在组织分支机构和工作流程时需要一些帮助 前提条件：10个开发人员使用git，0个单元测试覆盖率，10 ^ 5行代码。
我们的回购邮件中有master分支，其作用为production
每个功能都是在不同的分支上开发的，这也会创建一个新域（branch.qa.com）
完成后，QA团队会对branch.qa.com进行更改，然后将其合并为主服务器并自动推送到生产服务器。
问题：
分支A可以进行css次更改。它会上传到A.qa.com并进行检查
同时，开发人员从B分叉master并对其进行处理，修改相同的css。
这两项更改似乎对其分支机构来说都是合法的，但可能会发生B上的更改实际上会对A上的内容产生影响。
将A合并到master即可。然后将B合并到master将对A所做的更改产生不良影响。
你能排除这种情况吗？您如何合并pre production？
答案 0 :(得分：4)
如果您关注git-flow，则会有一个单独的develop分支，其中所有新功能都已分支出来并在完成时合并回来。
然后从develop分支创建临时release分支，这些分支经过测试（如有必要，可能会进行修补），然后合并到master / production分支。
因此，develop分支实际上最终成为一种pre production分支。
如果您让QA部门在合并回develop之前处理功能检查，并且所有过渡到release和master，我认为您最终会你当前的部门结构中想要什么。
图表：http://nvie.com/posts/a-successful-git-branching-model/
作为补充说明，我们目前正在通过gerrit实施git-flow以及代码审查，这将为我们提供处理所有这些的平台 - 尽管在我们的案例中开发人员和QA团队是相同的人（尽管添加了Jenkins CI服务器并进行了自动化测试）。
答案 1 :(得分：1)
您可以查看此链接http://nxvl.blogspot.com/2012/07/a-continous-delivery-git-branching-model.html
我认为在您的组织中，缺少“develop”分支。
预生产阶段可以是“develop”分支，生产是“master”分支。
由于分支之间可能存在冲突，因此不能在没有进一步测试的情况下直接合并到“master”分支中（此处冲突不仅是'git conflict'而且还有算法冲突）