Git提交規范有哪些

Git提交規范有哪些，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

1 . commit message規范

規范格式:

<type>: <subject>

**type  **

• feature: 新功能（feature）

• fix: 修補bug、style等

• refactor: 重構（即不是新增功能，也不是修改bug的代碼變動）

• test: 增加測試 chore: 構建過程或輔助工具的變動

subject

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

舉例：

1. feature:開發完成#代號 XXX.XXX需求

2. fix:修改 #代號 XXXX查詢問題

2. 提交規范以及GIT開發流程

**Git分支 **

1. master        （生產環境）    部署某個uat功能到準生產的時候合并到master，只允許uat分支合并/cherry-pick。

2. uat              （測試環境）    部署某個feature分支到測試的時候合并到uat，只允許feature分支合并。

3. feature/xxxx  (特性分支)      開發一個功能或者修改bug的時候合并/提交到feature

4. dev/xx           (本地開發版本)

在開發之前，需要在master分支上切一個以需求,BUG,重構.......命名feature分支 ，比如  feature/項目編號（BUG的代號）

2.1  本地沒有項目，克隆代碼的并切換到開發分支

克隆并在需要開發的feature分支上創建本地dev開發分支，本地分支可以以dev/自己標識的英文 命名。

git clone -b dev/xx  feature/項目編號

2.2  本地有項目，切換開發分支

為了避免本地分支與遠程不一致，需要切換到 feature/項目編號分支，更新一下。

git checkout feature/項目編號

git pull

再在 feature/項目編號上切出自己的開發分支

git checkout dev/xx

2.3 提交代碼

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

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

git add .

將修改后的文件提交到本地的版本庫中

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

也可以兩步合成一步操作

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

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

git后面的圖標對應的意思

• 第一個是 git 拉代碼操作按鈕

• 第二個是 git 提交操作按鈕

• 第三個是 git log操作按鈕

• 第四個是 git revert操作按鈕

首先點擊git提交按鈕

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

如果這個文件是項目啟動時候生成的，比如項目導出的excel或者log日志，直接使用 delete刪掉

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

2.4 推送到遠程分支

在推送本地分支dev到遠程dev的時候，需要先切換到 feature/項目編號分支,merge遠程分支代碼。

git checkout feature/項目編號
git pull

再切換到自己的開發分支dev/xxx

git checkout dev/xxx

rebase feature/項目編號到自己dev/xxx，主要作用就是檢查是否有沖突。

git rebase feature/項目編號

沒有沖突，直接push dev/xxx到遠程 dev/xxx

git  push  origin dev/xxx

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

git status

所有合并中沖突而待解決的文件，都會以未合并狀態標識出來。 Git 會在有沖突的文件中加入標準的沖突解決標記，這樣你可以打開這些包含沖突的文件然后手動解決沖突。

<<<<<<< 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

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

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

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

修改完成之后需要操作

git add .

使用 git add 命令來將其標記為沖突已解決。 一旦暫存這些原本有沖突的文件，Git 就會將它們標記為沖突已解決

然后繼續rebase操作:

git rebase --continue

一直循環rebase --continue，直到rebase成功

然后push

git  push  origin dev/xxx

最后登錄gitlab或者coding的web管理，提交合并請求，將遠程分支dev/xxx和遠程分支feature/項目編號分支合并，合并之后才能表示你的提交完成了。等feature分支所有的人開發完成并測試通過之后，再將feature合并到uat進行上線測試。

現在我們看看借助我們神器idea來解決沖突。

在操作 merge，rebase,cherry-pick   ,當有沖突的會彈出conflicts

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

總結:

對于git而言，只有push和pull操作才會和遠程打交道，其他的命令都是本地完成的，也就是說只有pull,push或者在git平臺上直接發起遠程分支和遠程分支合并請求的時候才真正知道有木有沖突。即使本地rebase feature ，但還是沒有辦法保證dev和feature沒有沖突，因為你rebase的時候不能代表你當前本地feature分支和你發起合并請求時候的feature分支的代碼完全一致，所以rebase feature 只是提前降低了合并feature時候的沖突。

對于git操作的流程，大家使用習慣有些不一樣，實際上怎么操作都沒有錯，如果公司，團隊有所認可的規范，還是按照規范來。

**常見的提交方式 **:

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

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

3.就是我上面寫的嚴格操作，每個人都有一個自己命名的本地開發分支，通過和本地的將要合并的本地分支merge或者rebase來解決沖突，然后通過web平臺的請求來合并。

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

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

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

第三種，操作有點復雜，雖然繞了一點彎路，但是和第二種相比較，主要區分就是feature分支允不允許直接提交。如果允許，那feature合并的權限控制就放在合并到uat的這個環節。

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

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

警告：有沒push的代碼不要刪.git目錄，你懂得。

沒有解決沖突然后強行push的后果，哈哈哈，我笑了

**彩蛋; **

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

1.reset怎么用？

用法：

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


git reset –mixed HEAD~1 
回退一個版本,且會將暫存區的內容和本地已提交的內容全部恢復到未暫存的狀態,不影響原來本地文件(未提交的也 
不受影響) ,也就是恢復到add之前
git reset –soft HEAD~1 
回退一個版本,不清空暫存區,將已提交的內容恢復到暫存區,不影響原來本地的文件(未提交的也不受影響),也就是恢復到commit之前
git reset –hard HEAD~1 
回退一個版本,清空暫存區,將已提交的內容的版本恢復到本地,本地的文件也將被回退的版本替換，也就是恢復到沒開發之前

首先強調已上線的項目reset不建議使用，也禁止使用，為啥這么說呢？

git本身就是存儲代碼所有歷史記錄，不管你是錯誤提交還是提交的代碼有BUG，應該是在錯誤的基礎上再commit一條你修正的提交，而不是撤銷你已經提交到遠程分支的代碼。

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

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

 git  checkout -b uat20190711 c27894c06a2cc23e4097a93013cf640cc4fd527d

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

3.cherry-pick這么用？

git  cherry-pick -x -n 017822ece3049d3f46c72cabf32dee9f44dd15cc

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

-x 保留原作者  -n 不自動提交

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

關于Git提交規范有哪些問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。