[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
Cheers,
Julien
More information about the Bf-committers
mailing list