Re: GIT workflow

[Mikko Rantalainen]

Vladimir 'φ-coder/phcoder' Serbinenko, 2013-11-10 19:01 (Europe/Helsinki):
> Hello, all. We've switched to git some time ago, now we should have some
> kind of workflow documents. In particular I think of following points:
> - Developpers with commit access can create branches as they see fit as
> long as it's prefixed by their name and they don't do sth nasty like
> storing binary or unrelated files.
> - When committing bigger work should we merge or squash? I think that
> squash should be possible if developper desires. Is there any reason to
> use merges?

Squashed merge is identical to rebase && merge --no-ff except for the 
detail that squashing loses any meaningful history for the patch series. 
I'd seriously suggest rebase followed by merge --no-ff over squashed 
merges. The only exception is the case where commits in the original 
work are not logical patches but instead random snapshots of the 
directory tree during development of the patch. In that case, squashing 
the patch series loses no valuable information.

The reason to keep patch series: git bisect

> - Which commits should we sign? All? Some? Official releases?

Depends on what you mean by "sign". If you mean

  Signed-off-by: A U Thor <address@hidden>

that's the "Developer Certificate Of Origin":
http://elinux.org/Developer_Certificate_Of_Origin

Other projects (e.g Grub) can decide their own policy for such metadata. 
Additional info is available at 
http://stackoverflow.com/questions/1962094/what-is-the-sign-off-feature-in-git-for

If you mean digitally signed, the correct method is to use signed tags 
for all the releases meant for non-developers. See "git help tag" and 
look for "--sign".

--
Mikko