Git工作流程和Gerrit

Question

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

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

• Gerrit只会执行合并到一个分支
• 我不允许将合并提交推送到Gerrit.在批准更改后,Gerrit必须完成合并

我想要解决的是以下内容.考虑这个git情况:

Master 0 
        \
         \
Develop   0-----0-----0-----0

有一个master分支有一个commit和一个develop分支,它是从master分支出来的,有几个额外的提交.过了一会儿,开发分支被合并回master,以创建下一个生产版本.开发人员使用开发和严格变基的主题分支.在推动之前,他们的承诺总是在最新的上游开发之上进行重新设计.这应该导致线性历史记录并且只有快进提交.

现在假设某人从master创建了一个修补程序分支并合并回master:

Master 0--------0 HF 
        \
         \
Develop   0-----0-----0-----0

此提交现在仅合并到主分支,但开发人员需要在他们的开发分支中进行此提交,以在其更改中包含错误修复.通常你会合并master分支来开发develop分支,但考虑到我的前提条件,这是不可能的,因为它会创建一个本地合并提交.

我的问题是:如何将主分支中的新提交合并到本地开发分支中,以便开发人员的任何新更改都包含错误修复？理想情况下,我会修改我的脚本,首先将bugfix更改应用于本地开发分支(合并但没有合并提交),然后重新设置dev的提交并推送.这样,错误修复将自动添加到他们的新更改中,并将被视为这样,作为新提交的一部分,而不是单独的提交.

我一直在考虑可能的解决方案:

• Cherry选择了对开发分支的提交.我相信,当下次开发与master合并时,这将始终导致重复提交.有没有办法解决？
• 如此处所述进行重新定位:http://davitenio.wordpress.com/2008/09/27/git-merge-after-git-cherry-pick-avoiding-duplicate-commits/ .这可能会导致问题,因为开发分支已发布,或者不会发布？

我希望我的问题很明确.如果需要进一步澄清,请告诉我.我知道我的工作流程非常严格,但与Gerrit结合使用会非常理想.如果无法完成,那么我可能会允许合并提交......

Answer 1

在考虑了选项后,我决定放弃这种方法.在我看来,Gerrit主要针对单一集成分支开发.

当需要将更改合并到两个分支(例如,需要掌握和开发的修补程序)时,它会让您跳过所有类型的箍,这相当于额外的工作/审查.我决定坚持一个分支.

我认为Git流模型并不适合Gerrit设计.如果其他人将Gerrit与Git流程整合在一起,我很想知道他们的方法.