我不認爲我在做正確的事情。我正在使用Subversion作爲我們組織網站的vcs。我是唯一的開發人員，我使用bugzilla作爲我的錯誤跟蹤系統。我已經使用bugtraq屬性鬆散耦合了bugzilla和svn，以便我可以將我的評論鏈接到bugzilla。我現在正在做的是每當我收到一個請求在網站上執行任何工作（增強，中斷，內容更改）時，我在bugzilla中創建一個bug [xx]，然後創建一個名爲bug [xx]的分支。完成任務之後，我手動將分支更改導出到我們的測試版網站，更改已經過審查和驗證，然後我使用bugtraq屬性將分支合併回主幹，指示錯誤＃。在顛覆中管理分支
這工作得很好除了當我有一個或兩個以上的變化。如果我爲十個工作請求創建了10個分支，我想知道如何輕鬆分辨哪些已經合併到主幹中，哪些不合並。如果我應該使用似乎瘋狂的mergeinfo屬性...
我不想從顛覆，因此不建議它。
爲什麼不在重新整合到主幹後刪除分支？當一個功能分支重新集成時，你應該做的事情（在一般情況下）。所以診斷很簡單：如果分支存在，它還沒有重新整合。
你的工作流程對我來說似乎很不錯。但是，在您重新合併到主幹後，您不再需要錯誤分支，因此請將其刪除。這樣，你只會有分支數量作爲開放的錯誤。
如果需要，您可以隨時取回分支，但不會讓事情混亂。
從我的角度來看，爲每個bug創建一個分支並不是一個好的做法。作爲分支的最佳做法中提到，你應該在兩種情況下創建分支：
看來你只是需要第二個分支。爲了更清楚地看看下面的圖片：
的開發分支是你的軀幹目錄下保持一個（綠線）。您可以創建一個名爲發佈分支的分支（紅線），並將要發佈的更改合併到該分支中。這樣，只有選定的更改進入您的發佈版本。如果您正在開發一項可能需要1-2周以上的新功能，請創建功能分支（藍線），並在完成後合併更改。功能分支完成後可能會被刪除。
所以，我建議你只有一個叫做發佈分支的分支。當您收到錯誤時，請在您的開發線中進行更改。當測試正常時，您可以將更改合併回發佈行。這樣，您就可以發佈所需的功能。另外，通過查看您的發行版歷史記錄，您可以找到哪些更改已合併到發佈行中。
在您投入生產之前5分鐘，您會收到一個調用，不會部署您所做的5個錯誤修復中的錯誤3。您現在已經將錯誤匯入svn中的一個版本。嘗試現在刪除一個錯誤。 –
在這種情況下，您應該將您的發行版恢復到以前的版本，並重新合併所需的錯誤修復。你的風格存在同樣的問題。假設在你進入生產之前五分鐘，你會接到一個調用，不會部署你所做的6個bug修復的bug4。但是，您已經將6個不同分支中的所有更改合併到了每個bug中！你現在應該怎麼做？ – hsalimi
此外，如果您的錯誤修復在同一地點包含更改，則合併過程確實是一個很大的問題。但是將所有修復都放在同一行中，合併過程不那麼痛苦。 – hsalimi
嗯。這很好，很簡單。讓我思考一下。 –