在组织分支和工作流程方面需要一些帮助。
前提条件：10 名开发人员使用 git，0 次单元测试覆盖率，10^5 行代码。
在我们的带有master分支的 repo 中，它充当production.
每个功能都在不同的分支上开发，这也创建了一个新的域 ( branch.qa.com)
完成后，QA 团队会检查更改branch.qa.com，然后将其合并到主服务器并自动推送到生产服务器。
问题：
分支 A 可能有css变化。它被上传A.qa.com并被检查。同时，开发人员从
分支分支并对其进行处理，修改相同的. Bmastercss
这两个更改对于它们的分支来说似乎都是合法的，但是可能会发生 change onB实际上粉碎了某些东西A。
合并A进去master就OK了。那么merging Bintomaster会对A.
你排除这种情况吗？你如何融入pre production？
如果您遵循 git-flow，您将拥有一个单独的develop分支，所有新功能都会从其中分支出来，并在完成后合并回。
然后，您可以从develop分支创建临时release分支，这些分支经过测试（必要时可能会进行修补），然后合并到您的master/production分支中。
所以develop分支实际上最终成为一种pre production分支。
如果您然后让您的 QA 部门在合并回 之前处理功能检查develop，以及所有转换到releaseand master，我想您最终会在当前部门结构中得到您想要的。
图在这里： http: //nvie.com/posts/a-successful-git-branching-model/
作为补充说明，我们目前正在通过gerrit实现 git-flow 和代码审查，这将为我们提供一个处理所有这些的平台——尽管在我们的案例中，开发人员和 QA 团队是同一个人（尽管有添加了具有自动化测试功能的Jenkins CI服务器）。
你可以看看这个链接http://nxvl.blogspot.com/2012/07/a-continous-delivery-git-branching-model.html
我认为在您的组织中，develop缺少“ ”分支。
预生产阶段可以是“ develop”分支，生产是“ master”分支。
由于分支之间可能存在冲突，您不能直接合并到您的“ master”分支中而无需进一步测试（这里的冲突不仅是“git冲突”，还有算法冲突）