rebase與合併：整合GIT的變化

本文繼續我們的“高級git”系列。在Twitter上關注我們，或訂閱我們的新聞通訊以獲取有關未來文章的最新信息！

有效的GIT分支對於開發人員至關重要。我上一篇文章詳細介紹了分支策略，GIT的分支模型，分支類型和常見的工作流程。核心好處：孤立的工作區（分支）顯著改善了版本控制。

本文著重於整合分支機構 - 將代碼有效地合併回主開發線路。我們將探討兩種關鍵方法：合併和重新構造。

git merge和git rebase都解決了相同的問題：將一個分支的變化整合到另一個分支。但是，他們的方法差異很大。讓我們先檢查合併。

高級GIT系列：

• 第1部分：制定理想的吉特犯罪
• 第2部分：優化GIT分支策略
• 第3部分：簡化與拉請求的合作
• 第4部分：有效解決合併衝突
• 第5部分： rebase vs. Merge（您在這裡！ ）
• 第6部分：掌握互動式重新啟動
• 第7部分：挑選櫻桃的git提議
• 第8部分：利用反射儀恢復丟失的提交

了解GIT合併

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>

該過程涉及三個步驟：

1. 暫時刪除提交：在暫時存儲共同祖先之後在branch-A上提交。
2. 應用branch-B的提交：應用branch-B的提交，暫時對齊兩個分支。
3. 重新校長branch-A的提交：暫時存儲的branch-A提交被重新應用於branch-B的提交，創建了線性歷史記錄。

結果：簡化的歷史沒有合併。

rebasing的潛在陷阱

至關重要的是，重新編寫命令歷史。雖然內容保持不變，但提交的父母會改變，生成新的SHA-1哈希。

這對於未出版的提交是可以接受的。但是，重新出版的提交是有風險的，有可能破壞基於原始提交的工作的合作者。

黃金法則：永遠不要反映公共分支機構！在集成到共享分支之前，請在本地使用重新打掃以清理歷史記錄。

集成策略：合併與重生

合併和重新構造都是有價值的工具。合併歷史無損。重新設計精簡歷史，但需要謹慎對待發表的提交。

探索我免費的“高級GIT套件”，以深入了解GIT工具。

愉快的合併和重組！在下一個“高級git”部分中見！

高級GIT系列：

• 第1部分：制定理想的吉特犯罪
• 第2部分：優化GIT分支策略
• 第3部分：簡化與拉請求的合作
• 第4部分：有效解決合併衝突
• 第5部分： rebase vs. Merge（您在這裡！ ）
• 第6部分：掌握互動式重新啟動
• 第7部分：挑選櫻桃的git提議
• 第8部分：利用反射儀恢復丟失的提交

以上是rebase與合併：整合GIT的變化的詳細內容。更多資訊請關注PHP中文網其他相關文章！