我的開發團隊和我開始經常在幾個問題上運行，而不涉及git。我們都在名爲mysql_trunk的同一分部工作。我們經常遇到推衝突和合並衝突。與大型代碼庫和多個開發人員的多次提交一起工作Git
我們很喜歡使用git，但我們覺得在這裏丟失了一些東西。必須有一種更有效的方式來處理大型代碼庫（1.5mil代碼行），同時多個開發人員同時對相同的回購進行貢獻。這似乎是一個相當直接的問題，但我們真的可以通過一些幫助找到解決方案，防止我們不斷地推動衝突，合併衝突，分離HEAD衝突。
任何建議和/或閱讀材料將不勝感激。
鑑於git被用於（並開發用於）linux內核，1.5MLOC似乎並不是特別龐大的代碼庫（內核大約是其10倍）。您的併發開發人員數量可能還少於Linux。
所以問題是，你爲什麼首先得到這些衝突？
無論如何，有很多方法可以避免合併衝突。這裏有幾個（由4 Simple Tricks to Avoid Merge Conflicts啓發）
承諾的時候，做最小的原子提交，往往不惜。 （不要讓代碼文件的重新縮進破壞你的bug修正提交）
確保使用相同的編碼約定（尤其是空格）
創建功能分支，而且使短並且將它們合併爲一個分支（分支從中繼線分支越少，發生衝突的機率越小）
以模塊化方式組織代碼：如果開發人員處理（不同/無關任務需要更改非常相同的代碼行，那麼你的代碼組織有問題 - 並且沒有VCS能夠幫助你）。溝通（如果你的代碼已經是模塊化的，而不是確保工作在相同的代碼上的人，一起工作而不是互相攻擊;他們應該知道代碼的哪些部分在不久的將來會改變，所以他們能忍住自己的修改）
承諾往往
確保您正在跟蹤僅人工編輯的文件（沒有二進制文件，沒有文本構建工件（如自動工具文件）
承諾更經常的是
如果你經常遇到合併衝突，它*可能*意味着你有一些文件，每個人都經常碰觸。如果這是正確的，你應該考慮拆分這些文件或者重構它們來分離責任。 「上帝階級」通常會像這樣結束。 –
至於推衝突，是的，這會發生，但你們是否都直接在分支上工作？你在做小功能嗎？還是更大的功能？您是否考慮過功能分支，以便您可以或多或少地單獨工作，直到功能完成爲止？這應該可以緩解主分支周圍的一些爭議。 –
其通常很小的功能錯誤修復，偶爾大功能集。 – Charles