Git提交規(guī)范有哪些

Git提交規(guī)范有哪些，針對(duì)這個(gè)問(wèn)題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問(wèn)題的小伙伴找到更簡(jiǎn)單易行的方法。

1 . commit message規(guī)范

規(guī)范格式:

<type>: <subject>

**type  **

• feature: 新功能（feature）

• fix: 修補(bǔ)bug、style等

• refactor: 重構(gòu)（即不是新增功能，也不是修改bug的代碼變動(dòng)）

• test: 增加測(cè)試 chore: 構(gòu)建過(guò)程或輔助工具的變動(dòng)

subject

提交目的的簡(jiǎn)短描述，描述做了啥或者改了啥，如果有團(tuán)隊(duì)管理工具(issue ,JIRA)或者產(chǎn)品需求，必須以內(nèi)部命名的需求代號(hào)作為描述信息的一部分，方便查看日志，合并和cherry-pick。

舉例：

1. feature:開(kāi)發(fā)完成#代號(hào) XXX.XXX需求

2. fix:修改 #代號(hào) XXXX查詢問(wèn)題

2. 提交規(guī)范以及GIT開(kāi)發(fā)流程

**Git分支 **

1. master        （生產(chǎn)環(huán)境）    部署某個(gè)uat功能到準(zhǔn)生產(chǎn)的時(shí)候合并到master，只允許uat分支合并/cherry-pick。

2. uat              （測(cè)試環(huán)境）    部署某個(gè)feature分支到測(cè)試的時(shí)候合并到uat，只允許feature分支合并。

3. feature/xxxx  (特性分支)      開(kāi)發(fā)一個(gè)功能或者修改bug的時(shí)候合并/提交到feature

4. dev/xx           (本地開(kāi)發(fā)版本)

在開(kāi)發(fā)之前，需要在master分支上切一個(gè)以需求,BUG,重構(gòu).......命名feature分支 ，比如  feature/項(xiàng)目編號(hào)（BUG的代號(hào)）

2.1  本地沒(méi)有項(xiàng)目，克隆代碼的并切換到開(kāi)發(fā)分支

克隆并在需要開(kāi)發(fā)的feature分支上創(chuàng)建本地dev開(kāi)發(fā)分支，本地分支可以以dev/自己標(biāo)識(shí)的英文 命名。

git clone -b dev/xx  feature/項(xiàng)目編號(hào)

2.2  本地有項(xiàng)目，切換開(kāi)發(fā)分支

為了避免本地分支與遠(yuǎn)程不一致，需要切換到 feature/項(xiàng)目編號(hào)分支，更新一下。

git checkout feature/項(xiàng)目編號(hào)

git pull

再在 feature/項(xiàng)目編號(hào)上切出自己的開(kāi)發(fā)分支

git checkout dev/xx

2.3 提交代碼

注意:必須把不需要提交的后綴或者文件添加到和.git同目錄的 .gitignore文件中

添加修改的文件到暫存區(qū)(staging area)

git add .

將修改后的文件提交到本地的版本庫(kù)中

git commit -m 'fix:修改了XXXXX'

也可以兩步合成一步操作

git commit -am 'fix:修改了XXXXX'

提交代碼我個(gè)人是建議最好使用idea或者其他git圖形化界面來(lái)操作勾選需要添加的文件，或者操作。

git后面的圖標(biāo)對(duì)應(yīng)的意思

• 第一個(gè)是 git 拉代碼操作按鈕

• 第二個(gè)是 git 提交操作按鈕

• 第三個(gè)是 git log操作按鈕

• 第四個(gè)是 git revert操作按鈕

首先點(diǎn)擊git提交按鈕

如果這個(gè)文件不需要修改，或者不小心空格等操作，直接使用 revert恢復(fù)

如果這個(gè)文件是項(xiàng)目啟動(dòng)時(shí)候生成的，比如項(xiàng)目導(dǎo)出的excel或者log日志，直接使用 delete刪掉

小技巧:大家在開(kāi)發(fā)過(guò)程中，可以隨時(shí)進(jìn)入上圖的提交界面直觀的看到哪些文件有變動(dòng)，更方便和更高效的管理自己修改的內(nèi)容，其他桌面圖形化也可以，比如  TortoiseGit，Source Tree，以及git自帶的兩個(gè) gitk 和 git-gui (在git目錄里輸入命令)。

2.4 推送到遠(yuǎn)程分支

在推送本地分支dev到遠(yuǎn)程dev的時(shí)候，需要先切換到 feature/項(xiàng)目編號(hào)分支,merge遠(yuǎn)程分支代碼。

git checkout feature/項(xiàng)目編號(hào)
git pull

再切換到自己的開(kāi)發(fā)分支dev/xxx

git checkout dev/xxx

rebase feature/項(xiàng)目編號(hào)到自己dev/xxx，主要作用就是檢查是否有沖突。

git rebase feature/項(xiàng)目編號(hào)

沒(méi)有沖突，直接push dev/xxx到遠(yuǎn)程 dev/xxx

git  push  origin dev/xxx

如果有沖突，可以在合并沖突后的任意時(shí)刻使用 git status 命令來(lái)查看那些因包含合并沖突而處于未合并（unmerged）狀態(tài)的文件

git status

所有合并中沖突而待解決的文件，都會(huì)以未合并狀態(tài)標(biāo)識(shí)出來(lái)。 Git 會(huì)在有沖突的文件中加入標(biāo)準(zhǔn)的沖突解決標(biāo)記，這樣你可以打開(kāi)這些包含沖突的文件然后手動(dòng)解決沖突。

<<<<<<< HEAD:index.html
<div id="footer">contact : email.support@github.com</div>
=======
<div id="footer">
 please contact us at support@github.com
</div>
>>>>>>> dev/xx:index.html

以上文件內(nèi)容表示head指向的(也就是rebase的那個(gè)分支)版本和下面dev/xx指向的版本有沖突

=======為分割線，上半部分是head指向的分支的版本的代碼，下半部分是dev/xx分支所指向的版本的代碼

上述的沖突解決方案僅保留了其中一個(gè)分支的修改，并且<<<<<<< , ======= , 和 >>>>>>> 這些行需要被完全刪除。

修改完成之后需要操作

git add .

使用 git add 命令來(lái)將其標(biāo)記為沖突已解決。 一旦暫存這些原本有沖突的文件，Git 就會(huì)將它們標(biāo)記為沖突已解決

然后繼續(xù)rebase操作:

git rebase --continue

一直循環(huán)rebase --continue，直到rebase成功

然后push

git  push  origin dev/xxx

最后登錄gitlab或者coding的web管理，提交合并請(qǐng)求，將遠(yuǎn)程分支dev/xxx和遠(yuǎn)程分支feature/項(xiàng)目編號(hào)分支合并，合并之后才能表示你的提交完成了。等f(wàn)eature分支所有的人開(kāi)發(fā)完成并測(cè)試通過(guò)之后，再將feature合并到uat進(jìn)行上線測(cè)試。

現(xiàn)在我們看看借助我們神器idea來(lái)解決沖突。

在操作 merge，rebase,cherry-pick   ,當(dāng)有沖突的會(huì)彈出conflicts

解決完成之后apply之后直接push就可以了。

總結(jié):

對(duì)于git而言，只有push和pull操作才會(huì)和遠(yuǎn)程打交道，其他的命令都是本地完成的，也就是說(shuō)只有pull,push或者在git平臺(tái)上直接發(fā)起遠(yuǎn)程分支和遠(yuǎn)程分支合并請(qǐng)求的時(shí)候才真正知道有木有沖突。即使本地rebase feature ，但還是沒(méi)有辦法保證dev和feature沒(méi)有沖突，因?yàn)槟鉹ebase的時(shí)候不能代表你當(dāng)前本地feature分支和你發(fā)起合并請(qǐng)求時(shí)候的feature分支的代碼完全一致，所以rebase feature 只是提前降低了合并feature時(shí)候的沖突。

對(duì)于git操作的流程，大家使用習(xí)慣有些不一樣，實(shí)際上怎么操作都沒(méi)有錯(cuò)，如果公司，團(tuán)隊(duì)有所認(rèn)可的規(guī)范，還是按照規(guī)范來(lái)。

**常見(jiàn)的提交方式 **:

1.直接在feature分支開(kāi)發(fā)，每個(gè)人在commit之前pull（git fetch + git merge）一下新的feature的代碼，然后有沖突一次性解決之后 add. commit  push。

2.直接在feature分支開(kāi)發(fā)，每個(gè)人先commit到本地分支，然后pull --rebase （git fetch + git rebase）當(dāng)前新的feature的代碼，然后有沖突解決之后 add.    push。

3.就是我上面寫(xiě)的嚴(yán)格操作，每個(gè)人都有一個(gè)自己命名的本地開(kāi)發(fā)分支，通過(guò)和本地的將要合并的本地分支merge或者rebase來(lái)解決沖突，然后通過(guò)web平臺(tái)的請(qǐng)求來(lái)合并。

4.歡迎大家提供更多牛逼哄哄的方式。。。。。。。

第一種，是最簡(jiǎn)單的，最常見(jiàn)的操作的方式，這種方式容易在解決沖突的時(shí)候把自己修改的代碼弄丟，操成無(wú)法挽回的結(jié)果。（大家可以借助idea本地的歷史回滾也是可以）

第二種，先提交，再拉代碼rebase，可以保證自己的代碼提交到了本地分支，不管之后怎么瞎操作改代碼都不會(huì)丟失這條已提交的commit。

第三種，操作有點(diǎn)復(fù)雜，雖然繞了一點(diǎn)彎路，但是和第二種相比較，主要區(qū)分就是feature分支允不允許直接提交。如果允許，那feature合并的權(quán)限控制就放在合并到uat的這個(gè)環(huán)節(jié)。

簡(jiǎn)單的理解:GIT的操作無(wú)非就****是拉代碼，推代碼，合并代碼，在每一步和遠(yuǎn)程分支打交道的操作才會(huì)真正出現(xiàn)沖突。但是什么時(shí)候提前解決沖突或者以什么方式解決沖突有很多種。

不管你用什么圖形化工具，但是我們需要先搞清楚git的基本命令，以及每一步圖形化工具操作的背后git操作的命令。

警告：有沒(méi)push的代碼不要?jiǎng)h.git目錄，你懂得。

沒(méi)有解決沖突然后強(qiáng)行push的后果，哈哈哈，我笑了

**彩蛋; **

上面提交的知識(shí)講完了，我們拓展一下知識(shí)

1.reset怎么用？

用法：

git reset --mixed/--hard/--soft c27894c06a2cc23e4097a93013cf640cc4fd527d


git reset –mixed HEAD~1 
回退一個(gè)版本,且會(huì)將暫存區(qū)的內(nèi)容和本地已提交的內(nèi)容全部恢復(fù)到未暫存的狀態(tài),不影響原來(lái)本地文件(未提交的也 
不受影響) ,也就是恢復(fù)到add之前
git reset –soft HEAD~1 
回退一個(gè)版本,不清空暫存區(qū),將已提交的內(nèi)容恢復(fù)到暫存區(qū),不影響原來(lái)本地的文件(未提交的也不受影響),也就是恢復(fù)到commit之前
git reset –hard HEAD~1 
回退一個(gè)版本,清空暫存區(qū),將已提交的內(nèi)容的版本恢復(fù)到本地,本地的文件也將被回退的版本替換，也就是恢復(fù)到?jīng)]開(kāi)發(fā)之前

首先強(qiáng)調(diào)已上線的項(xiàng)目reset不建議使用，也禁止使用，為啥這么說(shuō)呢？

git本身就是存儲(chǔ)代碼所有歷史記錄，不管你是錯(cuò)誤提交還是提交的代碼有BUG，應(yīng)該是在錯(cuò)誤的基礎(chǔ)上再commit一條你修正的提交，而不是撤銷你已經(jīng)提交到遠(yuǎn)程分支的代碼。

如果你不小心把一部小電影提交到了GIT，或者你想“刪代碼跑路“，再或者你的改動(dòng)操成了成千上萬(wàn)的BUG， reset之后，需要強(qiáng)制push到遠(yuǎn)程分支，reset點(diǎn)之后的遠(yuǎn)程分支的提交的記錄將永久消失。

2.我想合并uat分支的某次提交之前的代碼

 git  checkout -b uat20190711 c27894c06a2cc23e4097a93013cf640cc4fd527d

可以push到遠(yuǎn)程再和其他分支合并或者切換其他分支rebase直接push

3.cherry-pick這么用？

git  cherry-pick -x -n 017822ece3049d3f46c72cabf32dee9f44dd15cc

將某一次提交的改動(dòng)直接在當(dāng)前分支上做修改，然后提交即可，所以提交的commit就需要寫(xiě)清楚你提交的意圖。

-x 保留原作者  -n 不自動(dòng)提交

圖形化工具截圖，自己摸索，都一個(gè)樣，找到某一條commit的記錄直接操作即可。

關(guān)于Git提交規(guī)范有哪些問(wèn)題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒(méi)有解開(kāi)，可以關(guān)注億速云行業(yè)資訊頻道了解更多相關(guān)知識(shí)。