是否有建议的工作流程在Gerrit中使用git-flow功能分支？任何最佳做法？
我们正在启动一个包含多个开发人员的项目和一个由Git管理的中央存储库。使用git-flow，我一直坚持将功能分支推送到Gerrit的问题，作为在功能未完成时备份开发人员工作的一种方式：
我们不希望在开发时审查功能分支，因此我们允许所有开发人员直接推送到refs / heads / feature / *，绕过魔术审查分支。我们希望在功能分支合并到开发分支时进行审核，但是当开发人员在合并之后将其工作推送到Gerrit时，只有合并提交才能进行审核。功能分支中所做的更改不会出现在此修补程序集中。我认为这是因为这些更改被直接推送到refs / heads / feature / *所以Gerrit认为他们不再需要审核了。
开发人员是否应该在完成功能分支之前将功能分支推送到Gerrit？为了能够做到这一点，她需要在refs / heads / feature / *和refs / for / refs / heads / feature / *上推送和创建引用的权限，确保她只推送到审查分支。 / p>
非常感谢任何帮助。
答案 0 :(得分：6)
我和我的一位同事实际上已经用grit为git-flow做了一个分叉。 我们决定推进名为主题的分支，以区分常规开发和“功能/主题”分支的访问控制。
让我在星期一与他讨论并回到我们将所有内容发布到github的地方 ：）
我将开始删除源中的一些次要公司特定项目并发布到github。 我将在北京时间明天上午开始：）
最后 你可以检查这个git-flow的分支 https://github.com/RasmusVoss/gitflow
您需要阅读一些项目。 https://github.com/RasmusVoss/gitflow/wiki
要了解常规git-flow与此版本之间的区别， 这个版本主要面向使用Gerrit的开发人员，我们还没有使用git-flow的任何发布功能。
干杯。
答案 1 :(得分：2)
整合git-flow和gerrit并不是那么直截了当，当推动分支时，你不能改变git-flow中的起源来反映gerrit中审查所需的起源。
我读了wiki page，讨论了集成git-flow和gerrit的棘手部分。您可能也想阅读它。