讓git分支「變老」有什麼危害嗎？

所以我聽說過使用Git的branch-per-feature工作流程，我也讀過一些爲什麼this could be a bad idea的原因。我真正的問題是 - 如果我正在開發一個小功能（就像一個簡單的正則表達式時間解析器），合併這個分支回到樹幹後，會發生（或應該發生）該分支？它只是坐在那裏嗎？由於我爲那個創建了它，非常具體的功能，我想不出我必須回去並使用該分支的原因。我應該以某種方式將這個分支標記爲不存在，或者我只是繼續前進而忘記它？讓git分支「變老」有什麼危害嗎？

謝謝

來源

2011-10-31 Wayne Werner

一旦你完成，你可以刪除分支，不是嗎？（'git branch -d'） –

是的，git branch -d總是安全的，它不會丟失隨後可能被垃圾回收的修訂。 git分支-D將甚至刪除包含其他地方找不到的更改的分支。這在大多數情況下很有用，當你確定一種方法是完全死衚衕的時候。鑑於磁盤空間有多便宜，你可能不願意使用git分支-D – tialaramex

它可能會幫助你記住分支僅僅是一個指向提交的指針。一旦你完成了一個分支的工作，並且你已經合併了這個提交，你就不必再指向它了。 – Cascabel

當我使用功能分支時，我喜歡保留合併後在分支中開發功能的事實。這使瀏覽歷史更容易。它通過功能或錯誤對變化進行分組，使得知道最重要的事情變得更容易：爲什麼變更完成了。

這就是爲什麼當我合併時，我故意使用git merge --no-ff禁用快進。這保留了歷史分支的結構。然後我可以自由刪除分支標籤（git branch -d branch_name），合併點包含分支名稱，並清理分支組。

相比之下，在分支上工作時，我更願意重新綁定上游分支。這保持了分支的歷史很好，乾淨，沒有大量的上游合併噪音和衝突解決方案。在合併之前，我通常會重新設置上游，以使整合工作變得更容易（因爲分支作者可以修復衝突和破壞測試）以及合併清理器。

這種方法保留了分支機構的歷史，同時防止舊的分支機構不再被阻塞發展。它使用gitk或GitX對歷史進行可視化非常有用。

我同意你鏈接的文章中的基本觀點，因爲你越來越多的大型功能分支正在同步工作，越來越多的衝突和集成問題出現。孤立使它們如此有用成爲一種責任。其中一個解決方案是不具有大的舊功能分支。如果你可以將一個功能分支變成可以完成並集成的小塊，那麼你可以避免這個問題。對於許多其他原因，這通常很有用，比如需要審查代碼的窮人。

如果可以不斷地將特徵分支集成到主線中，那麼特徵分支必須具有有用的，工作的，測試的和記錄的工作。如果有的話，那些可以被切割成自己的分支。

我坦率地承認我可能會過分解讀這一點，但在文章中可能講的一個缺陷是，樹枝被命名爲人而不是功能。這意味着每個分支都是爲了「無論Jim在做什麼」而不是「添加藍色小部件」。這意味着一些發展問題......

功能和分支由個人或團隊擁有
分支不是離散特徵
- 代替，分支是個人遊樂場
- 與沒有定義的功能，他們可以繼續下去
開發是在孤島中完成的
- 個人不說話，對方經常
- 個人不上分支
- 個人不談論他們的變化一起工作，直到整合

很多，這不是一個技術問題而是一個社會問題。其中大部分可以通過強力使用與版本控制強有力聯繫的良好問題跟蹤器（如Github's）來解決。主要的變化是：

分支應該是定義功能
開發商前，應報告問題去關閉和做一堆的工作

沒有人「擁有」的功能（儘管它們可能是負責它）

不幸的是，第二個是由大多數項目的錯誤跟蹤政策不鼓勵。在報告錯誤之前準備好補丁程序的願望是非常強烈的。

良好的分支管理需要良好的社會化，這是由良好的版本控制集成和歡迎策略的問題跟蹤器促進的。

來源

2011-10-31 22:56:51 Schwern

刪除它，如果你不需要它了。如果您稍後意識到，您再次需要它，您可以再次創建它。而且因爲你將變化合併到「後備箱」中，沒有任何東西丟失。

來源

2011-10-31 20:45:47 KingCrunch

唯一的原因，我可以看到，你會希望保持它的周圍是：

你想，當你在它上次工作的歷史。
您可以推斷何時開始開發。

來源

2011-10-31 20:48:41 Andy

即使沒有實際的分支指向提交，您也可以通過查看歷史記錄來獲得這兩者。沒有真正的理由保持分支，當它的工作完成並且合併到其他分支。 – poke

同意。但是，我認爲看到一個有用的分支名稱會更容易，而不是反向分析分支從提交消息所做的。 – Andy

兩件事情要考慮：

也許你應該降落面前有基礎重建這些分支到主（或地方）尖端的習慣。這樣，它們就像KingCrush所建議的那樣嚴格冗餘，如果發現問題，可以在以後重新創建它們。
使用rename可以標記您不確定的分支是否需要再次使用特定的前綴，以便您可以在知道不想過時的情況下快速掃描它們到分支列表中功能分支。

您可以使用這些技術的一些混合，例如，總是重新命名，然後將分支foo重命名爲landed-foo，然後在設定的時間間隔後（比如說一次發佈或30天）刪除landed-foo分支。

請注意，如果您沒有重新綁定（並對重定版本運行任何測試），則無法確定發現後發現的錯誤實際上是否已在開發的代碼中，而不是由影響造成的在開發之後合併它，所以在這種情況下，你可能想保留一段時間的分支。這種情況會隨着侵入性/非常大的變化而發生，不像您的問題情景。

來源

2011-10-31 20:50:51 tialaramex

重新制作並不總是一個好主意，因爲它破壞了方式，功能被開發出來。正確合併絕對沒有壞處，而git實際上是爲了處理廣泛的分支和合並而開發的。在稍後的歷史記錄中顯示清晰的分支會向您顯示該功能是單獨開發的，如果需要，您可以稍後再輕鬆識別它。同樣，刪除分支也是完全安全的，因爲它們只是指向歷史記錄中的提交的指針。刪除分支不會刪除它所屬的歷史記錄;歷史將始終顯示分支/合併。 – poke

關於Git和分支的好處是每個分支本質上是一個指向提交的指針。一旦你合併了你的分支，用於形成分支的提交現在成爲主要歷史的一個組成部分。

        your branch 
            main 
             | 
    (main) -------x----x----x-x---x----x 
        \    /
    (your branch) \--x--x-x--x-x---/

此時，如果刪除了使用「混帳分支-d」你的分支，你留下了：

        main 
             | 
    (main) -------x----x----x-x---x----x 
        \    /
    (your branch) \--x--x-x--x-x---/

正如你所看到的，從你的分支提交仍然安全。所有改變的是名爲「你的分支」的指針已被刪除。

請注意，如果你沒有合併到main中，那麼「git branch -d」會失敗。如果強制在這一點上刪除了它，你會留下：

        main 
            | 
    (main) -------x----x----x-x---x--x 
        \ 
    (your branch) \--x--x-x--x-x

由於在此階段沒有分支指針，提交被「晃來晃去」，將被刪除在下一次混帳做它的垃圾採集。長話短說，如果你的分支已經合併，你可以並且應該刪除它。如果它沒有合併，你不應該。

來源

2011-10-31 23:20:04 Carl

讓git分支「變老」有什麼危害嗎？

回答

相關問題