合併分支使用Merge仍是Rebase？

閱讀原文：合併分支使用Merge仍是Rebase？

做爲一個有追求的開發者，我必定會選擇更好的版本管理工具（Git）, 使用中咱們不免會在 Merge 和 Rebase 中選擇其一用於合併分支。

Rebase 和 merge 都是被設計用於集成你所作的改變從一個分支到另外一個分支，只是經過不一樣的方式。雖然目的相同，但不一樣的方式有不一樣的優缺點。

區別

例如：咱們有下面的幾個commit，merge會將一些commit的組合做爲一個結果，而rebase會將全部commit添加到目標分支的最近一次提交以後。

經過上圖咱們能夠看到，merge 會存在合併的歷史記錄，而rebase沒有了歷史記錄且成一條直線。

Merge

• 簡單易理解
• 源分支和目標分支相互分離
• 保留功能分支的提交歷史和分支圖形
• 分支一旦較多顯示比較混亂

Rebase

• 簡化複雜的記錄且線性可讀
• 沒有合併的記錄
• 多個commit衝突時必須一個個提交去修改
• 對遠程分支rebase須要force push

何時使用rebase？何時使用merge ？

• 獨立開發

  若是你不是團隊合做開發，那麼你能夠優先選擇使用rebase來保持你整潔的提交歷史。

• 準備code review

  你須要在合併的時候有人來給你review，此時你須要提交一個 merge/pull request,此時別人可review你的代碼後會執行merge，這將保存你這次的請求合併的記錄，已備未來追溯。

• 合併到多個目標分支或其餘人正在使用當前分支

  這是應該使用merge,由於你執行rebase時,當前分支原先的commit會被刪除（會影響他人），造成新的commit鏈接在目標分支最新commit以後。因此在這個條件不成立的時候你可使用rebase來合併分支。

推薦

在不符合上面第三點時（合併到多個目標分支或其餘人正在使用當前分支）,我的分支(feature/bugfix/……)中使用rebase來更新主分支（我的分支的來源）上的變更，確保當前分支是最新的，而後提交merge/pull request,由其餘人來負責對你的代碼進行review並肯定是否經過請求，這樣能夠看到每一個人開發合併的歷史記錄。

不知道你是如何的呢？

往期文章一覽

1. 把「策略模式」應用到實際項目中

2. 造個輪子,我學到了什麼

3. 技術面試中的軟技能

4. 不一樣時重寫equals和hashCode又怎樣！

關注微信公衆號 「碼上實戰」 回覆 ：面試視頻 和 架構師 送你很是不錯的資料。