[Bf-committers] RFC: "Continuous integration" branch?

Julien RIVAUD (_FrnchFrgg_) frnchfrgg at free.fr
Sun Mar 8 07:22:51 CET 2015

Le 06/03/2015 09:38, Sergey Sharybin a écrit :

> We could approach to the issue of applying patches from a totally different
> angle tho. Screw it creating branches in the main repository, just whoever
> is responsible for that patch could have a local staging branch with all
> the commits ready for master. So workflow would be something like:
> - Developer sees a good patch
> - He applies it in a local staging branch
> - Gives some reasonable explanation on when it'll be in actual master
> (we'll also need to have a way to mark patches as applied in someone's
> staging branch)
> - Rebases the local staging after the release and pushes changes ot actual
> master
> - Drops the local branch
> Not perfect, but addresses concerns of work being spreaded at the
> stabilization period. Plus it could be combined with per-developer /
> per-feature branches (if develoeprs thinks those branches needed).

That's going to look a lot like the maintainer workflow of Junio C 
Hamano for git itself: he locally (in his tree) keeps a branch per 
patchset he intends to let into master, with a name looking like 
"jk-some-feature" where "jk" are the initials of the patch authors.

The difference is that he probably doesn't rebase much, but rather uses 
merges (I'm not completely sure about that), and he publishes a branch 
in which he tried to merge all pending patches (that is called "next" IIRC).

Another difference is that even if a patch set is fully rebased to 
master, he nevertheless keeps a merge commit, whose message describes 
the goal of the patch set as a whole (kind of the description of the 
patch set in Phab). The history gets a lot more branchy (non-linear) but 
each patch set is more insulated. Patch sets are easier to revert as a 
whole, bisection is more efficient because it doesn't consider at all 
the patches of a set that's irrelevant, and so on. And you get a good 
starting point for the end-user changelog by showing messages of merge 
commits only.

See also http://nvie.com/posts/a-successful-git-branching-model/
and https://git.wiki.kernel.org/index.php/MaintNotes



More information about the Bf-committers mailing list