重寫未發佈的歷史記錄有什麼缺點？

我在想，特別是在開發過程中「失敗的歷史」的缺點是什麼。一個着名的例子當然是git rebase -i/git merge --squash，但在「我想在將主要更改提交到主線之前清理我的提交歷史記錄」下的described here也是什麼。重寫未發佈的歷史記錄有什麼缺點？

我可以看到，導出補丁並將它們應用到另一個分支將失去該分支的「歷史」，但爲什麼該分支及其提交歷史記錄在合併之後會有用？

有人可以詳細說明爲什麼這些技術被認爲是「髒」嗎？爲什麼只要能夠將主要分支應用於初次更改的順序，最重要的是哪些順序？

來源

2012-06-10 user1447278

考慮改寫你的問題來「重寫未發表的歷史」。重寫人們可能已經建立分支機構等的事情有更多的缺點，這在你的情況下似乎並不相關。 – ThiefMaster

考慮一下：

* (master) Merge feature-branch into master 
|\ 
| * (feature-branch) Fix a comment typo 
| * Add comments 
| * Add feature task 3 
| * Consolidate feature tasks 1 and 2 
| * Add feature task 2 
| * Forgot a semi-colon 
| * Add feature task 1 
|/ 
* Older commit on master

與此：

* (master, feature-branch) Add feature 
* Older commit on master

第一個是的feature-branch一個（--no-FF）合併成master，並且底部是南瓜/將feature-branch重新拼寫到master。首先是非常詳細的，這將使迴歸測試更加專注，但如果您有很多功能分支，將會變得雜亂無章。如果你有很多功能，第二個是更清晰的閱讀，但失去了分支定義。你自己的方法將取決於項目的大小，團隊的規模等。

個人而言，我使用將其他人關心這個提交經驗法則。下游沒有人關心例如我在評論中修正了一個錯字。我通常我把之前把第一個例子弄成這個樣子（與rebase -i）：

* (master) Merge feature-branch into master 
|\ 
| * (feature-branch) Add feature task 3 
| * Add feature task 2 
| * Add feature task 1 
|/ 
* Older commit on master

分支歷史中的相關內容仍然是明顯的，其餘的是壓扁。

來源

2012-06-10 16:37:18 ellotheth

如果你沒有看到自己對歷史的任何用處，那麼沒有任何缺點。事實上，許多開發人員在單獨的分支（feature/1234）中創建新功能，然後將它們合併，然後將其重新綁定到develop分支並刪除功能分支。原因在於，通常情況下，如果您實現了一項功能，那麼您通常對後面的每個實施步驟都不感興趣，而是對整個功能感興趣。但是，您應該避免壓縮提交，它們沒有任何共同之處，僅僅是爲了節省提交。有很多提交也沒有缺點。

來源

2012-06-10 16:25:25 KingCrunch

除了管理生產質量代碼之外，您還可以將git視爲全產品全局無限延展撤消。「未發表的歷史」可能包括拼寫錯誤，沒有出現的實驗，只是因爲您當時在那裏並且可能晚些時候會分裂出來的次要無關修復，哪些不是。我從來沒有理解過對撤銷的不滿。

將您的重寫與您改寫的內容進行比較。如果新版本更好地滿足您的需求，那就更好了。如果原版中的某些內容符合新版本的需求，那麼這是一個缺點。特別是對於呆在你自己的回購中的未發佈的東西，你可以隨心所欲地處理這些東西。

來源

2012-06-10 16:26:35 jthill

重寫未發佈的歷史記錄有什麼缺點？

回答

相關問題