[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GIT workflow

From: Mikko Rantalainen
Subject: Re: GIT workflow
Date: Thu, 14 Nov 2013 15:20:10 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0

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":

Other projects (e.g Grub) can decide their own policy for such metadata. Additional info is available at

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".


reply via email to

[Prev in Thread] Current Thread [Next in Thread]