问题
I am trying to implement a 'git-flow' kind of workflow using Gerrit but I can't seem to figure out the last piece of the puzzle.
There are two preconditions to my problem:
- Gerrit will only perform merging to one branch
- I do not allow merge commits to be pushed to Gerrit. The merging has to be done by Gerrit after the changes are approved
What I want to solve is the following. Consider this git situation:
Master 0
\
\
Develop 0-----0-----0-----0
There is a master branch with one commit and a develop branch which is forked from master with several additional commits. After a while the develop branch is merged back into master to create the next production release. The developers work with topic branches from develop and with strict rebasing. Their commits are always rebased on top of the latest upstream develop before pushing. This should result in linear history and only fast forward commits.
Now suppose someone creates a hotfix branch from master and merges back to master:
Master 0--------0 HF
\
\
Develop 0-----0-----0-----0
This commit is now only merged to the master branch but the developers need this commit in their develop branch to incorporate the bugfix in their changes. Normally you would merge the master branch to develop the develop branch but considering my preconditions this is not possible as it would create a local merge commit.
My question is: how do I incorporate the new commits from the master branch into the local develop branch so that any new changes by the devs will contain the bugfix? Ideally I would modify my script to first apply the bugfix changes to the local develop branch (merging but without a merge commit) and then rebase the dev's commits and push. This way the bugfix will be automatically added to their new changes and will be seen as such, as part of their new commits, not a seperate commit.
I've been thinking about possible solutions:
- Cherry picking the commit to the develop branch. I believe this will always result in a duplicate commit when develop is merged with master the next time. Is there any way around this?
- Rebasing as described here: http://davitenio.wordpress.com/2008/09/27/git-merge-after-git-cherry-pick-avoiding-duplicate-commits/ . This probably causes problems since the develop branch is published, or won't it?
I hope my question is clear. Please let me know if it needs further clarification. I know I'm being pretty rigid with my workflow, but it would be ideal in combination with Gerrit. If it can't be done then I will probably allow merge commits...
回答1:
After considering the options I have decided to abandon this method. It seems to me that Gerrit is targeted at single integration branch development for the most part.
When changes need to be merged to two branches (eg. a hotfix that needs to go to master and develop) it makes you jump through all kinds of hoops which amount to extra work/reviewing. I've decided to stick to one branch.
I think that the Git flow model doesn't really suit in the Gerrit design. If other people have integrated Gerrit with Git flow I would love to hear about their methods.
回答2:
You should be able to merge the hotfix into your development branch. You don't need to merge master. We handle this with this workflow (a hotfix is considered another release and we rebase work on top of it):
https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR
回答3:
The best solution is definitely to merge either master or the hotfix branch into your development branch. I'm not sure what your 'no merge commits' precondition is trying to solve, but it will probably create more hassle than it is worth.
On the other hand, if you do cherry pick, git will usually detect the duplicate commit during the merge and automerge it without any problems. But when there are problems they won't be fun. Also it isn't as clear which fixes have been cherry picked and which haven't, where as with a merge it is very clear.
来源：https://stackoverflow.com/questions/8405966/git-workflow-and-gerrit