新來個(gè)技術(shù)總監(jiān)，禁止我們用Git的rebase！？
點(diǎn)擊關(guān)注公眾號(hào)，Java干貨及時(shí)送達(dá)
在Git中，merge和rebase是兩種不同的代碼合并策略，它們用于將一個(gè)分支的更改合并到另一個(gè)分支。它們的主要區(qū)別在于合并的方式和提交歷史的表現(xiàn)上
在介紹區(qū)別之前，我們先看下當(dāng)我們從主干（Main）創(chuàng)建了一個(gè)新的分支（Feature）開始開發(fā)代碼時(shí)，然后另外有人把自己的代碼提交到主干（Main）之后，就會(huì)產(chǎn)生分叉的提交記錄。
這時(shí)候你想把你的代碼也提交到主干中，就有兩個(gè)選擇了：merge(合并)，rebase(變基)
git checkout feature
git merge maingit merge feature main以上兩種都是把一個(gè)主干(main)的最新代碼合并(merge)到分支(featrue)的方式。
這個(gè)操作會(huì)在分支中創(chuàng)建一個(gè)新的“merge commit”，它將兩個(gè)分支的更改合并到一個(gè)新的提交中。
如上圖，就是我們把Main中的新提交Merge到我們的Feature分支中。
作為merge的替代方法，您可以使用以下命令將功能分支重新設(shè)置為主分支：
git checkout feature
git rebase main這會(huì)將整個(gè)feature移動(dòng)到main分支的頂端，從而有效地將所有新提交合并到 main 中。但是，rebase不是使用merge commit，而是通過為原始分支中的每個(gè)提交創(chuàng)建全新的提交來重寫項(xiàng)目歷史記錄。
如上圖，就是我們將Main中新的提交，通過rebase的方式合并到我們的Feature分支中。（另外我出了一份Java面試寶典，里面有600多道面試常考題目）
當(dāng)我們想要把一個(gè)分支合并到主干的時(shí)候，merge操作會(huì)通過merge commit的方式在主干上新建一個(gè)節(jié)點(diǎn)，并一次性的把分支中的修改合并到主干中。它的優(yōu)點(diǎn)是分支代碼合并后不破壞原分支的代碼提交記錄，缺點(diǎn)就是會(huì)產(chǎn)生額外的提交記錄并進(jìn)行兩條分支的合并。
而rebase操作，不會(huì)在主干上新建節(jié)點(diǎn)，而是把分支上的所有歷史提交都合并到主干中，形成一個(gè)完成的線性提交記錄。他的優(yōu)點(diǎn)是無須新增提交記錄到目標(biāo)分支，rebase后可以將對(duì)象分支的提交歷史續(xù)上目標(biāo)分支上，形成線性提交歷史記錄，進(jìn)行review的時(shí)候更加直觀。
所以，merge rebase可以保留完整的歷史提交記錄。
當(dāng)你想要保留原始分支的提交歷史，并且不介意在合并中產(chǎn)生額外的合并提交時(shí)，可以使用merge。在多人協(xié)作或公共分支上，merge是一個(gè)更安全和常見的選擇，因?yàn)樗Ａ袅嗣總€(gè)開發(fā)者的提交歷史，易于跟蹤和回溯。（另外我出了一份Java面試寶典，里面有600多道面試常考題目）
當(dāng)你想要保持提交歷史的整潔、線性，并且愿意改寫提交歷史時(shí)，可以使用rebase。在個(gè)人開發(fā)分支上，為了保持提交歷史的簡潔和易于閱讀，rebase用的更多。
一般來說，在公司內(nèi)部做團(tuán)隊(duì)開發(fā)，使用merge的情況會(huì)更多一些，我在工作中基本上90%的時(shí)間都是使用merge的。
一般來說，我們?cè)诠ぷ髦械拈_發(fā)模式都是基于分支開發(fā)，基于主干發(fā)布的模式。什么意思呢？
就是倉庫中有一份主干的代碼，線上運(yùn)行的就是這套代碼，當(dāng)我們有需求要開發(fā)的時(shí)候，不會(huì)直接在主干上開發(fā)，而是基于主干拉一個(gè)分支出來，在分支中進(jìn)行開發(fā)，開發(fā)好之后，再把這個(gè)分支的代碼通過發(fā)布的方式合并到主干中。
在業(yè)內(nèi)有一個(gè)rebase黃金法則：不要對(duì)已經(jīng)提交到共享倉庫（如遠(yuǎn)程倉庫）的提交執(zhí)行 rebase。
為什么要遵守這個(gè)黃金法則呢？
rebase會(huì)將所有的Main分支上的提交移動(dòng)到Feature分支的頂端，問題是這個(gè)操作只發(fā)生在你自己的本地倉庫中，所有的其他開發(fā)者是完全不感知的，因?yàn)樗麄兪鞘褂门f的Main分支創(chuàng)建的分支。（另外我出了一份Java面試寶典，里面有600多道面試常考題目）
這時(shí)候如果我們的Feature變更被推送到遠(yuǎn)程倉庫后，其他人的Feature想要在提交的時(shí)候，就會(huì)產(chǎn)生大量的沖突。
所以，在多人協(xié)作中，應(yīng)該遵循以下指導(dǎo)原則：
在個(gè)人開發(fā)分支上進(jìn)行 rebase：如果你在個(gè)人開發(fā)分支上進(jìn)行 rebase，這不會(huì)對(duì)其他開發(fā)者產(chǎn)生影響，因?yàn)檫@個(gè)分支只屬于你個(gè)人。
在共享倉庫的主分支上使用 merge：在共享倉庫的主分支（如 master 或 main）上，推薦使用 merge 來將開發(fā)的功能或修復(fù)合并回主分支。這樣可以保留每個(gè)開發(fā)者的提交歷史，易于跟蹤和回溯。
協(xié)作時(shí)協(xié)商：如果有特殊情況需要在共享倉庫的分支上進(jìn)行 rebase，應(yīng)該與其他開發(fā)者進(jìn)行充分協(xié)商，并確保大家都知道并同意這個(gè)變更。
往 期 推 薦
1、對(duì)線面試官：說出 Java 中的 7 種重試機(jī)制
2、超越 MyBatis-Plus？來領(lǐng)略一下 MyBatis-Flex 的優(yōu)雅魅力！
3、世界上最流行的軟件，拋棄了Git
4、還敢買微軟手機(jī)？消息稱微軟停產(chǎn)Surface Duo 2 同時(shí)不再提供安卓版本更新
5、已被LLM“殺死”？Stack Overflow：打不過就加入
6、這 3 類程序員成長最慢！踩坑最多！
點(diǎn)分享
點(diǎn)收藏
點(diǎn)點(diǎn)贊
點(diǎn)在看
