背景

我初學(xué)前端的時候接觸git，那時候只要會add/commit什么的就好了，網(wǎng)上的教程大多都停留在從頭到尾一個個介紹git的命令，關(guān)于各種用法，特別是多個分支來回交叉沖突的實際處理，很少有這方面的介紹，經(jīng)過很多次的實踐（踩雷?），想分享一點經(jīng)驗，給剛進(jìn)入前端的同學(xué)做過渡用，但畢竟一千個人有一千個使用git的方式，所以不保證對所有人都是有用的?

現(xiàn)在在公司開發(fā)維護(hù)一個比較大的項目，有公司自己實現(xiàn)的各種npm包、框架代碼、各種業(yè)務(wù)公共代碼和業(yè)務(wù)實現(xiàn)代碼，總行數(shù)五六十萬行，頻繁的git提交經(jīng)常導(dǎo)致代碼翻車，經(jīng)歷過多次車禍現(xiàn)場也算有點心得?。我司前端代碼庫主要有dev/test/release環(huán)境分支（分別對應(yīng)后端三個環(huán)境），幾個大的項目/特性分支和小百個業(yè)務(wù)分支，主要的規(guī)則就是自己開發(fā)的特性分支合并到dev（和后端聯(lián)調(diào)）=>合并到test（提交測試同學(xué)測試，改bug）=>合并release（測試同學(xué)模擬線上環(huán)境測試，準(zhǔn)備發(fā)布線上），說出來感覺非常清晰簡單，實際操作會有各種問題，有天災(zāi)（臨時改需求，后臺改字段），有人禍（提交代碼不規(guī)范）。

外部的可視化工具

如果不是特別熟悉git，還是先老實選一款git可視化工具吧，推薦SourceTree（安裝后需要免費(fèi)注冊，注冊要翻墻），之前用過GitHub Desktop，輕量的git工具，不能滿足復(fù)雜的需求，后來用了SourceTree，隨著版本的更新，越來越好用。 有關(guān)SourceTree的使用可以寫一篇文章，但是如果對git有稍深一點的理解，非常容易上手，節(jié)省了記命令的腦容量，節(jié)點圖也非常直觀。剛使用的同學(xué)建議多探索一下，很多操作如解決沖突、重置等比命令行要快，絕大部分命令都能用簡單的操作代替。如果git倉庫分支多而且關(guān)系復(fù)雜，純寫命令行的git老司機(jī)也容易翻車?

本地和遠(yuǎn)程origin

提交代碼之前請三思，如果是使用SourceTree，請不要在提交上點擊同時推送到遠(yuǎn)端（非常重要）

這樣提交以后，如果發(fā)現(xiàn)自己提交有問題還可以選擇更正上一次提交。我們公司的遠(yuǎn)程倉庫除管理員無法回退，所以每次提交要非常謹(jǐn)慎，據(jù)說很久以前沒那么多限制，大家在release/test上也隨意reset加push -f，回退的同時把這中間別人提交的代碼也干掉了，于是公司就禁止了除管理員以外對遠(yuǎn)程倉庫的修改。理論上說在這三個環(huán)境分支release/test/dev上大家不應(yīng)該直接提交，應(yīng)該從其他分支改完merge過來，但是畢竟直接提交更方便，有個精度/樣式小bug之類的直接改掉，比切到相應(yīng)業(yè)務(wù)分支改掉提交，切回環(huán)境分支，merge過來更加的快，但是萬一提交出錯，就比較尷尬，所以還是不能懶。

提取單次提交cherry-pick

cherry-pick這個命令非常強(qiáng)大，也是我習(xí)慣SourceTree后唯二在命令行使用的git命令（還有revert merge），它是提取出某個分支的特定的那次提交應(yīng)用到其他分支上，精準(zhǔn)的操作，對其他代碼不會造成任何影響。假如有個緊急bug，即將上線，我直接在release上改了，那么事后一定要同步到自己的特性分支和test等其他環(huán)境分支，這時候又不想merge過去，就需要用到cherry-pick了，具體使用命令 git cherry-pick xxxxx，（xxxxx可以取簡略的那個commitId）

回退revert及回退某次合并

分支多，合并也多，先說合并merge，merge xxx1 into xxx2這個命令中，xxx1是傳入分支，xxx2是當(dāng)前分支，把xxx1分支上的代碼合并到xxx2這個分支上，xxx1上新的代碼就到了xxx2上了。比如我自己新開發(fā)的一個業(yè)務(wù)分支開發(fā)測試都搞得差不多，那我就準(zhǔn)備合并到release，很好理解，但是合并完過一段時間被告知不對，不應(yīng)該上去，產(chǎn)品還有別的想法?，那就revert吧，（由于前面的原因，reset是被禁止的）revert有優(yōu)點，會只影響那一次提交的的代碼，但是缺點是會產(chǎn)生一個新的節(jié)點，revert merge又有不同，還拿上面的例子，假如提前合并上了不該上的代碼，那只能revert，具體代碼git revert xxxxx -m 1 xxxxx還是commitId，1表示當(dāng)前分支為準(zhǔn)，2表示傳入分支為準(zhǔn)，一般都是1，然后自己的特性分支又改了很多，等到了要上release的時候是沒法在直接merge的，因為revert是一個比較新的節(jié)點，這樣就要再次revert那個revert提交的commit（和第一次commit不一樣，是revert的commit），完了再進(jìn)行merge自己特性分支最新的代碼就可以了（來回merge加revert超亂的，下次誰出問題直接打死他?）

分支污染

分支污染這個問題主要是針對多個開發(fā)任務(wù)并行的情況，比如這個優(yōu)惠券功能打算下周上，那個價格比對功能下下周上，那么這兩個分支千萬不能互相合并，或者間接合并，道理很簡單，但是任務(wù)一多很容易亂，還有，多個特性任務(wù)分支可以隨時把release合并進(jìn)來（最好經(jīng)常合并以保持同步），因為這是最終版本，但是不能合并除release之外的其他分支，特別是test/dev分支，test/dev分支上存在了許多各種橫死的/半死的項目，這些千萬不能出到其他分支，要不然其他分支上到release就把這些垃圾內(nèi)容帶過去上線。總之，各公司情況不同，但是大致結(jié)構(gòu)差不多，把握好單向的代碼流就好。

復(fù)雜場景

實際情況可能很復(fù)雜，因為我們公司用json來保存用戶級的各種配置，tsx對某些大型組件里面字段類型做校驗，這些都是自動生成的，有時候只改了一點配置，就生成了一大堆更改，這樣的反復(fù)多人在不同分支修改以后，一合并沖突的連它媽都不認(rèn)識了，這個仍是當(dāng)前項目的痛點，有可能每次合并就要花去單人半天一天的工作量，這樣的只能手動修改合并，借助編輯器內(nèi)部工具，如果后期有時間可能會把node層json配置改為mongoDB，但是本地json配置還沒有好辦法，歡迎留言區(qū)提出方案。

編輯器內(nèi)部git工具（vscode的gitlens和webstorm）

vscode里面的必裝插件gitlens最近進(jìn)行了更新，合并等功能已經(jīng)快趕上webstorm了，合并的三欄式布局適合修改一些復(fù)雜沖突，左右是當(dāng)前以及傳入的代碼，中間是自己的修改，非常的科學(xué)，還有很多功能如查看當(dāng)前這個文件所有的歷史更改，與某個分支的某個文件的快速比對等等功能，解決了復(fù)雜項目的很多痛點。

提交鉤子及繞過

公司對git有很多規(guī)范，禁止了push -f，對commit提交的備注信息做了限制，這個是在自己項目的.git/hooks/里面有限制，可以自己修改，我們統(tǒng)一是必須攜帶JIRA任務(wù)號，便于JIRA統(tǒng)計或者提交的是merge信息，但如果想跳過的話（規(guī)則就是用來打破的，?），可以在SourceTree提交里設(shè)置繞過鉤子提交

tag的問題

實際在多人協(xié)作項目里使用git，基本沒有打過tag，tag的問題就在于如果和分支名字一樣，切換/合并分支容易到tag，而且打了錯誤的不合適的tag，必須遠(yuǎn)程和所有本地一起刪除tag，要不然只要有一個人本地有tag，一push又到了遠(yuǎn)程，難以去除，一般都是在運(yùn)維用jenkins部署時打個上線日期tag，便于回退（但是如果jenkins部署打的tag不規(guī)范、重名，也會引發(fā)前端代碼庫提交各類問題）。

總結(jié)

git這東西說簡單也簡單，說難有的問題直撓頭皮，但是我覺得，最重要的是要養(yǎng)成一個好的提交習(xí)慣，提交本地前先三思，提交到遠(yuǎn)程前再想一遍，避免翻車，對團(tuán)隊代碼造成災(zāi)難型的后果，影響他人工作。 純手敲出這么多字，如果感覺有些幫助，那我就很滿足了，如果有問題盡管提，共同進(jìn)步！

總結(jié)

以上是生活随笔為你收集整理的git管理复杂项目代码的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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