### 一、前言
Git是我們每日工作中都會接觸到的工具。它給我們帶來了極大的便利，但隨之而來的也在團隊中使用出現了各式各樣的風格，這些風格我們并不認為它是錯的，只能說不太適合現在日益壯大的團隊。團隊的壯大也有我們每一個人的汗水，希望各位能盡量遵循現有規范，達到log日志語義化，分支名稱標準化。謝謝
*****
### 二、Git日志格式規范
`{type}: {subject}`
- type ：表示提交信息的類型，具體為一下可選項中的任意一種：
| 可選項 | 含義 |
| --- | --- |
| feat | 添加功能 |
| fix | 修復bug |
| opt | 優化功能 |
| merge | 合并代碼 |
- subject ：表示提交的內容，中英文均可，**建議中文**
- 例子：??
上面的例子我們對`yarn.lock`文件進行了修改，假設我們這是一個需求，就是在這個文件中添加空格，那么我們提交時log日志便是這樣的：`git commit -m "feat: 添加空格"`，其中`feat`代表我們此次提交的類型為**新增**，而`：`后面便是我們對此次提交的說明。
*****
### 三、Git分支格式規范
`{type}-{id}-{task}-{createTime}`
- type ：表示分支的類型，具體為一下可選項中的任意一種：
| 可選項 | 含義 |
| --- | --- |
| feat | 添加功能 |
| fix | 修復bug |
| opt | 優化功能 |
| merge | 合并代碼 |
- id ：表示`需求id`，此id可以去`禪道上查看（需求前面的數字）`：
- task ：表示`需求名稱`，名稱使用**駝峰方式連接**
- createTime ：分支創建的時間，以當前時間為例：`190415`代表著19年4月15日
- 例子：??
以上面提到的id為`013`的需求為例，我們試著創建一個分支：
`feat-013-salesBonus-190415`，這樣我們的分支就建立好了。so easy
*****
### 三、代碼合并規范
寫在最后也是最為嚴重的問題。合并代碼對其他人代碼的覆蓋以及部分的**丟失**問題比較**嚴重**，所以我們`merge`代碼時如果遇到沖突一定要找到和你沖突的人**面對面**進行解決。提交前需對修改代碼進行`diff`后在提交。盡量避免此類問題再次出現在團隊中。這樣大家辛苦工作的成果也不會因為這類意外而**付之東流**。
