rebase的兩種用法

• • 用法一: 合并當前分支的多個commit記錄
  • • 1. 找到想要合并的commit, 使用rebase -i
    • 2. 進入Interact交互界面
    • 3.使用s命令 合并到上一個commit
    • 4.修改commit記錄
    • 5.查看最新合并情況
    • 6.rebase的其他用法
  • 用法二: 避免出現分叉合并
  • • 場景1: 合并時, 最舒服的情況
    • 場景2: 各分支都有自己新的commit
    • • ● develop 直接merge feature
      • ● develop rebase feature
      • ● rebase 兩步走 完整版
      • • step1: feature 先 rebase develop
        • step2: develop 再 merge develop
    • rebase時如何解決沖突
  • 使用rebase的注意點
  • • 警告!
    • 不要基于rebase的分支 切新分支
    • 不要對已經合并到主分支的本地修改進行變基
    • 不要在預發布/正式分支上使用rebase -i
    • 總結

用法一: 合并當前分支的多個commit記錄

你可能出現過對同一處代碼進行多次處理的場景。這會導致如下提交記錄:

$ git log --pretty=format:'%h: %s' d2399da: feat: modify c 0134695: feat: modify b eb63848: feat: modify b 51c0bca: feat: modify b 4cb600e: feat: modify a d29f331: Initial commit

其實, 中間的對b的3次提交 完全可以合并成一次commit, 這個時候 rebase就很有用了。

1. 找到想要合并的commit, 使用rebase -i

git rebase -i 4cb600e

注意 git rebase -i [startPonit] [endPoint]

• 前開后閉 區間 這里的 [startPonit] 是指需要合并的commit的前一個commit (即當前示例中的 “4cb600e: feat: modify a”)。 因為, 三個commit肯定要基于上一個commit合并成了新的commit。
• 謹慎使用[endPoint] 省略, 即默認表示從起始commit一直到最后一個，但是一旦你填寫了, 則表示 [endPoint]后面的commit全部不要了!

2. 進入Interact交互界面

終端會進入選擇交互界面, 讓你進行變基選擇操作:

說明

• 最上面三行, 就是剛剛選中的三個commit, 按時間順序依次往下排序(和git log的展示順序是反的, 大家查看的時候要注意)
• 前面的三個Pick 其實就是下面 Commands展示的7種命令中的第一個p, 也就是使用commit。

3.使用s命令 合并到上一個commit

按i 進入操作, 將第二、三個commit的pick改成s

按Esc 退出操作

輸入:wq保存并退出

4.修改commit記錄

接下來會彈出第二個頁面, 分別展示三個commit的提交信息

這里三個信息都是一樣的, 我們選用第一個的提交信息, 將其余的全部注釋掉,重復上述步驟, 保存退出即可

5.查看最新合并情況

會發現原三個一樣的提交現在合并成了一個新的commit。

6.rebase的其他用法

命令縮寫含義

pick	p	保留該commit
reword	r	保留該commit，但需要修改該commit的注釋
edit	e	保留該commit, 但我要停下來修改該提交(不僅僅修改注釋)
squash	s	將該commit合并到前一個commit
fixup	f	將該commit合并到前一個commit，但不要保留該提交的注釋信息
exec	x	執行shell命令
drop	d	丟棄該commit

用法二: 避免出現分叉合并

接下來, 我將用實際示例和場景, 來分析rebase是如何解決分叉合并的, 在此之前, 我先做如下規定:

有兩個分支: develop(主分支) rebase_new(feature分支)

新需求按 時間順序 叫 a 、b、…等(a需求最早, b其次, 以此類推。)

原commit a 變基之后(hashId改變) 叫 a'

場景1: 合并時, 最舒服的情況

此時的合并有兩點好處:

沒有沖突

沒有多余的commit提交

其實這種情況下, rebase和merge的效果是一樣的。
請大家記住這個場景, 后面所有的rebase都是奔著這個目標來的。

場景2: 各分支都有自己新的commit

develop 新增需求a: “feat: a”
feature ?新增需求b: “feat: b”

● develop 直接merge feature

會出現以下結果:

會保留所有的commit(hashId不變)

按提交順序排序

產生新的commit點(Merge branch ‘XXX’ into develop)

● develop rebase feature

會出現以下結果:

develop分支的 a會被排在 合進來的feature分支 b 的上面(盡管a是先完成的)

develop的 原commit a 被移除 產生了新的 commit a’ (hashId已變)

從feature合進來的 b不變 (不會對合進來的commit進行變基)

● rebase 兩步走 完整版

step1: feature 先 rebase develop

# feature分支 git fetch origin git rebase develop# 或者 直接一個命令 git pull develop --rebase

會出現以下結果:

和場景2類似, feature的commit b 會在重新排在第一個 變成 b’

develop的新需求會排在 b’ 的前面

到這里, 你應該有所察覺了!: 沒錯! 這一步相當于 回到了場景1的模式, 我當前的feature相當于先把需求b 拎出來, 同步完最新的develop, 再把需求b放在了最后面。
所以, 接下來merge的時候 就很舒服了~!

step2: develop 再 merge develop

# develop分支 git merge rebase_new

而這, 也是rebase為什么不會產生多余的commit記錄的原因了。

rebase時如何解決沖突

先解決沖突 再保存

git add .

git rebase --continue
注意! 不是commit ! 不是commit ! 不是commit !

使用rebase的注意點

警告!

先引用官網上的一段話:

如果提交存在于你的倉庫之外，而別人可能基于這些提交進行開發，那么不要執行變基。

如果你遵循這條金科玉律，就不會出差錯。 否則，人民群眾會仇恨你，你的朋友和家人也會嘲笑你，唾棄你。

因為變基最強大也是最危險之處, 就在于, 它能改變原commit的hashId, 而一旦你對歷史提交做出改變, 那么 從變基那個節點開始往后的所有節點的commit id 都會發生變化。 這對線上環境來說, 是不可控的！

不要基于rebase的分支 切新分支

如果feature在寫完新需求b后, 切了新分支 feature_B, 然后又rebase了develop, 那么新分支feature_B無論是合進develop 還是 合進 feature 都會有沖突, 出現重復的b(其實是b和b’)

除非 你能百分百確保 你的分支已經完成新需求, rebase操作結束之后, 再切新分支, 這時 他們才是同步的。

不要對已經合并到主分支的本地修改進行變基

首先, 自己的分支, 如果想對已經推送的commit進行修改, 可以在修改完后, 使用 git push -f 強行push并覆蓋遠程對應分支。
但是如果這些修改 已經被合到了其他分支(比如主分支), 那又會出現沖突, 因為其他分支保存的是你rebase之前 合進去的commit。

不要在預發布/正式分支上使用rebase -i

從變基那個節點開始往后的所有節點的commit id 都會發生變化。這個就不再贅述了。
所以可以想象一下, master上有100個commit, 你悄悄改了第50個commit, 那從50—100的所有commit全部改變了, 這時, 別人的分支合進來, 就會有51個沖突, 解決完沖突之后, 就會產生51*2個相同的提交記錄, 恐怖如斯!

總結

總的原則是，只對尚未推送或未分享給別人的本地修改執行變基操作清理歷史， 從不對已推送至別處的提交執行變基操作，這樣，你才能享受到兩種方式（rebase 和merge）帶來的便利。

總結

以上是生活随笔為你收集整理的git rebase的两种用法(最全)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。