rebase的兩種用法

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

用法一: 合并當(dāng)前分支的多個(gè)commit記錄

你可能出現(xiàn)過(guò)對(duì)同一處代碼進(jìn)行多次處理的場(chǎng)景。這會(huì)導(dǎo)致如下提交記錄:

$ 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

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

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

git rebase -i 4cb600e

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

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

2. 進(jìn)入Interact交互界面

終端會(huì)進(jìn)入選擇交互界面, 讓你進(jìn)行變基選擇操作:

說(shuō)明

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

3.使用s命令 合并到上一個(gè)commit

按i 進(jìn)入操作, 將第二、三個(gè)commit的pick改成s

按Esc 退出操作

輸入:wq保存并退出

4.修改commit記錄

接下來(lái)會(huì)彈出第二個(gè)頁(yè)面, 分別展示三個(gè)commit的提交信息

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

5.查看最新合并情況

會(huì)發(fā)現(xiàn)原三個(gè)一樣的提交現(xiàn)在合并成了一個(gè)新的commit。

6.rebase的其他用法

命令縮寫(xiě)含義

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

用法二: 避免出現(xiàn)分叉合并

接下來(lái), 我將用實(shí)際示例和場(chǎng)景, 來(lái)分析rebase是如何解決分叉合并的, 在此之前, 我先做如下規(guī)定:

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

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

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

場(chǎng)景1: 合并時(shí), 最舒服的情況

此時(shí)的合并有兩點(diǎn)好處:

沒(méi)有沖突

沒(méi)有多余的commit提交

其實(shí)這種情況下, rebase和merge的效果是一樣的。
請(qǐng)大家記住這個(gè)場(chǎng)景, 后面所有的rebase都是奔著這個(gè)目標(biāo)來(lái)的。

場(chǎng)景2: 各分支都有自己新的commit

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

● develop 直接merge feature

會(huì)出現(xiàn)以下結(jié)果:

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

按提交順序排序

產(chǎn)生新的commit點(diǎn)(Merge branch ‘XXX’ into develop)

● develop rebase feature

會(huì)出現(xiàn)以下結(jié)果:

develop分支的 a會(huì)被排在 合進(jìn)來(lái)的feature分支 b 的上面(盡管a是先完成的)

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

從feature合進(jìn)來(lái)的 b不變 (不會(huì)對(duì)合進(jìn)來(lái)的commit進(jìn)行變基)

● rebase 兩步走 完整版

step1: feature 先 rebase develop

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

會(huì)出現(xiàn)以下結(jié)果:

和場(chǎng)景2類(lèi)似, feature的commit b 會(huì)在重新排在第一個(gè) 變成 b’

develop的新需求會(huì)排在 b’ 的前面

到這里, 你應(yīng)該有所察覺(jué)了!: 沒(méi)錯(cuò)! 這一步相當(dāng)于 回到了場(chǎng)景1的模式, 我當(dāng)前的feature相當(dāng)于先把需求b 拎出來(lái), 同步完最新的develop, 再把需求b放在了最后面。
所以, 接下來(lái)merge的時(shí)候 就很舒服了~!

step2: develop 再 merge develop

# develop分支 git merge rebase_new

而這, 也是rebase為什么不會(huì)產(chǎn)生多余的commit記錄的原因了。

rebase時(shí)如何解決沖突

先解決沖突 再保存

git add .

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

使用rebase的注意點(diǎn)

警告!

先引用官網(wǎng)上的一段話(huà):

如果提交存在于你的倉(cāng)庫(kù)之外，而別人可能基于這些提交進(jìn)行開(kāi)發(fā)，那么不要執(zhí)行變基。

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

因?yàn)樽兓顝?qiáng)大也是最危險(xiǎn)之處, 就在于, 它能改變?cè)璫ommit的hashId, 而一旦你對(duì)歷史提交做出改變, 那么 從變基那個(gè)節(jié)點(diǎn)開(kāi)始往后的所有節(jié)點(diǎn)的commit id 都會(huì)發(fā)生變化。 這對(duì)線(xiàn)上環(huán)境來(lái)說(shuō), 是不可控的！

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

如果feature在寫(xiě)完新需求b后, 切了新分支 feature_B, 然后又rebase了develop, 那么新分支feature_B無(wú)論是合進(jìn)develop 還是 合進(jìn) feature 都會(huì)有沖突, 出現(xiàn)重復(fù)的b(其實(shí)是b和b’)

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

不要對(duì)已經(jīng)合并到主分支的本地修改進(jìn)行變基

首先, 自己的分支, 如果想對(duì)已經(jīng)推送的commit進(jìn)行修改, 可以在修改完后, 使用 git push -f 強(qiáng)行push并覆蓋遠(yuǎn)程對(duì)應(yīng)分支。
但是如果這些修改 已經(jīng)被合到了其他分支(比如主分支), 那又會(huì)出現(xiàn)沖突, 因?yàn)槠渌种П４娴氖悄鉹ebase之前 合進(jìn)去的commit。

不要在預(yù)發(fā)布/正式分支上使用rebase -i

從變基那個(gè)節(jié)點(diǎn)開(kāi)始往后的所有節(jié)點(diǎn)的commit id 都會(huì)發(fā)生變化。這個(gè)就不再贅述了。
所以可以想象一下, master上有100個(gè)commit, 你悄悄改了第50個(gè)commit, 那從50—100的所有commit全部改變了, 這時(shí), 別人的分支合進(jìn)來(lái), 就會(huì)有51個(gè)沖突, 解決完沖突之后, 就會(huì)產(chǎn)生51*2個(gè)相同的提交記錄, 恐怖如斯!

總結(jié)

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

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。