版本和傳統的SCM bugfixing

我是可怕的問題的標題很抱歉，但我會盡力解釋自己多一點冗長：版本和傳統的SCM bugfixing

我使用Git（但我猜特定軟件在這種情況下並不重要）爲我的軟件項目。就像許多項目一樣，我計劃進行各種發佈。當有一個版本時，我可能會分配一個提交標籤 - 例如「1.0」。時間過去了，代碼被黑了，最後還有一個發佈版，還有另一個標籤 - 這次是「2.0」。

有一天，我注意到一個嚴重的錯誤，這是目前在版本1.0和2.0，它需要修復。爲了讓事情變得困難（也可能更現實一些），我不能僅僅在當前的master/trunk中修復它，並假設每個人都會使用它，因爲2.0中存在一些向後不兼容的情況，並且人們懶惰，不願意不想升級。

那麼，爲了支持這種行爲，可以採取什麼樣的措施：能夠對舊版本進行更改。由於git describe命令（「[latest tag]-[commits since the tag]-[current commit hash]」）的輸出，Git似乎將標籤與某些級別的發佈等同起來。那麼我可能無法完全避免使用標籤。

我可以感覺到標籤和分支的組合會是一個好主意，但由於某種原因，我無法用這個東西包圍我的頭。

來源

2009-01-18 Henrik Paul

你一定要考慮使用分支爲此。 Git支持很好地支持這種類型的開發。

舉例來說，你的線性版本歷史記錄可能是這樣的：

---A---B---C[1.0]---D---E---F[2.0]---G---H

如果你發現在1.0中的錯誤，並希望解決它，你不能簡單地插入一個新的提交在提交之間C和D.因此，你可以創建一個分支是這樣的：

---A---B---C[1.0]---D---E---F[2.0]---G---H[2.1] 
      \ 
      C1---C2[1.1]

提交C1和C2固定在該分支，在那裏你可以標記1.1版的問題。現在假設您在版本2.1中進行了更改（G），您希望將其恢復到版本1.1以在此處進行相同的更改。您可以使用git cherry-pick做到以下幾點：

---A---B---C[1.0]---D---E---F[2.0]---G---H[2.1] 
      \ 
      C1---C2[1.1]---G1[1.2]

提交G1是有關承諾摹除了它可以的，而不是2.0版本，1.1版本上應用。

在這些例子中，分支（額外的開發流）是關鍵概念，而標籤只是一個方便的方式來指定項目在特定時間點所處的狀態。 Git支持許多其他操作分支的方式，特別是使用強大的git rebase命令。

來源

2009-01-19 00:31:03

您需要一個分支 - 您將在發佈標籤開始的分支上執行維護修復和發佈，同時繼續在主（主）分支上繼續開發。

來源

2009-01-18 23:10:56

如果你可以詳細闡述你的答案，也許有一個例子，我相信人們（不包括我）會更好地開悟。 – 2009-01-18 23:15:50

當您提到分支和標籤時，您似乎已經得到了大部分答案。一個標籤甚至可以標記一個特定的（像一個發佈版本），並且分支用於並行開發。某個版本的維護通常在分支上完成，您可以使用當前VCS的大部分選項來更改變更集，以將頭/ trunk中的給定錯誤修復導入分支中，反之亦然。

您可以關閉head/trunk/master（無論您是「當前」開發分支名稱）併合並各個維護分支中的錯誤修復。一旦完成主要或次要發佈，您就創建一個分支進行維護。

有很多方法可以實現你想要的。

來源

2009-01-18 23:41:47 Keltia

版本和傳統的SCM bugfixing

回答

相關問題