面向初學者的 SVN 按功能分支

Question

我與一個 PL/SQL 團隊合作，該團隊習慣於使用基於每個文件鎖的 SourceSafe 進行版本控制。 一位用戶“擁有”該文件。 交付新代碼時，有人手動整合所有更改，然后將整合包部署在登台環境中。 如果有什么東西壞了，他們只是從整合包中刪除壞的代碼，然后再次分期。 如果一切正常，他們會在生產中部署整合包。

現在他們必須用 Java 編寫代碼，並使用 SVN。 這是一個很大的變化。 我們制定了開發和部署策略，但我們並不是 100% 滿意。

分支機構：

• 主干：代碼穩定並已部署在生產中。
• 功能：每個功能都是在從主干創建的特定分支中開發的。
• 維護：此分支用於修復生產錯誤，它是在生產中部署后從主干創建的。 我們只需要處理 N-1 版本。

在部署之前，我們希望在臨時環境中測試新功能和維護錯誤修復。 我們的想法是將我們要測試的維護和功能分支合並到主干中。 在登台環境中部署主干。

案例 1：新功能需要修正

• 修復在功能分支中完成
• 修復后，功能分支合並到主干中

問：如果該功能由於維護錯誤修復而不起作用怎么辦？ 功能修復應該在主干中完成嗎？

案例 2：新功能尚未生產就緒，我們無法在短期內發布

• 由於該功能已合並到主干中，我們必須從該分支恢復。

我們是否應該恢復自最新生產版本以來的所有合並，並且只重新合並想要的分支？

案例 3：暫存持續 2 周，但仍需要提交錯誤修復生產

• 維護分支已合並到主干。

在暫存期間，我們應該在哪個分支上提交錯誤修復。 如果我們在維護分支上提交它們，我們可能會丟失這些更改，因為當暫存完成時，主干將投入生產，並且將從該主干創建一個新的維護分支。 因此，新的維護分支將錯過在暫存期間完成的舊維護分支的提交。

正如您所看到的，有很多問題沒有得到解答，並且是一個包含大量合並的復雜策略（耗時且容易出錯）。 從我讀到的關於這個主題的博客來看，我認為我們的分支設置是失敗的。 我們對任何修改持開放態度，目標是有一個簡單易懂的策略。

Answer 1

這似乎太寬泛和/或太基於意見，不適合 SO，但是......

情況1：

如果您不將 MAINT 中的 bigfixes 合並回“工作分支” - 您完成了分支|合並錯誤。 即之前合並到您擁有的主干功能分支（來自我的 POV）：

• 在 feature-branch 中寫入錯誤修復，將新范圍（自動檢測到不太古老的 SVN）合並到以前已經與維護同步的主干中。 “如果該功能由於維護錯誤修復而不起作用”，您必須在功能分支中添加新的錯誤修復以“獲得維護兼容性”並再次合並

但要注意：SVN 中的循環合並（即使是最新鮮的）可能會在不可預測的（一般）點與樹沖突產生奇怪和糟糕的結果

功能修復應該在主干中完成嗎？

這更多是本地策略的問題，但對於“穩定主干”，我更喜歡看到只有來自不同分支的合並集的主干（更容易發現歷史）

案例2：

如果只有合並集（在某種程度上，見下文）主干，您必須反向合並主干中的單個合並集，將未准備好的生產功能合並到主干。 注意：為了返回功能，您沒有重新合並功能分支，您必須反向合並修訂，這（反過來）從主干反向合並功能

案例3

是的，帶有修補程序的 MAINT必須合並到 STAGING（主干）中，並像任何其他合並一樣重新測試主干