Ada*_*dam 6 git continuous-integration github
我们正在概述和准备Git集成,我们正在实现与以下链接类似的设计.
http://nvie.com/posts/a-successful-git-branching-model/
我们遇到的问题是当你提交并推送到'develop'分支或持续集成分支时,因为我们有多个团队在不同的分支上工作,你必然会遇到合并冲突,因为你永远不会从'开发在推动之前.对于团队来说,尝试解决他们没有太多知识的事情似乎并不是最好的做法.
我们的一个想法是在'develop'分支上做一个pull请求,并有一个专门解决这些问题的团队.
他们是我们缺少的选择吗？
功能分支背后的想法是它们应该只包含一个小的原子更改。理论上，由于其本质，此更改不应导致合并冲突。
如果某个功能引入了合并冲突，我会更倾向于检查您认为的“功能”。
我所经历的引入方式是，一项功能与一项特定任务相关，该任务（就时间而言）不应持续超过一两天。
鉴于时间跨度短，在周期内不太可能出现合并冲突，但如果出现这种情况，例如当您有多个团队在代码库的同一区域工作时，则需要一定程度的沟通来确保合并冲突矛盾得到正确解决。
您可以应用不同的模型来帮助您管理冲突解决。我们采用水平切片模型，在该模型中，如果多个团队需要在代码库的特定区域进行更改，则会将其分配给项目包含整个给定模块的团队。您的公司可能对垂直切片模型更感兴趣，在这种情况下，您不太可能遇到团队之间的合并冲突。
在解决冲突方面，再多的工具也无法胜过对话。如果您知道您的更改将影响其他人正在处理的文件，则最好遵循的模型是对话。
在某些情况下，这并不理想，企业可能对谁的更改何时发布有其他想法，但只要每个开发人员保持其功能分支与开发保持同步，那么发生冲突的可能性就会大大降低。