Git提交規範流程和解決衝突實際使用

前言：GIT對於咱們程序員來講是吃飯的工具，本篇主要是針對提交和分支以及對於大多數程序員聞風喪膽的衝突一些我的看法，若是有啥不對的或者大家公司git提交流程歡迎下方評論。

在討論規範以前，咱們須要定最基本的要求

1.團隊內保持良好的代碼格式便於易讀和維護，最主要減小沒必要要的代碼衝突（建議統一使用開發工具（idea）的代碼格式化）。

2.提交任何代碼必須確認代碼可運行

3.提交的代碼必須移除無用的包路徑引用和無用的依賴，儘可能不要使用過時的方法或者類

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提交按鈕

點擊提交按鈕就能清楚的看到git status的狀況，有修改的有哪些文件，哪些文件須要提交git，哪些文件不須要提交git。若是臨時或者不當心動的地方可使用revert恢復到修改前。

若是這個文件不須要修改，或者不當心空格等操做，直接使用 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的記錄直接操做便可。

博客地址：my.oschina.net/wangnian