git rebase -i

軟件開發混亂。 如此多的錯誤轉彎，拼寫錯誤得到糾正，快速的hack和錯誤糾正可以在以后發現的過程中發現一次又一次的錯誤。 使用版本控制，您可以清晰地記錄在創建“完美”最終產品（準備好向上游提交的補丁）的過程中進行的每一次錯誤操作和更正的原始記錄。 就像電影的票房一樣，它們有些尷尬，有時還很有趣。

如果可以使用版本控制定期將您的工作保存在航路點，然后準備好要提交以供審閱的東西，則可以隱藏所有這些私人起草工作，而只需提交一份完整的補丁？ 認識git rebase -i ，這是重寫歷史記錄的完美方法，使每個人都認為您是第一次生成完美的代碼！

git rebase做什么？

如果您不熟悉Git的復雜性，這里是簡要概述。 在幕后，Git將項目的不同版本與唯一標識符相關聯，該唯一標識符由父節點唯一標識符的散列以及新版本與其父節點之間的差異組成。 這會創建一棵修訂樹，每個簽出項目的人都會得到自己的副本。 不同的人可以在不同的方向進行項目，每個方向都可能從不同的分支點開始。

^{左側“原始”存儲庫中的master分支，右側是您的個人副本上的private分支。}

git merge ，另一個是使用git rebase 。 它們以不同的方式工作。

當您使用git merge時 ，將在master分支上創建一個新提交，其中包括來自原始位置的所有更改以及所有本地更改。 如果存在任何沖突（例如，如果其他人更改了您也在使用的文件），則將標記這些沖突，并且您有機會在將該合并提交提交到本地存儲庫之前解決沖突。 當您將更改推回父存儲庫時，所有本地工作將顯示為Git存儲庫其他用戶的分支。

但是git rebase的工作方式有所不同。 它回滾您的提交，并從master分支的頂端再次重放這些提交。 這導致兩個主要變化。 首先，由于您的提交現在正在分支到另一個父節點，因此將重新計算其哈希值，并且克隆您的存儲庫的任何人現在都可能擁有該存儲庫的損壞副本。 其次，您沒有合并提交，因此在將更改重播到master分支上時會識別出任何合并沖突，因此您需要先進行修復，然后再進行基礎調整。 現在，當您進行更改時，您的工作不會出現在分支上，并且看起來您是從對主分支的最新提交中寫入所有更改的。

^{合并提交（左）保留歷史記錄，而合并（右）則重寫歷史記錄。}

但是，這兩個選項都有缺點：在準備共享代碼之前，每個人都可以在本地解決問題時看到所有涂鴉和編輯內容。 這是git rebase的--interactive （或簡稱-i ）標志出現在圖片中的地方。

引入git rebase -i

git rebase的最大優點是它可以重寫歷史記錄。 但是，為什么只假裝您后來分支了呢？ 有一種更進一步的方法可以重寫您如何準備就緒的代碼： git rebase -i ，交互式git rebase 。

此功能是Git中的“魔術時光機”功能。 該標志允許您在進行基礎更改時對修訂歷史進行復雜的更改。 您可以隱藏自己的錯誤！ 將許多小的更改合并到一個原始功能補丁中！ 重新排列版本歷史記錄中的內容！

當您運行git rebase -i時 ，您將獲得一個編輯器會話，其中列出了所有正在被重新構建的提交以及可以對其執行的操作的多個選項。 默認選擇是pick 。

• Pick會在您的歷史記錄中保留提交。
• Reword允許您更改提交消息，也許可以解決錯字或添加其他注釋。
• 編輯允許您在重播分支的過程中對提交進行更改。
• Squash將多個提交合并為一個。
• 您可以通過在文件中移動來重新排列提交。

完成后，只需保存最終結果，即可執行重新設置基準。 在您選擇修改提交的每個階段（使用reword ， edit ， squash或發生沖突時），變基都會停止并允許您在繼續之前進行適當的更改。

上面的示例導致“單一代碼錯誤修復”和“在各處集成新標頭”被合并為一個提交，而“文檔網站的新標頭”和“ D'oh-錯字。已固定”被合并為另一個提交。 就像魔術一樣，進入其他提交的工作仍在您的分支上，但是相關的提交已從您的歷史中消失了！

這使得使用git send-email或通過使用新整理的補丁集針對父存儲庫創建拉請求輕松地向上游項目提交干凈補丁。 這具有許多優點，包括使您的代碼更易于查看，更易于接受和更易于合并。

翻譯自: https://opensource.com/article/20/4/git-rebase-i

git rebase -i

總結

以上是生活随笔為你收集整理的git rebase -i_git rebase -i改变生活的魔力的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。