兄弟，rebase 了解一下？

作者：Lxlxxx 鏈接：https://juejin.cn/post/7192823689426468919

前言

Git 作為我們?nèi)粘ｉ_發(fā)代碼的版本管理，開發(fā)分支的管理方面起著很大作用，我們開發(fā)過(guò)程中分支通常有生產(chǎn)、預(yù)發(fā)、測(cè)試、開發(fā)這幾個(gè)分支，我們會(huì)根據(jù)項(xiàng)目進(jìn)行的某個(gè)階段，將代碼提交到某個(gè)版本上，正常流程是先開發(fā) —>測(cè)試 —>預(yù)發(fā)—>生產(chǎn)，但是通常會(huì)有很多版本，有先后上線順序，并且我們的開發(fā)人員也會(huì)是多個(gè)，在各種因素下項(xiàng)目的開發(fā)版本遠(yuǎn)程分支，以及開發(fā)人員的本地分支管理就由為的關(guān)鍵。

普通開發(fā)流程

正常一個(gè)版本需要經(jīng)過(guò)的幾個(gè)階段，分別是 dev、test、uat、master，我們通過(guò)下面流程圖這么做是沒什么問題的，每個(gè)階段去將從 master 拉取的版本分支，push到對(duì)應(yīng)的分支上進(jìn)行發(fā)布，正常預(yù)發(fā)和生產(chǎn)環(huán)境的代碼應(yīng)該保持一致，test 分支由于會(huì)有多個(gè)版本并行開發(fā)，所以代碼和預(yù)發(fā)和生產(chǎn)比起來(lái)會(huì)有一些不一樣。

多版本并行開發(fā)

在多個(gè)版本并非開發(fā)的時(shí)候，對(duì)分支的管理就不像上面那么簡(jiǎn)單了，涉及到多個(gè) version，這些版本的上線時(shí)間節(jié)點(diǎn)也是不同的，意味著上 test 和 uat 的時(shí)間節(jié)點(diǎn)也是不一樣的。

這里涉及到多種情況

1. 在后端開發(fā)人員較少的情況下，通常 2-3人 為例，完全可以從 master 拉取一個(gè)開發(fā)分支，分支格式已服務(wù)名+上線時(shí)間，例如 xxx_20230130 這個(gè)本地分支，后端開發(fā)人員一起在這個(gè)分支上進(jìn)行并行開發(fā)，開發(fā)階段將自己的本地分支 merge 到 dev 分支，因?yàn)橹挥?2-3人 所以沖突解決起來(lái)還好，有沖突解決沖突。

2. 后端開發(fā)人員較多的情況，通常在 5-8人 為例，這時(shí)候從 master 分支拉取分支，分支格式就需要已 服務(wù)名+姓名縮寫+上線時(shí)間來(lái)命名，盡量每個(gè)人在自己命名的分支下進(jìn)行開發(fā)，這樣在開發(fā)階段本地測(cè)試的時(shí)候，可以做到相互不影響，但是在 merge 到遠(yuǎn)程分支的時(shí)候，解決代碼沖突的時(shí)候需要認(rèn)真仔細(xì)一些，這種活還是交給心細(xì)的人來(lái)做吧，測(cè)試的時(shí)候也需要根據(jù)版本上線的優(yōu)先級(jí)進(jìn)行測(cè)試。

3. 版本比較多的情況，比如一個(gè)月會(huì)有 4-5 個(gè)版本的開發(fā)，那么上線時(shí)間也是分 4-5 個(gè)節(jié)點(diǎn)，這樣就需要每次從先發(fā)上線的遠(yuǎn)程分支，將代碼 merge 到下個(gè)版本的本地開發(fā)分支上，以此類推。

Git merge

作為 git 合并分支的命令，也是在日常開發(fā)過(guò)程中經(jīng)常用到的一個(gè)命令，通常我們會(huì)將擁有最新代碼的一個(gè)版本merge到較老的一個(gè)版本，實(shí)現(xiàn)版本同步。

大體就是這么一個(gè)步驟，從剛開始的公共分支，變?yōu)?master 和 feature 分支， 通過(guò) git merge master 命令將master 分支 merge 到 feature 分支。Merge 命令會(huì)將前面 featrue 分支所有的 commit 提交全部合并為一個(gè)新的commit 提交。??這里只有會(huì)在產(chǎn)生沖突的時(shí)候，才能產(chǎn)生新的 commit 記錄。

可以理解為 git pull =git fetch +git merge，拉取最新的遠(yuǎn)程分支，然后將這個(gè)分支合并到另一個(gè)分支。

在公司開發(fā)的時(shí)候，通常大家喜歡這個(gè)命令，因?yàn)楹?jiǎn)單粗暴，直接將其他分支合并到自己分支，簡(jiǎn)單好理解。

Git rebase

作為自己的個(gè)人喜好，比較喜歡 rebase 這個(gè)命令，核心理念就是“變基”。

1. 由上圖可看見，通過(guò) reabse 命令將 feature 分支延續(xù)到了 master 分支后面。

2. 在多人開發(fā)過(guò)程中，如果其他人在 master 進(jìn)行 commit，這個(gè)時(shí)候你在 feature 分支提交了幾個(gè) commit，這時(shí)候你使用 rebase 命令，會(huì)將你的 commit 提交記錄放在 master 的 commit 記錄的后面，而 merge 就會(huì)將不同分支的 commit 合并成一個(gè)新的 commit 記錄，這就是 merge 和 rebase 的不同點(diǎn)。

3. 本地 feature 分支和遠(yuǎn)端的 master 分支如果是同一條分支的話，可以使用 rebase，保證 commit 的記錄的清晰性，這個(gè)很關(guān)鍵！

??不要在公共分支使用 rebase命令，這樣會(huì)污染公共分支，這樣公共分支就會(huì)存在你的 commit 記錄，別人拉取的時(shí)候會(huì)存在你的最新的 commit 記錄。

總結(jié)

在開發(fā)中不僅需要代碼質(zhì)量高，在版本管理上也是由為的重要，上線前漏掉代碼的事情，相信大家都曾遇到過(guò)，但是這種事情是很危險(xiǎn)??的，希望此文章能給大家在日常代碼版本管理中提交警惕，合理合并分支。