當多我的在同一個開發分支上工做的時候,會出現一些冗餘的難以接受的歷史記錄git
Merge branch 'feature/x' of github.com:xxx/learn-git into feature/x
翻譯過來就是把遠程倉庫分支feature/x
合併到本地分支feature/x
。github
emmm...fetch
你們都在一個分支,本身分支和本身分支有什麼好合並的(遠程分支和本地分支)?翻譯
那咱們一塊兒來看一下是什麼操做形成了這種局面吧日誌
有一天公司須要開發一個新功能code
開發人員是小明和小紅開發
小明從master
拉了一個分支出來,分支名是 feature/x
it
今後小明和小紅共同在這個分支上愉快的開發。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 pull
和git pull --rebase
有什麼區別
git pull
git pull --rebase
僅僅是使用rebase 代替了合併
你們對rebase
操做敬而遠之,大部分緣由都是道聽途說會有反作用。而後就把持着反正不用rebase
也能好好活着的方針,繼續避而不用。
就上面這種狀況,咱們來分析一下
小紅哈希值變了,會有什麼影響,先來個靈魂拷問
如上所示,小紅哈希值變的是本身本地的2次提交,並未推送。
那麼會有反作用嗎?不會。
什麼狀況下會有反作用呢?
舉個栗子:
呃。。。
簡而言之就是不影響其餘人的修改(不變動已推送到遠程倉庫的提交)都不會有反作用。
有反作用的狀況會在後續系列更新。