Git工作流程和Gerrit [英] Git workflow and Gerrit

问题描述

我正在尝试使用Gerrit实现'git-flow'类型的工作流程，但我似乎无法弄清楚拼图的最后一部分。

我的问题有两个先决条件：

• Gerrit只会执行合并到一个分支


• 我不允许合并提交被推送到Gerrit。在批准更改后，合并必须由Gerrit完成

我想要解决的是以下几点。考虑一下这个git情况：

$ $ $ $ $ $ $ $ $

开发0- ---- 0 ----- 0 ----- 0

有一个主人分支与一个提交和一个开发分支，这是分支从主与几个额外的提交。一段时间后，开发分支合并回主，以创建下一个产品版本。开发人员通过开发和严格重新设计来处理主题分支。在推动之前，他们的承诺总是在最新的上游开发之上进行重新设计。这应该会导致线性历史记录，只有快速转发提交。

现在假设有人从主服务器创建了一个修补程序分支并合并回主服务器：

 主人0 -------- 0 HF 
 \ 
 \ 
开发0 ---- -0 ----- 0 ----- 0 
  

此提交现在仅合并到主分支，但是开发人员需要在开发分支中提交这个提交，以便将bug修改纳入其更改中。通常你会合并master分支来开发develop分支，但考虑到我的前提条件，这是不可能的，因为它会创建一个本地合并提交。

我的问题是：怎么做我将主分支中的新提交合并到本地开发分支中，以便开发人员进行的任何新更改都将包含bug修复？理想情况下，我会修改我的脚本，首先将修补程序更改应用到本地开发分支（合并但没有合并提交），然后重新设置开发者的提交和推送。这样，bug修复会自动添加到他们的新修改中，并且会被视为新的修改的一部分，而不是单独提交。

我已经考虑可能的解决方案：

• Cherry选择提交到开发分支。我相信，当开发与下一次合并时，这总是会导致重复的提交。有没有办法解决这个问题？


• 按照此处所述重新配售： http://davitenio.wordpress.com/2008/09/27/git-merge-after-git-cherry-pick-avoiding-重复提交/ 。这可能会导致问题，因为发展分支机构已发布，或不是吗？
  
  
  我希望我的问题很明确。请让我知道是否需要进一步澄清。我知道我的工作流程非常僵化，但它与Gerrit结合使用会非常理想。如果无法完成，那么我可能会允许合并提交...

  解决方案

  考虑到我已决定选择放弃这种方法。在我看来，Gerrit主要针对单一整合分支的开发。
  
  

  当需要将更改合并到两个分支（例如，需要到达主服务器并进行开发的修补程序）时，它会让您跳过所有类型的箍环额外的工作/审查。我决定坚持一个分支。
  
  

  我认为Git流模型并不适合Gerrit设计。如果其他人将Gerrit和Git流程整合在一起，我很乐意听到他们的方法。

  
  

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

  解决方案

  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.

  这篇关于Git工作流程和Gerrit的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！