© Postmodern Studio/Shutterstock.com
許多開發人員依賴開源代碼管理系統 Git。從共享代碼到編輯已部署程序的特定功能，Git 在許多方面讓生活變得更輕鬆。兩個最常用的命令是 Git merge 和 Git rebase。它們服務於相同的最終目標，將來自多個開發人員的更改集成到一個實體中，但有很大的不同。
本文重點介紹這兩個命令之間的差異、它們的應用程序以及每個命令的優點和缺點。但在我們研究全面比較之前，讓我們解釋一下我們將在整篇文章中引用的三個重要術語:提交、分支和合併。
Commit
提交基本上是代碼和對代碼所做的更改存儲在 Git 中。例如，如果開發人員在 Git 上保存了三個 Python 文件，這些文件將被分組為一個提交並分配一個提交 ID 號。當開發人員或其他開發人員通過添加更多 Python 文件對代碼進行更改時，更改將保存在不同的提交中並使用新的 ID。簡而言之，Git 上的每個更改都會生成一個提交。
分支
分支是代碼的獨立版本。 Git 上有兩種類型的分支:master 分支和feature 分支。 以一個網站為例； master 分支是存儲已部署站點代碼的地方，通常是默認情況下。
如果開發人員想要向網站添加功能，他們會將整個代碼複製到不同的“文件夾”中，他們可以在不影響網站的情況下進行修補。這個“文件夾”在 Git 上被稱為特性分支。完成後，開發人員隨後“合併”功能分支和主分支，以便前者的更改反映在後者上。
合併
在 Git 上，合併是將一個分支的變化包含到另一個分支中的過程。它可以通過兩種方式完成，Git merge 和 Git rebase。
現在，讓我們比較這兩種方法。
Git Merge 與 Rebase:並行-Side Comparison
Git Merge 與 Rebase:有什麼區別?
現在，讓我們定義這兩種技術，並詳細說明它們之間的區別。
Git合併:定義
這是 Git 上的合併技術之一。它保持功能分支上的提交日誌完整，同時在主分支上創建新的提交。
舉個例子，主分支有提交 1、2 和 3，而功能分支有提交 X 和 Y。當開發人員執行 Git 合併時，功能分支保留，但在主分支上，然後兩個提交合併形成提交 4。這樣做時，更改的日誌保留在功能分支上.
Git Rebase: 定義
這是一種合併技術，它通過為來自特性分支的每個提交創建單獨的提交來將特性分支集成到主分支上。然後它會刪除功能分支。
例如，對於具有 3 個提交的主分支和具有 X 和 Y 提交的功能分支，Git Rebase 命令會將提交 X 和 Y 添加到主分支作為提交 4 和 5，然後丟棄功能分支。結果，它沒有留下任何特徵分支存在的證據。
兩者之間的主要區別在於它們處理提交歷史記錄的方式。 Git Merge 將兩個或多個更改的歷史記錄連接成類似鏈節的結構，而 Git rebase 將這些更改重新應用到主分支而不保留它們的歷史記錄，給人一種線性日誌的印象。
優點Git Merge and Rebase
Git Merge 命令保留現有分支，留下所有日誌的歷史記錄。它也簡單、直接且易於使用。事實上，它是 Git 上使用的第一種合併，這解釋了為什麼它在名稱中保留了“合併”。
由於 Git Merge 給出了更改的時間順序並提供了更改的上下文，其他開發人員可以更全面地了解每次更改發生的時間和方式。這不僅使開發過程易於跟進，而且易於發現和糾正錯誤。
另一方面，Git Rebase 重寫了代碼的更改歷史；因此，它通過將中間提交合併為一個來簡化原本可能是複雜的歷史記錄。它的線性結構減少了混亂，同時也最大限度地減少了繁忙分支和存儲庫中常見的提交噪音。
在 Git Rebase 和 Git Merge 之間做出選擇完全取決於您的具體工作需求，包括您的團隊規模和所需的透明度級別。
©Sharaf Maksumov/Shutterstock.com
Git Rebase 和 Git Merge 的缺點
通過保留所有更改的歷史記錄，Git Merge 會產生詳盡的 Git 日誌，如果不這樣做，它會變得混亂且無用妥善維護。它不是非常用戶友好，尤其是在主分支處於活動狀態的情況下。
另一方面，Git Rebase 命令旨在解決 Git Merge 的這些缺點，它確實做到了。然而，它也有自己的缺點。
它將功能提交最小化為它創建的主分支上的較小提交，使其他開發人員無法知道何時以及如何進行更改。
另一個缺點是解決衝突。在 Rebase 上，您必須按照衝突的創建順序解決衝突，因此，您可以一個接一個地解決它們，而不是像 Git Merge 那樣一次全部解決。
最後，Git Rebase 可以不接受拉取請求，這是用於查看另一個開發團隊成員所做的微小更改的命令。
但是，可以避免使用 Git Rebase 命令的一些常見問題:
避免在遠程發布的分支上使用 rebase 命令，除非你確定沒有其他人在該分支上工作。在 rebase 之前創建你將要 rebase 的分支的備份。這將使您很容易比較變化，並在必要時返回到基準前狀態。
Git Merge vs. Rebase: 4 Must-Know Facts
Git Merge 將功能分支的內容添加到基礎分支上，而不丟棄功能分支，因此保留了更改的歷史記錄。Rebase 丟棄功能分支及其相關歷史。Rebase 將功能分支移動到主分支的頂端，但為其內容提供新的 ID 號。Git Rebase 比 Git Merge 更複雜地撤消。
Git Merge 與 Rebase:哪個更好?您應該使用哪一個?
在某些時候，您將不得不在這些分支策略之一之間做出選擇，那麼您應該選擇哪一個?好吧，這個問題的答案取決於一個關鍵因素:您的團隊。
小團隊:如果單獨或在小團隊中處理項目，那麼 Git Rebase 是一個不錯的選擇。然而，Git Merge 對於大型團隊來說是更好的選擇。透明度:是否需要跟踪每個開發人員所做的所有更改?如果需要透明性，即使單獨工作，Git Merge 也是可以使用的命令。日誌訪問:正如透明性一樣，Git Merge 是要採用的策略；團隊中的其他人必須了解每個提交的來源。但是，如果需要使此類日誌不可訪問，請使用 Git Rebase。在您不希望其他團隊成員看到的分支上工作時，這是一個合適的選擇。
同時使用 Git Merge 和 Git Rebase
大多數精通 Git 的開發人員通常在同一個項目中使用這些技術。
考慮一個3分支的場景:一個主分支，一個特性分支，以及特性分支的一個子分支。開發人員可以對子分支進行更改，然後在使用 Git Merge 將功能分支合併到主分支之前將其變基到功能分支。這樣，其他開發人員只能看到開發人員在特性分支上所做的更改，而永遠看不到特性分支的子分支上做了什麼。簡單地說，你可以在私有分支上使用 Git Rebase，然後使用 Git merge 命令將所有提交整合到主分支上。
其他注意事項
一個好的分支策略應該允許開發人員按照自己的節奏工作，只添加對主要時間線有意義的內容。為實現這一目標，重要的是讓開發人員在獨立的並行團隊中工作，這些團隊在個人級別使用 Git Rebase，在團隊級別或主要分支使用 Git Merge。
Git 能力級別團隊也是一個重要的考慮因素。那些只有基礎的人應該堅持使用 Git Merge 命令或學習 Git Rebase 的細微差別，然後再將其應用到項目中。
因此，決定使用 Git Merge 還是 Git Rebase 並不在於是否使用 Git Rebase。一種策略優於另一種策略，但取決於開發團隊的動力。 Git 能力水平、組織結構、目標和團隊理念是決定性因素。
Git Merge 與 Rebase:何時使用每種 FAQ（常見問題）
Git Rebase 最大的缺點是什麼?
你看不到其他開發者在上游所做的更改。這樣，您最終可以解決上游其他人已解決的相同問題。
什麼是 Git 重置?
此命令撤消所有更改通過在提交後刪除所有本地更改來在特定提交後在存儲庫上創建。
什麼是交互式變基?
這是比Git Reset 命令，尤其是在使用 Git Rebase 時。它允許更改單個提交、刪除提交、更改提交順序和壓縮提交。它是使 Git 提交歷史變得線性且更易於理解的強大命令。
“Squash and merge”和“rebase and merge”之間有什麼區別?
當單個功能分支有多個不再有用的提交時，應用壓縮和合併。因此，您將它們組合成一次提交到 master 分支上。它保留更改但從歷史記錄中刪除提交。
另一方面，變基和合併將整個功能分支移動到主分支並重寫提交歷史。
我應該學習如何使用 Git Rebase 嗎?
了解如何使用 Git Rebase 將加深您對 Git 的了解並提高您作為開發人員的源代碼管理能力。
p>
是否可以同時使用Git Merge和Git Rebase?
按順序，可以。同時，不是真的。一個必須先於另一個。請參閱“哪個更好?”有關如何在同一項目中使用兩者的更多信息，請參閱本文的部分。
Git 是一個安全的源代碼控制系統嗎?
因為它是開源平台，安全級別低。但是，有多種方法可以保護您在 Git 上的工作，例如不提交敏感信息、保護對 Git 存儲庫的訪問、保持 Git 更新以及簽署您的工作。
什麼是最好的Git 的替代品?
有很多這樣的替代品，但最好的取決於您的需要。它們包括 Mercurial、SourceForge、Perforce 和 Bitbucket 等。