我的开发团队和我开始经常在几个问题上运行，而不涉及git。我们都在名为mysql_trunk的同一分部工作。我们经常遇到推冲突和合并冲突。与大型代码库和多个开发人员的多次提交一起工作Git
我们很喜欢使用git，但我们觉得在这里丢失了一些东西。必须有一种更有效的方式来处理大型代码库（1.5mil代码行），同时多个开发人员同时对相同的回购进行贡献。这似乎是一个相当直接的问题，但我们真的可以通过一些帮助找到解决方案，防止我们不断地推动冲突，合并冲突，分离HEAD冲突。
任何建议和/或阅读材料将不胜感激。
鉴于git被用于（并开发用于）linux内核，1.5MLOC似乎并不是特别庞大的代码库（内核大约是其10倍）。您的并发开发人员数量可能还少于Linux。
所以问题是，你为什么首先得到这些冲突？
无论如何，有很多方法可以避免合并冲突。这里有几个（由4 Simple Tricks to Avoid Merge Conflicts启发）
承诺的时候，做最小的原子提交，往往不惜。 （不要让代码文件的重新缩进破坏你的bug修正提交）
确保使用相同的编码约定（尤其是空格）
创建功能分支，而且使短并且将它们合并为一个分支（分支从中继线分支越少，发生冲突的几率越小）
以模块化方式组织代码：如果开发人员处理（不同/无关任务需要更改非常相同的代码行，那么你的代码组织有问题 - 并且没有VCS能够帮助你）。沟通（如果你的代码已经是模块化的，而不是确保工作在相同的代码上的人，一起工作而不是互相攻击;他们应该知道代码的哪些部分在不久的将来会改变，所以他们能忍住自己的修改）
承诺往往
确保您正在跟踪仅人工编辑的文件（没有二进制文件，没有文本构建工件（如自动工具文件）
承诺更经常的是
如果你经常遇到合并冲突，它*可能*意味着你有一些文件，每个人都经常碰触。如果这是正确的，你应该考虑拆分这些文件或者重构它们来分离责任。 “上帝阶级”通常会像这样结束。 –
至于推冲突，是的，这会发生，但你们是否都直接在分支上工作？你在做小功能吗？还是更大的功能？您是否考虑过功能分支，以便您可以或多或少地单独工作，直到功能完成为止？这应该可以缓解主分支周围的一些争议。 –
其通常很小的功能错误修复，偶尔大功能集。 – Charles