如何管理來自多個開發人員的合併更新？

我與一箇中等規模的開發團隊合作開發一款產品。開發人員編寫代碼來解決功能或錯誤修復權證，然後將其簽入我們的主要開發分支（在Subversion中）。一旦這張票已經由質量保證人在那裏進行測試和驗證，我將它合併到後備箱中。我通常會手動執行此操作，因爲很多票都包含多個修訂版，這些修訂版並不總是順序的，並且可能包含一次修復多張票的修訂。如何管理來自多個開發人員的合併更新？

我肯定有一件事情會有所幫助，那就是鼓勵開發者每次修改只籤一張票。我們使用Jira來跟蹤我們的任務，因此每個Subversion修訂版本都應該在日誌中包含Jira問題標識 - 當我合併代碼時，我會查找包含我正在合併的問題的修訂版本。

Are there其他方式我可以更好地管理這個？其他團隊是否爲每一張票和問題分行？正如我所說的，我們有一個主要的開發分支，至少部分原因是我們正在快速構建大量新功能，而且我想如果我們爲每張門票製作一個分支，我們就會很快結束數十個分支。

來源

2009-07-31 Brock Boland

這個問題與DVCS無關。這是一個過程問題，而不是技術問題。下面是我採取什麼很多人都在做，而且ClearCase的UCM推廣過程：

/project/trunk 
     /branches 
      /release-1.0-JIRA1023 
      /release-1.0-darthcoder-JIRA1029 
      /darthcoder-JIRA1029 

     /branches/release-1.0-tfix <- This is the patch trunk. Main trunk is future dev

當我解決我的錯誤，我想提拔回主幹，或到具體的發佈我米試圖解決。我將合併到release-1.0-tfix和trunk，因爲它需要在幾個地方修復。完成後，我刪除分支並轉到下一個問題。因此，當我測試它並處理問題時（如果解決方案非常不同的話），我有兩個JIRA修復代碼分支。

但是除非運行成功的構建/測試周期，否則沒有任何東西會被提升爲樹幹或-tfix樹，並且它具有用於跟蹤的JIRA屬性。通過這種方式，您可以將每個單獨的修補程序與開發人員，分支聯繫起來，並驗證事情得到正確修復。此外，這些問題不會丟失（JIRA1029是否已經成爲1.2版本？那麼您可以通過在存儲庫中查找JIRA1029來驗證它，您永遠不需要使用GUESS，這就是軟件開發可重複使用並使我們更容易接近錯誤== 0

來源

2009-07-31 17:10:46

有趣。快速提問 - 您是否總是爲每個Jira創建一個分支，或者是否有任何情況下您在一個分支中一次性修復一組Jira門票？ – 2009-07-31 17:17:00

您可以在一個分支中修復一些bug/jira，但UCM的理想是爲每個修補創建可能的最小變更集。假設你正在研究Linux內核，並且你分發了補丁。你想向最終用戶提供什麼，可能不適用於他們（可能是有害的）的一大塊修復，或者小的，重點突出的外科修復？這兩種方法都有爭議，但我儘可能地支持1 JIRA - 1合併。對於大型JIRA（如新功能/增強），這可能變得不實用。 – 2009-07-31 17:43:12

您是否在使用併發版本？對於我的所有沒有太多併發版本開發的項目（通常是< 10個開發者），我們使用trunk。一個簽入應該只適用於一個如果它恰好修復了另一張票，那麼票更新並標記爲測試

爲什麼你合併？是你的代碼審查還是你確保構建不被破壞的方法我個人會設置持續整合並跳過這一步，你應該是能夠相信您的開發人員不會破壞構建，並讓CI抓住他們，如果他們這樣做。

來源

2009-07-31 17:22:07 Gren

如何管理來自多個開發人員的合併更新？

回答

相關問題