我正在尝试使用 Gerrit 实现“git-flow”类型的工作流程，但我似乎无法弄清楚最后一块拼图。
我的问题有两个先决条件：
- Gerrit 只会对一个分支执行合并
- 我不允许将合并提交推送到 Gerrit。更改获得批准后，合并必须由 Gerrit 完成
我想解决的问题如下。考虑一下这个 git 情况：
Master 0
\
\
Develop 0-----0-----0-----0
有一个具有一次提交的 master 分支和一个从 master 分叉出来并具有多个额外提交的开发分支。一段时间后，开发分支被合并回主分支以创建下一个生产版本。开发人员使用来自开发的主题分支并进行严格的变基。在推送之前，他们的提交总是基于最新的上游开发。这应该会导致线性历史记录并且仅快进提交。
现在假设有人从 master 创建了一个修补程序分支并合并回 master：
Master 0--------0 HF
\
\
Develop 0-----0-----0-----0
此提交现在仅合并到主分支，但开发人员需要在其开发分支中进行此提交，以将错误修复合并到他们的更改中。通常，您会合并主分支来开发开发分支，但考虑到我的先决条件，这是不可能的，因为它将创建本地合并提交。
我的问题是：如何将主分支的新提交合并到本地开发分支中，以便开发人员的任何新更改都将包含错误修复？理想情况下，我会修改我的脚本，首先将错误修复更改应用到本地开发分支（合并但没有合并提交），然后重新设置开发人员的提交和推送。这样，错误修复将自动添加到他们的新更改中，并且将被视为新提交的一部分，而不是单独的提交。
我一直在思考可能的解决方案：
- 精挑细选对开发分支的提交。我相信当下次开发与 master 合并时，这总是会导致重复提交。有没有办法解决？
- 变基如下所述：http://davitenio.wordpress.com/2008/09/27/git-merge-after-git-cherry-pick-avoiding-duplicate-commits/ http://davitenio.wordpress.com/2008/09/27/git-merge-after-git-cherry-pick-avoiding-duplicate-commits/。由于开发分支已发布，这可能会导致问题，或者不会吗？
我希望我的问题很清楚。如果需要进一步说明，请告诉我。我知道我的工作流程非常严格，但与 Gerrit 结合使用将是理想的选择。如果无法完成，那么我可能会允许合并提交......
在考虑了各种选择之后，我决定放弃这种方法。在我看来，Gerrit 的大部分目标是单一集成分支开发。
当更改需要合并到两个分支时（例如，需要掌握和开发的修补程序），它会让您跳过各种麻烦，这相当于额外的工作/审查。我决定坚守其中一个分支。
我认为 Git 流程模型并不真正适合 Gerrit 设计。如果其他人将 Gerrit 与 Git 流程集成，我很想听听他们的方法。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
