gitworkflows - how exactly to graduate a branch?
I have a git branching model pretty much like the one described in gitworkflows http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html and here http://members.cox.net/junkio/git/MaintNotes.html
I have some doubts about how exactly to graduate a branch and what to do with commits that fix bugs that only happen when 2 different branches interact.
Specifically, I have these branches:
production: exactly the same as what's deployed in our production server
hotfixes: forked from the tip of 'production', where I fix bugs and later fast-forward 'production' to it (and re-deploy)
several feature branches: every new feature is created in isolation
开发者_开发技巧test: where I merge every feature branch that's mature enough
all: where I merge every feature, no matter how new or untested it is
Say I merge feature branches F1 and F2 in that order into 'test'. It turns out that they don't play nice together, so I commit fixes C1 and C2 (directly into 'test'); I later merge a third branch F3 and continue committing fixes for bugs that happen because of these branches not interacting well (if I found a bug in one specific feature, I would fix it in it's own branch and then re-merge). I later want to graduate only F2, because F1 and F3 are not ready yet (or because the client is on a whim), so I merge that branch directly into 'production'.
What to do next?
What to do with the bug fixes that were in 'test' that involved F2 interacting with F1 or F3 (like C1 and C2)? Do I cherry-pick them into the corresponding not-yet-graduated branch? Wouldn't this be a bit too much manual work?
What about 'test'? Do I discard it and build it again from the new tip of 'production'? If so, how to avoid losing the bug fixes for branches that aren't yet in 'production'? cherry-pick again? Is there a way to update 'test' that does not require reset/rebase?
Would it have been better to revert the merge(s) of F1 and F3 into 'test' and once I have only F2 in there, merge 'test' into production'? Note that this model also requires me to revert the bug fixes that relate to the branch I'm reverting.
The complexity of this model comes from the common branch 'test
', where too much operations are done.
I would rather:
- isolate the current "integration in progress"
F1
+F2
+F3
in its own branch 'integ
' - reset
test
onprod
(provided everybody is clear on the consequence of a reset, and is ready to reset his/her own local cloned branchtest
). - merge
integ
ontest
(getting back all the work done on those three features, but based onprod
)
精彩评论