如何使用 Git 合併
已發表: 2023-01-03
Git 使用分支來隔離開發流，以防止穩定版本分支被污染。 將分支中的工作納入主流意味著合併分支。 這是你如何做的。
什麼是 Git 中的合併？
準備在 Git 中合併一個分支
執行合併
在 Git 中執行快進合併
如何解決 Git 中的合併衝突
一切最終合併
什麼是 Git 中的合併？
Git 旨在使分支變得簡單和快速。 與其他版本控制系統相比，在 Git 上創建分支是一件小事。 特別是在多開發者項目中，分支是 Git 的核心組織工具之一。
分支沙箱新的開發工作，以便可以修改或添加代碼而不影響其他分支中的代碼，尤其是主分支或主分支。 這通常包含代碼庫的穩定版本。
將這些更改與穩定代碼版本隔離是非常有意義的。 但是新代碼遲早會經過測試、審查和加蓋橡皮圖章，以便被納入 master 分支。 此時，您需要將您的分支合併到 master 分支中。
實際上，分支可以有子分支，因此您可能會將您的分支合併到其他分支而不是主分支。 請記住，合併總是採用一個分支並將其合併到目標分支中，無論該分支是什麼。 如果你想將你的 master 分支合併到另一個分支，你甚至可以這樣做。
與 Git 中的大多數操作一樣，您在本地存儲庫中執行合併並將它們推送到遠程存儲庫。
準備在 Git 中合併一個分支
我們有一個帶有本地 Git 存儲庫和遠程 Git 存儲庫的小型開發項目。 我們從“master”分支創建了一個名為“bugfix14”的分支，並致力於解決一個錯誤。
這項工作已經完成，我們已經測試了我們的代碼。 一切都按預期工作。 我們希望將這些更改滾動到 master 分支中，以便我們的修復成為軟件下一版本的一部分。
在我們執行合併之前需要做一些準備工作。 我們需要確保目標分支——在本例中為“主”分支——以及我們要合併到其中的分支都是最新的。
為此，我們將使用git status命令。
混帳狀態
- 在分支 bugfix14 上：這是我們當前的分支。
- Your branch is up to date with 'origin/bugfix' ：我們本地存儲庫中的分支與遠程存儲庫中的分支具有相同的提交歷史。 這意味著它們是相同的。
- nothing to commit暫存區中沒有未提交的更改。
- 工作樹清理：工作目錄中沒有未暫存的更改。
所有這些都表明該分支是最新的，我們可以繼續進行。 如果其中任何一個表明存在更改，我們就需要暫存它們、提交它們並將它們推送到遠程。 如果其他人處理過這些文件，我們可能需要從遠程存儲庫中提取他們的更改。
檢查我們要合併到的分支可以簡化合併過程。 它還允許我們驗證它是最新的。 讓我們看看主分支。
git結帳大師
混帳狀態
我們得到相同的確認，即“master”分支是最新的。
相關：如何選擇適合您團隊的 Git 工作流和分支模型
執行合併
在我們合併之前，我們的提交看起來像這樣。
“bugfix14”分支是從“master”分支分支出來的。 在創建“bugfix14”分支後，已經提交到“master”分支。 “bugfix14”分支有幾個提交。
我們已經確保我們的兩個分支是最新的，並且我們已經檢查了“master”分支。 我們可以發出命令將“bugfix14”分支合併到“master”分支。
git 合併 bugfix14
合併發生。 “bugfix14”分支仍然存在，但現在在該分支中所做的更改已合併到“master”分支中。
在這種情況下，合併命令執行三向合併。 只有兩個分支，但涉及三個提交。 它們是任一分支的負責人，以及代表合併操作本身的第三次提交。
要更新我們的遠程存儲庫，我們可以使用git push命令。
推
有些人喜歡在合併後刪除分支。 其他人則小心翼翼地保存它們，作為項目真實發展歷史的記錄。
如果要刪除分支，可以使用帶有-d （刪除）選項的git branch命令。
git branch -d bugfix14
要刪除遠程存儲庫中的分支，請使用以下命令：
git push origin --delete bugfix14
您將擁有線性提交歷史記錄，但它不會是真實的歷史記錄。
相關：如何刪除本地和遠程存儲庫上的 Git 分支
在 Git 中執行快進合併
如果您還沒有對“master”分支進行任何提交，您的歷史記錄將如下所示。 如果您重新設置了開發分支的基礎，它也會看起來像這樣，以便它附加到“master”分支的末尾。
因為“master”分支中沒有提交，要合併“bugfix15”分支，Git 所要做的就是將“master”頭指針指向“bugfix15”分支的最後一次提交。
我們可以使用通常的git merge命令：
git 合併 bugfix15
這給了我們這個結果。
這與此相同：
這與此相同：
只要有可能，Git 就會執行快進合併。 如果提交到“主”分支意味著快進合併是不可能的，Git 將使用三向合併。
您不能強制執行快進合併 — 畢竟這可能是不可能的 — 但您可以聲明它是快進合併或什麼都不是。 有一個選項指示 Git 在可能的情況下使用快進合併，但在不能的情況下不進行三向合併。 該選項是--ff-only （僅快進合併）。
這會將“bugfix15”分支合併到“master”分支，但前提是可以進行快進合併。
git merge --ff-only bugfix15
如果不可能，Git 會抱怨並退出。
git merge --ff-only bugfix16
在這種情況下，已經有提交到“master”分支，所以快進合併是不可能的。
如何解決 Git 中的合併衝突
如果在兩個分支中更改了同一文件的相同部分，則無法合併分支。 需要人工交互來解決衝突的編輯。
在這裡，我們對名為“bugfix17”的分支中名為“rot.c”的文件進行了更改，我們希望將其合併到“master”分支。 但是“rot.c”在“master”分支中也發生了變化。
git 合併 bugfix17
當我們嘗試合併它時，我們會收到一條警告，提示存在衝突。 Git 列出了衝突的文件，並告訴我們合併失敗。 我們可以使用--abort選項完全退出：
git 合併 --abort
但是解決合併並不像聽起來那麼可怕。 Git 已經做了一些工作來幫助我們。 如果我們編輯其中一個衝突文件——在我們的例子中，我們只有一個——我們會發現衝突的代碼部分為我們突出顯示。
每個衝突由七個小於字符“ <<<<<<< ”和七個大於字符“ >>>>>>> ”界定，它們之間有七個等號“ ======= ” .
- 等號上方的代碼來自您要合併到的分支。
- 等號下面的代碼是您要合併的分支的代碼。
您可以輕鬆地搜索一組七個字符中的一組，並在整個文件中從衝突轉移到衝突。 對於每個衝突，您需要選擇要保留的編輯集。 您必須編輯掉您拒絕的代碼，以及 Git 添加的七字符行。
我們將保留“bugfix17”分支中的代碼。 編輯後，我們的文件看起來像這樣。
我們現在可以繼續進行合併。 但請注意，我們使用commit命令來執行此操作，而不是merge命令。
我們通過暫存文件並照常提交來提交更改。 我們將在進行最終提交之前檢查狀態。
git 添加 rot.c
混帳狀態
git commit -m "合併 bugfix17"
合併完成。 我們現在可以將其推送到我們的遠程存儲庫。
相關：如何修復、編輯或撤消 Git 提交（更改 Git 歷史）
一切最終合併
最終，所有分支都需要合併，這樣它們中的更改就不會成為孤立的和被遺忘的。
合併分支很容易，但在繁忙的大型團隊中處理衝突可能會變得複雜。 解決衝突可能需要每個開發人員的輸入，只是為了解釋他們的代碼做了什麼以及他們為什麼進行更改。 您需要了解這一點，然後才能就保留哪些編輯做出明智的決定。
遺憾的是，Git 對此無能為力。
相關：您應該使用 GUI Git 客戶端嗎？