我是一个应用 SCRUM 和 Git 的学生程序员团队的技术经理。
我们使用以下分支模型: http://nvie.com/posts/a-successful-git-branching-model/
虽然我一周只工作半周，但学生们会在最适合他们的日程安排/个人需求的时候进行计划(也可以在周末或有时在深夜)。
现在我们有不同的要求(在我看来)不能很好地结合在一起:
一方面作为负有技术责任的人，我想在代码进入开发分支之前对其进行审查，并能够检查代码是否存在单元测试，总体上遵守编码风格和可维护性。
另一方面我希望我的团队经常 merge ，这样就不会出现 merge 冲突(或者至少保持尽可能少的冲突。
- 这是一个常见问题吗？其他人已经发现了这个问题 一个经过验证的解决方案？
- 我这里有什么特别的问题吗？你有 知道如何解决吗？
- 我这样想是不是走错了方向——这是我的前提 有点假？
最佳答案
这就是您可以利用 Git 的分布式特性的地方:
您可以将它们 merge 到专用“QA”存储库的开发分支中，如果提交获得批准，该分支又将推送到最终的集中式存储库。
理想情况下，QA 存储库是 gerrit一，旨在促进审查过程。
但 DVCS 的总体思路是:您不仅有 merge 工作流程(从一个分支 merge 到另一个分支)，您还有一个 publication workflow (从存储库推送到 upstream repo )。
关于git - 最佳实践 : Workflow: When to merge in a inhomogeneous team，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/19223118/