2. 程式人生 > >GIT使用rebase和merge的正確姿勢

GIT使用rebase和merge的正確姿勢

阿新 • • 發佈：2018-12-28

背景

使用GIT這麼久了從來沒有深層次的研究過，一般情況下，只要會用pull,commit,push等幾個基本提交命令就可以了，公司的專案分支管理這部分操作一直都是我負責，對於分支的合併我一直都使用merge操作，也知道還有一個rebase，但是一直不會用，百度了很多，說的基本都差不多，按照步驟在公司專案裡操作，簡直就是噩夢，只要rebase就出現噩夢般的衝突，所以一直不敢用，今天自己搗騰了一番終於領略到一些，不多說直接進入乾貨。

先來兩張合理使用rebase，merge和只使用merge的對比圖

使用 rebase

 

 

使用 merge

 

 

使用 rebase 和 merge 的基本原則：

 

  1. 下游分支更新上游分支內容的時候使用 rebase
  2. 上游分支合併下游分支內容的時候使用 merge
  3. 更新當前分支的內容時一定要使用 --rebase 引數

例如現有上游分支 master，基於 master 分支拉出來一個開發分支 dev，在 dev 上開發了一段時間後要把 master 分支提交的新內容更新到 dev 分支，此時切換到 dev 分支，使用 git rebase master

等 dev 分支開發完成了之後，要合併到上游分支 master 上的時候，切換到 master 分支，使用 git merge dev

一、建立兩個GIT專案，project1和 project2,同時分別加入三個檔案並提交master分支

$ git clone [email protected]:baiyl3/project1.git
$ cd project1
$ touch file1 file2 file3
$ git add .
$ git commit -m '在專案一中初始化三個程式碼檔案'
$ git push -u origin master

$ git clone 
 
[email protected]:baiyl3/project2.git
$ cd project2
$ touch file1 file2 file3
$ git add .
$ git commit -m '在專案二中初始化三個程式碼檔案'
$ git push -u origin master

從程式碼提交時間軸圖看兩個專案現在的狀態都一致

 

 

二、分別給兩個專案建立三個分支 B1，B2，B3 (* 對應數字)

$ git checkout -b B*
$ git push origin B*
$ git branch -a
  B1
  B2
* B3
  master
  remotes/origin/B1
  remotes/origin/B2
  remotes/origin/B3
  remotes/origin/master
$ git logs --graph
* 891d1ed<baiyl3> - (HEAD -> B3, origin/master, origin/B3, origin/B2, origin/B1, master, B2, B1) 在專案二中初始化三個程式碼檔案 (23 minutes ago)  
  file1
  file2
  file3

從 git log 中我們看到 B1，B2，B3 都基於master最新提交點拉出來的三個新分支，如下圖從時間軸也可以看出

 

 

三、現在我們分別切換分支到 B1，B2，B3，並修改對應的檔案 file1，file2，file3，最後切換到 mastet 分支新增一個 README.md 檔案，然後再看時間軸：

 

 

從上圖的結果可以看出，B1, B2, B3, master 四個分支分別在不同的時間點做了程式碼提交，那麼最後一次 master 上做的修改在 B1, B2, B3 三個分支上肯定沒有

四、此時在這三個分支上開發的同學發現他們要做的功能要在 master 最新的基礎上開發，或者他們也想要 master 上最新的內容，重點來了，現在我們怎麼辦？方法有兩種，一種是使用 rebase ，另一種是使用 merge，我們分別在 project1 和 project2 兩個專案上使用這兩種方式解決這個問題

在專案 project1 使用 rebase

$ cd project1
$ git checkout B1
$ git pull origin B1 --rebase
From gitlab.xpaas.lenovo.com:baiyl3/project1
 * branch            B1         -> FETCH_HEAD
Already up-to-date.
Current branch B1 is up to date.

$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: FILE1 第一次修改

$ git push origin B1
To gitlab.xpaas.lenovo.com:baiyl3/project1.git
 ! [rejected]        B1 -> B1 (non-fast-forward)
error: failed to push some refs to '[email protected]:baiyl3/project1.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

$ git push origin B1 --force
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 328 bytes | 328.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: 
remote: To create a merge request for B1, visit:
remote:   http://gitlab.xpaas.lenovo.com/baiyl3/project1/merge_requests/new?merge_request%5Bsource_branch%5D=B1
remote: 
To gitlab.xpaas.lenovo.com:baiyl3/project1.git
 + b3052a0...00032a7 B1 -> B1 (forced update)

$ ls
README.md   file1       file2       file3

 

 

在上面的過程中，更新程式碼我使用的是 git pull origin B1 --rebase 而不是 git pull origin B1 這也是平時使用 rebase 注意的一點，git pull 這條命令預設使用了 --merge 的方式更新程式碼，如果你不指定用 --rebase，有的時候就會發現日誌裡有這樣的一次提交 Merge branch 'dev' of gitlab.xpaas.lenovo.com:liuyy23/lenovo-mbg into dev 什麼？自己分支合併到了自己分支，顯然這個沒有什麼必要，而且在時間軸上也不好看，平白無故多了一條線出來，對於強迫症的我來說看著就難受。。。

還有就是使用 rebase 之後，如果直接使用 git push origin B1 發現是不好使的，提示也說明了提交失敗的原因，我個人是這麼理解的，使用 rebase 之後，master分支上比B1分支上多的修改，直接“插入”到了B1分支修改的內容之後，也就是 master 分支的修改在 B1 分支上重演了一遍，相對遠端 B1 分支而言，本地倉庫的B1分支的“基底”已經變化了，直接 push 是不行的，所以確保沒有問題的情況下必須使用 --force 引數才能提交，這也就是官方對 rebase 作為 “變基” 的解釋（個人觀點）。

接下來我們接著在 project2 專案上使用 merge 操作

$ cd project
$ git pull origin B1
From gitlab.xpaas.lenovo.com:baiyl3/project2
 * branch            B1         -> FETCH_HEAD
Already up-to-date.

$ git merge master
Merge made by the 'recursive' strategy.
 README.md | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 README.md

$ git push origin B1
Counting objects: 2, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 278 bytes | 278.00 KiB/s, done.
Total 2 (delta 1), reused 0 (delta 0)
remote: 
remote: To create a merge request for B1, visit:
remote:   http://gitlab.xpaas.lenovo.com/baiyl3/project2/merge_requests/new?merge_request%5Bsource_branch%5D=B1
remote: 
To gitlab.xpaas.lenovo.com:baiyl3/project2.git
   d3ea69c..e040c7b  B1 -> B1

ls
README.md   file1       file2       file3

 

 

可以看到 merge 之後，在 B1 分支上多出一條合併的log

此時，我們的 B1 分支開發完成了，要合併到 master 分支，根據基本原則，在 master 分支上都使用 git merge B1 就可以合併，看下圖結果：

$ git checkotu master
$ git merge B1
Updating c782e83..00032a7
Fast-forward
 file1 | 1 +
 1 file changed, 1 insertion(+)

$ git push origin master

 

 

接下來對 B2，B3 分別在 project1 和 project2 上做相同的操作，我們看結果：

 

 

再看看命令列下log的情況

$ git logs --graph
* 5826260<baiyl3> - (HEAD -> master, origin/master, origin/B3, B3) FILE3 第一次修改 (6 minutes ago)| 
| file3

* cffcc9a<baiyl3> - (origin/B2, B2) FILE2 第一次修改 (8 minutes ago)| 
| file2

* 00032a7<baiyl3> - (origin/B1, B1) FILE1 第一次修改 (87 minutes ago)| 
| file1

* c782e83<baiyl3> - 新增README.md檔案 (2 hours ago)| 
| README.md

* b783e0a<baiyl3> - 在專案一中初始化三個程式碼檔案 (3 hours ago)  
  file1
  file2
  file3
git logs --graph
*   bc3f385<baiyl3> - (HEAD -> master, origin/master, origin/B3, B3) Merge branch 'master' into B3 (4 minutes ago)
|\  
| *   64b4f3d<baiyl3> - (origin/B2, B2) Merge branch 'master' into B2 (5 minutes ago)
| |\  
| | *   e040c7b<baiyl3> - (origin/B1, B1) Merge branch 'master' into B1 (35 minutes ago)
| | |\  
| | | * 2cedfcb<baiyl3> - 新增README.md檔案 (2 hours ago)| | | | 
| | | | README.md

| | * | d3ea69c<baiyl3> - FILE1 第一次修改 (2 hours ago)
| | |/  | | |   
| | |   file1

| * | 5975eae<baiyl3> - FILE2 第一次修改 (2 hours ago)
| |/  | |   
| |   file2

* | 37ec6de<baiyl3> - FILE3 第一次修改 (2 hours ago)
|/  |   
|   file3

* 891d1ed<baiyl3> - 在專案二中初始化三個程式碼檔案 (3 hours ago)  
  file1
  file2
  file3

使用 rebase 就感覺所有人都在同一條直線上開發一樣，很乾淨的log，看著很舒服，而一直使用 merge 的log看起來就很亂，我這只是4個分支的例子，我們專案每週基本都是十幾個分支，真的是看起來亂入一團哇。。。

這個例子中的操作都沒有出現不同分支修改同一個檔案導致衝突的情況，實際開發中這種情況非常多，rebase 的時候出現衝突後 git 也會列出來哪些檔案衝突了，等你解決衝突之後使用 git rebase --continue 就會繼續處理，所以為了避免這種衝突太多，而且不好解決，我們專案中基本都是一個需求就一個分支，而且開發過程中要隨時更新上游分支的內容下來，確保在最新的程式碼基礎上開發，這也是 GIT 推薦的方式，儘可能多建分支開發，而不是在一個開發分支上很多人操作，如果是這種情況建議不要用 rebase，另外負責分支合併的人在合併下游分支程式碼的時候要確保你這個上游分支不要在這段時間內提交程式碼，有一個方法就是把上游分支 設定 protect

五、注意事項

 

 

from:https://zhuanlan.zhihu.com/p/34197548 

  1. 更新當前分支程式碼的時候一定要使用 git pull origin xxx --rebase
  2. 合併程式碼的時候按照最新分支優先合併為原則
  3. 要經常從上游分支更新程式碼，如果長時間不更新上游分支程式碼容易出現大量衝突

相關推薦

GIT使用rebase和merge的正確姿勢

背景 使用GIT這麼久了從來沒有深層次的研究過，一般情況下，只要會用pull,commit,push等幾個基本提交命令就可以了，公司的專案分支管理這部分操作一直都是我負責，對於分支的合併我一直都使用merge操作，也知道還有一個rebase，但是一直不會用，百度了很多，說的基本都差不多，按照步驟

溝通技巧系列 - 給予和接受反饋的正確姿勢

準備 你會 在哪裏 美的 剛才 方式 辦公室 出現 了解 給予反饋 “績效評估” - 往往是不論普通員工還是管理者都不願意做的事情。 世界各地的員工和管理人員都對這種儀式感到恐懼，其中存在的主要問題是：我們已經將反饋的給予和接受程序化了。我們暗中觀察員工的日常

Redis全方位詳解--資料型別使用場景和redis分散式鎖的正確姿勢

一、Redis資料型別 　　1.string 　　　　string是Redis的最基本資料型別，一個key對應一個value，每個value最大可儲存512M。string一半用來存圖片或者序列化的資料。 　　2.hash 　　　　相當於一個string型別的對映表。特別適合用來儲存物件。例如可以儲存使用者

解讀mysql的索引和事務的正確姿勢

一、索引是做什麼的? 很多時候，當你的應用程式進行SQL查詢速度很慢時，應該想想是否可以建索引。 大多數MySQL索引(PRIMARY KEY、UNIQUE、INDEX和FULLTEXT)在B樹中儲存。只是空間列型別的索引使用R-樹，並且MEMORY表還支援hash索引。 索引是一個排

使用開源專案的正確姿勢，都是血和淚的總結！

軟體開發領域有一個流行的原則：DRY，Don’t repeat yourself，我們翻譯過來更形象通俗：不要重複造輪子。開源專案主要目的是共享，其實就是為了讓大家不要重複造輪子，尤其是在網際網路這樣一

Delphi中GDI+和ImageList使用的正確姿勢

GDI+DrawImage只能傳入TGPImage, 因此最初想到的是從ImageList中得到Image, 然後儲存為流，再轉換為TGPImage，然後顯示。 function drawImageList(graphics: TGPGraphics; paraImage

QTableWidget獲取遊標所在行號和列號的正確姿勢

最近筆者在專案開發過程中需要獲取QTableWidget的游標位置，琢磨了一段時間，拿出來和大家分享一下。 1.先說正確的姿勢： connect(this, &QTableWidget::i

處理ipv6和內購(IAP)及掉單問題的正確姿勢

最近開發一個專案涉及到內購, 也遇到過一些問題. 這裡拿出來分享一下, 避免一些人走彎路. 開頭先聊一聊最近蘋果關於2017年新的稽核機制和沸沸揚揚的微信和蘋果的撕逼 1. 2017新的稽核機制: ipv6: 使用國內阿里雲的app上架, 大都會遇到ipv6被

Golang錯誤和異常處理的正確姿勢

序言 錯誤和異常是兩個不同的概念，非常容易混淆。很多程式設計師習慣將一切非正常情況都看做錯誤，而不區分錯誤和異常，即使程式中可能有異常丟擲，也將異常及時捕獲並轉換成錯誤。從表面上看，一切皆錯誤的思路更簡單，而異常的引入僅僅增加了額外的複雜度。 但事實並非如此。

React Native 載入圖片的正確姿勢和遇到的一些么蛾子

一、載入圖片的正確姿勢 做過原生開發和在使用App時比較注重使用者體驗的都會注意到“List中載入過程中會出現跟業務相關的Loading圖，當圖片載入成功之後會消失；當圖片載入失敗之後會展示預設的error圖”，針對這個問題，自己嘗試著在做RN的時候優化一下這

開發函式計算的正確姿勢——支援 ES6 語法和 webpack 壓縮

首先介紹下在本文出現的幾個比較重要的概念： 函式計算（Function Compute）: 函式計算是一個事件驅動的服務，

Windows新終端中玩轉ASCII和Emoji遊戲的正確姿勢

前一段時間，我搬運了幾個Windows Terminal中玩遊戲的視訊，詳情請看 釋出在即！來一睹官方團隊如何玩轉 Windows Terminal - 知乎. 今天我來給大家展示一下具體的玩法~ Emoji版雙人碰碰球 目前有個現成的 .NET core 專案可以直接用，地址是： mbcrump/pong

Java執行緒狀態和關閉執行緒的正確姿勢

1、執行緒狀態及切換 　　Java中的執行緒有六種狀態，使用執行緒Thread內的列舉類來實現，如下，我對每個狀態都進行了一定的解釋。 　　public enum State { /** 表示一個執行緒還沒啟用（即未呼叫start方法）*/ NEW,

Android開發入門的正確姿勢,你get到了嗎？

開源 如何 com 正常 它的 接收 應用 切換 角度 在進行Android開發之前，我們先了解一下Android的生態圈現狀。Android系統是開源的，任何手機廠商和開發者都有權限去修改系統源代碼，定制專屬的系統。 這就產生了一個問題，不同手機廠商之間的ROM可能無法安

UITableViewCell嵌套UITableView的正確姿勢

views ble wce items repl ride ret 麻煩 sel 內嵌UiTableView的高度計算起來太麻煩了，如何解決，就是把二級TableVIew裏面的model item做到一級，然後對不同的item類型做不同的Cell，這樣就Ok

JavaScript函數setInterval()和setTimeout()正確的寫法

ava 改進 .cn tint 程序 寫法 set archive 編寫 一、常規寫法 1.1 不傳參數 function a (x, y) { var i = 0; var b = function(){ console.log(

Android玩轉百度地圖Sha1獲取正確姿勢？

views num adl 定位 提示 合作 動態 例如 登錄 場景一 由於近期項目鐘要用到定位功能因此肯定須要用到地圖以及地位功能，相信大家也知道眼下國內比較出名的地圖像百度、高德、騰訊等這些還是用到比較多的。於是思考了一下決定還是用百

HDFS數據遷移目錄到正確姿勢

pre -h -s dir 目錄 關閉 所有 white cdh 添加了一塊硬盤，原來的DataNode已經把原有的硬盤占滿；怎麽辦，想要把舊有的數據遷移到新的硬盤上面； 1. 在CDH中修改目錄（在HDFS組件中搜索.dir)，本例中，新加的硬盤掛載在/data上面，Na

fetch獲取json的正確姿勢

改進 key ret per property json cat cnblogs pan fetch要求參數傳遞，遇到請求無法正常獲取數據，網上其他很多版本類似這樣： fetch(url ,{ method: ‘POST‘, hea

Intellij IDEA中使用Protobuf的正確姿勢

hub pom.xml文件 art -c github es2017 生成 out -i 一、.proto文件語法高亮顯示 需要安裝Protobuf Support插件 依次點擊Intellij中的“File”-->"Settings"-->"Pl