Skip to main content

[Git] Git 合併策略


前言​

因為最近剛就職到第三家公司，用的是之前從沒用過的 fast-forward merge，之前每家公司也都用不一樣的策略，像是 rebase, squash, merge 等等， 所以想來整理一下 git 的合併策略，釐清概念和了解各種方式的優缺點

看完 ByteByteGo 的影片 後了解，主要分為兩個部分：

  • 將 main 的更新加到 feature
  • 將 feature 合回 main

因此下面會以這兩個部分不同的 Git 策略來做介紹



將 main 的更新加到 feature​

主要目的：讓現在開發的分支提早跟 main 整合，避免最後合併回 main 時，出現大量的衝突


Merge​

將 main 新的變更帶到 feature，同時建立一個新的 commit 點，feature 和 main 的歷史紀錄都會被保留，但 Git tree 會變得很混亂




Rebase​

將 feature 的根基移到最新 main 的 commit 點上，偽裝成就好像是剛從 main 最新點新開的一個 branch 一樣， 以達成更新，讓我們的 history 更乾淨和直觀




將 feature 合回 main​

主要目的：將分別開發的 feature 合併回 main branch，上到正式的環境，像是 dev, stg, prod 等等



Merge​

將 feature merge 回 Main，同時產生一個新的 commit 點

優點:

  • feature 和 main 的所有歷史紀錄都會被保留




缺點：

  • 到最後太多分支會變得很混亂，歷史紀錄也很複雜




Fast-forward merge​

在 feature 的起始根節點為 main 的最新 commit 點的前提下 (可透過前面的 rebase 達成)， 將 feature 直接合併回 main

透過 main 直接指到 feature 的最新 commit 點，不會產生新的 commit 點


優點：

  • 會讓所有的 git history 都在一直線上，非常乾淨
  • 不會有新的 commit 點產生



Fast-forward merge 前提條件

若要執行 Fast-forward merge，feature 的根節點一定要在 main 的最新節點上，這樣 main 才可以無縫串接 feature 所有的 commit 點




Squash​

將 feature 所有的 commit 點都壓縮 (squash) 成一個 commit 點，並將此 commit 點 merge 回 main branch，達成將 feature 合併回 main 的目的

優點：

  • main 乾淨又整齊，不會有太多的 commit 點

缺點：

  • feature 的 history 會消失，但可以把 feature 的 commit messages 都加到 squash commit 的 comment 中，作為補償



合併策略比較​

合併回 main​

strategymergefast-forwardsquash
Pros保留完整的 commit 歷史,包括所有分支上的變更保持線性歷史,簡單清晰將多個 commit 壓縮成一個,保持歷史簡潔
Cons可能導致 commit 歷史混亂,特別是在進行大量的合併操作時
  • 只能在沒有分支的情況下使用,否則會失去分支信息
  • 一定要確保 root 在 main 的最新 commit,不然無法使用
  • 失去 commit 的細節
  • 會失去詳細的 commit 歷史,不適用於需要保留每次變更記錄的情況

    • 更新 feature​

    strategymergerebase
    Pros保留完整的 commit 歷史,包括所有分支上的變更保持線性和乾淨的 commit 歷史,便於查看和理解
    Cons可能導致歷史混亂,特別是經常合併的分支
  • 可能會改寫歷史,不建議在公共分支上使用
  • 需要小心處理衝突,可能會比較複雜





    • 參考資源​