Git 合併策略：Git Merge 和 Git Rebase 簡介（他們用來做什麼以及何時使用它們）
小編推薦： ofollow,noindex">掘金是一個面向程式員的高質量技術社群，從 一線大廠經驗分享到前端開發最佳實踐，無論是入門還是進階，來掘金你不會錯過前端開發的任何一個技術乾貨。
作為一名開發人員，我們許多時候必須在 Merge和 Rebase 之間進行選擇。 我們從網際網路上獲得的所有參考文件文章，幾乎都告訴我們“不要使用 Rebase，它可能會導致嚴重的問題。”在這裡，我將解釋什麼是 merge 和 rebase，為什麼你應該（或者不應該）使用它們，以及如何做。
Git Merge 和 Git Rebase 其實是都是為了完成同樣的目的。 它們旨在將來自多個分支的更改整合到一個分支中。 雖然最終目標是相同的，但這兩種方法以不同的方式實現。
這個問題在 Git 社群中引起了分歧。有些人認為應該總是使用 rebase ，而另一些人則認為應該總是使用 merge 。雙方都有一些令人信服的好處。
Git Merge
對於使用版本控制系統的開發人員來說，merge 是一種常見的做法。不管建立分支是為了測試、修復 bug 還是其他原因，將提交更改合併到另一個位置。 更具體地說，merge 獲取源分支的內容並將它們與目標分支整合。 在此過程中，僅更改目標分支。 源分支歷史保持不變。
圖注：Merge Master -> Feature branch
優點
- 簡單而又熟悉
- 保留完整的歷史和時間順序
- 維持分支的上下文
缺點
git bisect
怎麼做
使用 checkout 和 merge 命令將 master 分支合併到 feature 分支中。
$ git checkout feature $ git merge master (or) $ git merge master feature
這將在 feature 分支中建立一個新的 合併(Merge)提交 ，其中包含兩個分支的歷史記錄。
Git Rebase
Rebase 是將更改從一個分支整合到另一個分支的另一種方法。 Rebase 將所有更改壓縮為單個“補丁”。然後它將補丁整合到目標分支上。
與 merge 不同，重定位使歷史變得扁平，因為它將完成的工作從一個分支轉移到另一個分支。在這個過程中，不需要的歷史記錄被消除。
Rebases 是更改應從層次結構頂部向下傳遞的方式，並且 Merge 是它們向上流回的方式
圖注：Rebase feature 分支到 master
優點
- 簡化可能複雜的歷史記錄
- 操作單個提交很容易（例如還原它們）
- 避免分支頻繁合併提交，頻繁回購。
- 通過將它們作為單個提交來清理中間提交，這對DevOps團隊很有幫助
缺點
- 將該功能分解為少量提交可以隱藏上下文
- 在團隊合作時，重新定位公共儲存庫可能會很危險
- 可能帶來更多的工作：使用rebase 來保持您的 feature 分支始終更新
- 使用遠端分支 Rebase 需要強制推送。人們面臨的最大問題是他們強制推送，但還沒有設定 git push 預設值。這會導致對本地和遠端上具有相同名稱的所有分支進行更新，這是非常可怕的，並且處理起來非常糟糕。
如果您錯誤地 rebase ，並無意中重寫歷史記錄，則可能會導致嚴重問題，因此請確保您知道自己在做什麼！
怎麼做
使用以下命令將 feature 分支 Rebase 到主分支上。
$ git checkout feature $ git rebase master
這會將整個 feature 分支移動到主分支的頂部。它通過為 原始(feature)分支中的每個提交建立全新的提交來重寫專案歷史。
互動式的 rebase
這允許在將提交移動到新分支時更改提交。 這比自動 rebase 更強大，因為它提供了對分支的提交歷史的完全控制。 通常，這用於在將 feature 分支合併到主分支之前，清理雜亂的歷史記錄。
$ git checkout feature $ git rebase -i master
這將通過開啟編輯器，列出即將移動的所有提交。
pick 22d6d7c Commit message#1 pick 44e8a9b Commit message#2 pick 79f1d2h Commit message#3
這精確定義了 rebase 執行後分支的確切內容。通過重新排序實體，可以使歷史記錄看起來像您想要的任何內容。例如，可以使用 fixup ， squash ， edit 等命令代替 pick 。
我們應該使用哪一個
哪一個最好？ 專家建議什麼？
由於每個團隊都不同，因此很難概括和哪一個最好。 但我們總得找個地方開始。
團隊在設定 Git rebase 與 merge 策略時，需要考慮幾個問題。因為事實證明，哪種工作流策略好，這取決於你的團隊。
考慮跨組織的重基和Git能力級別。確定相對於可追溯性和合並歷史，您更重視重基的簡單性的程度。
考慮整個組織的 rebase 和 Git能力水平。 相對於 merge 的可追溯性和歷史記錄，確定您重視 rebase 的簡單程度。
最後，應該在清晰的分支策略的上下文中考慮關於 merge 和 rebase 的決策(請 參閱本文 以瞭解關於分支策略的更多資訊)。成功的分支策略是圍繞團隊組織設計的。
我推薦什麼？
隨著團隊的增長，使用始終 merge 策略管理或跟蹤開發更改將變得非常困難。要有一個清晰易懂的提交歷史記錄，使用 Rebase 是合理和有效的。
通過考慮以下情況和指南，您可以充分利用 Rebase ：
你在本地開發：如果您還沒有與其他人合作。此時，你應該更喜歡 rebase 而不是 merge 以保持歷史的整潔。如果您擁有儲存庫的個人分支並且未與其他開發人員共享，那麼即使您已經推送到分支之後，也可以安全地進行 rebase 。
您的程式碼已經準備好接受評審：您建立了一個 pull 請求。其他人正在評審您的工作，並可能將其提取到他們的分支中進行本地評審。此時，您不應該 rebase 你的工作。您應該建立 rework 提交併更新您的 feature 分支。這有助於拉取請求中的可追溯性，並防止意外的歷史記錄破壞。
評審已經完成，準備整合到目標分支中。恭喜你!您將要刪除您的 feature 分支。考慮到其他開發人員從現在起不會在這些更改中進行獲取合併，這是您清理歷史記錄的機會。此時，您可以重寫歷史記錄並摺疊原始提交，並將那些討厭的’pr rework’和’merge’提交到一小組重點提交中。為這些提交建立顯式合併是可選的，但有價值。它記錄了該功能何時升級為 master 。
結論
我希望這這篇文章給出了關於 Git merge 和 Git rebase 的一些見解。 merge 與 rebase 策略總是值得商榷。 但也許這篇文章將有助於消除您的疑慮，並允許您採用適合您團隊的方法。
英文原文：https://medium.freecodecamp.org/an-introduction-to-git-merge-and-rebase-what-they-are-and-how-to-use-them-131b863785f