最佳實踐編輯使用git對舊提交進行更改

Question

我在大型項目設置中使用git的經驗不足，但我剛剛通過了這個stunning visual tutorial。有一件事我不明白的是，在一次練習中，它會讓您對先前提交的代碼（更改圖像的尺寸）進行小小更改。爲此，您需要對提交進行重新排序，以便將添加舊維的代碼放在最前面，修改該提交，然後將所有內容重新排列。

其結果是，您沒有額外的小修改來修復圖像的尺寸，但是您會看到一大堆所有修飾或櫻桃採摘的垃圾文物。

本教程中介紹的技術與簡單添加新提交相比有何優勢？或者，如果在這種特定情況下它是過度殺傷性的，但在其他一些情況下，有一個很好的理由，那麼什麼是一個例子，爲什麼它在它的上下文中沒有矯枉過正？正如我所看到的，這只是教條，但由於我沒有經驗，所以我肯定我錯了。

Answer 1

經驗法則：如果我們想要更改的提交以前被推送到共享存儲庫，請不要修改/重寫/重寫歷史記錄。只需在分支上執行另一個提交，然後推送它。

---

所以我們說的承諾（C1）你必須改變只在一個地方分支。 C1添加了一張圖片和一些與圖片鏈接的更改。

如果你再拍提交C2頂部（只改變圖片），如果你以後想櫻桃採摘通過C1帶來的要素的內容，你要摘櫻桃都C1（初始畫面等變化）和C2（更新後的圖片）。

儘管如此，在大多數日常情況下，您只需做另一次提交。這樣的「特色分支製作」在對開源項目提出拉取請求之前可能是有用的，因爲它使您的提交變得乾淨和原子化，因此更容易查看。

Answer 2

一個原因是使提交歷史記錄更容易理解。

這與將程序編寫爲不是針對計算機，而是針對另一個人（有更多評論，更少評論甚至沒有評論 - 但每個人都同意清晰度都很好）的論點類似。 這就像一篇散文的論文草稿和紅筆更正之間的區別，以及新的草稿，沒有所有分散的錯誤開始和錯誤而被重寫。

在您提交新功能，提交其他幾個功能，然後對之前的功能（bugfix/typo/etc）進行小修改的情況下，以實際發生的方式保存歷史記錄可能會更容易理解，因爲你記得做了這個修復（或者可能形成一個敘述，如果你第一次看到最初的版本，變化更有意義;它取決於它是否更清晰） - 但是對於其他人看到它的新鮮事物通常是不必要的複雜。對於他們來說，看起來好像該功能首先正確完成似乎更簡單。

最後，他們對重新排序，修改然後重新排序的具體方法似乎對我來說過於複雜。交互式地（git rebase -i parent_of_commit_to_be_changed）重新標記，標記提交修改（通過改變「pick」到「edit」或「e」），編輯文件等，遵循git給你的指示。

（NB：這只是推之前準備自己的私人倉庫- 推後爲@GuillaumeDarmont說，修改歷史製造麻煩的人誰是已經獲取/把它）。