本文繼續我們的“高級git”系列。在Twitter上關注我們，或訂閱我們的新聞通訊以獲取有關未來文章的最新信息！
有效的GIT分支對於開發人員至關重要。我上一篇文章詳細介紹了分支策略，GIT的分支模型，分支類型和常見的工作流程。核心好處：孤立的工作區（分支）顯著改善了版本控制。
本文著重於整合分支機構 - 將代碼有效地合併回主開發線路。我們將探討兩種關鍵方法：合併和重新構造。
git merge和git rebase都解決了相同的問題：將一個分支的變化整合到另一個分支。但是，他們的方法差異很大。讓我們先檢查合併。
git merge命令集成了分支。想像一下branch-B帶有新提交；合併成branch-A ：
<code>$ git checkout branch-A $ git merge branch-B</code>
這會在branch-A上創建一個新的合併提交，並連接兩個分支歷史。 GIT標識了三個關鍵提交：
git結合了這些承諾以實現整合。簡化的方案（ branch-A以來分支以來沒有提交的情況）導致“快速前進”合併 - 有效地添加了branch-B的直接提交。
但是，在大多數實際情況下，兩個分支都獨立發展。然後，與開發人員創建的提交不同，GIT創建了合併提交來結合這些更改的合併，這是自動生成的獨特犯罪。了解此自動合併需要分析完整的分支歷史。
開發人員創建的提交經過精心構建，其中包含相關的更改和信息信息。相反，合併提交會自動連接分支，而不一定代表一系列具有語義連貫的更改。
重新打造提供了合併的替代方法。它本質上不是“更好”，只是不同的。您可以僅通過合併而成功管理git。但是，理解重新打擊提供了寶貴的選擇。
重新啟動避免自動合併提交，創建線性項目歷史記錄，消除分支差距。
讓我們將branch-B重新為branch-A ：
<code>$ git checkout branch-A $ git rebase branch-B</code>
該過程涉及三個步驟：
branch-A上提交。branch-B的提交：應用branch-B的提交，暫時對齊兩個分支。branch-A的提交：暫時存儲的branch-A提交被重新應用於branch-B的提交，創建了線性歷史記錄。結果：簡化的歷史沒有合併。
至關重要的是，重新編寫命令歷史。雖然內容保持不變，但提交的父母會改變，生成新的SHA-1哈希。
這對於未出版的提交是可以接受的。但是，重新出版的提交是有風險的，有可能破壞基於原始提交的工作的合作者。
黃金法則：永遠不要反映公共分支機構！在集成到共享分支之前，請在本地使用重新打掃以清理歷史記錄。
合併和重新構造都是有價值的工具。合併歷史無損。重新設計精簡歷史，但需要謹慎對待發表的提交。
探索我免費的“高級GIT套件”，以深入了解GIT工具。
愉快的合併和重組！在下一個“高級git”部分中見！
以上是rebase與合併：整合GIT的變化的詳細內容。更多資訊請關注PHP中文網其他相關文章！
