消除同一個分支中的合併記錄(git pull --rebase)

問題:

當多我的在同一個開發分支上工做的時候,會出現一些冗餘的難以接受的歷史記錄git

Merge branch 'feature/x' of github.com:xxx/learn-git into feature/x

翻譯過來就是把遠程倉庫分支feature/x合併到本地分支feature/xgithub

emmm...fetch

你們都在一個分支,本身分支和本身分支有什麼好合並的(遠程分支和本地分支)?翻譯

那咱們一塊兒來看一下是什麼操做形成了這種局面吧日誌

問題重現

有一天公司須要開發一個新功能code

開發人員是小明和小紅開發

小明從master拉了一個分支出來,分支名是 feature/xit

今後小明和小紅共同在這個分支上愉快的開發。ast

有小改動 就經過git commit提交推送

小明推送前的日誌是這樣子的

* 2a68d81 (HEAD -> feature/x) 小明第三次提交
* 53b261a 小明第二次提交
* 71a5262 小明第一次提交
* 3021c2e (origin/master, origin/feature/x, master) first commit

小紅推送前的日誌是這樣子的

* 0266f4f (HEAD -> feature/x) 小紅第二次提交
* 260fa38 小紅第一次提交
* 3021c2e (origin/master, origin/feature/x, origin/HEAD, master) first commit

小明率先推送了

小紅改完也想推送了

這個時候遠端已經更新了(小明的推送),因此小紅想推送(push)必須先拉取代碼(git pull )

*   17771aa (HEAD -> feature/x) Merge branch 'feature/x' of github.com:zq741235/learn-git into feature/x
|\  
| * 2a68d81 (origin/feature/x) 小明第三次提交
| * 53b261a 小明第二次提交
| * 71a5262 小明第一次提交
* | 0266f4f 小紅第二次提交
* | 260fa38 小紅第一次提交
|/  
* 3021c2e (origin/master, origin/HEAD, master) first commit

(此處有點題),如何避免這種合併記錄呢?

若是這個時候使用rebase 模式操做,就是另一番景象了:

$ git pull --rebase

結果以下:

* 9cd6d58 (HEAD -> feature/x) 小紅第二次提交
* 01cd7cf 小紅第一次提交
* 2a68d81 (origin/feature/x) 小明第三次提交
* 53b261a 小明第二次提交
* 71a5262 小明第一次提交
* 3021c2e (origin/master, origin/HEAD, master) first commit

這兩種方式有什麼區別呢 ?

除了歷史記錄變成了一條直線,能夠看見的區別就是小紅提交記錄的哈希值變了。

咱們來看一下git pullgit pull --rebase 有什麼區別

git pull

  1. git fetch
  2. git merge FETCH_HEAD

git pull --rebase

  1. git fetch
  2. git rebase FETCH_HEAD
僅僅是使用rebase 代替了合併

其餘

你們對rebase操做敬而遠之,大部分緣由都是道聽途說會有反作用。而後就把持着反正不用rebase也能好好活着的方針,繼續避而不用。

就上面這種狀況,咱們來分析一下

小紅哈希值變了,會有什麼影響,先來個靈魂拷問

  1. 小紅哈希值變的是哪幾回提交?
  2. 推送到遠端倉庫了嗎?

如上所示,小紅哈希值變的是本身本地的2次提交,並未推送。

那麼會有反作用嗎?不會。

什麼狀況下會有反作用呢?

舉個栗子:

呃。。。

簡而言之就是不影響其餘人的修改(不變動已推送到遠程倉庫的提交)都不會有反作用。

有反作用的狀況會在後續系列更新。

相關文章
相關標籤/搜索