文章收錄在 GitHub JavaKeeper ，N線網際網路開發必備技能兵器譜
Git 使用規範
團隊開發中，遵循一個合理、清晰的 Git 使用流程，是非常重要的。
否則，各種不清晰的分支結構，後續産品疊代或維護都會讓人很頭疼，再如果每個程式員都送出一堆雜亂無章的commit，後續的快速查找定位問題隻能通過閱讀代碼，也是很低效的。
分支規範
幾乎所有的版本控制系統都以某種形式支援分支。 使用分支意味着你可以把你的工作從開發主線上分離開來，以免影響開發主線。有人把 Git 的分支模型稱為它的“必殺技特性”，因為基于指針的實作使其足夠輕量。
Git 鼓勵在工作流程中頻繁地使用分支與合并，哪怕一天之内進行許多次，但仍要遵循一定的規範
分支命名
- master 分支
- master 為主分支，也是用于部署生産環境的分支，master 分支要確定穩定性
- master 分支一般由 develop 以及 hotfix 分支合并，任何時間都不能直接修改代碼
- develop 分支
- develop 為開發分支，始終保持最新完成以及bug修複後的代碼
- 一般開發新功能時，feature 分支都是基于 develop 分支下建立的
- feature 分支
- 開發新功能時，以 develop 分支為基礎建立 feature 分支
- 分支命名: feature/ 開頭的為特性分支， 命名規則: feature/user_module、 feature/cart_module
- release 分支
- release 為預上線分支，釋出提測階段，以 release 分支代碼為基準提測
- hotfix 分支
- 分支命名: hotfix/ 開頭的為修複分支，它的命名規則與 feature 分支類似
- 線上出現緊急問題時，需要及時修複，以 master 分支為基線，建立 hotfix 分支，修複完成後，需要合并到 master 分支和 develop 分支
當有一組 feature 開發完成，首先會合并到 develop 分支，進入提測時，會建立 release 分支。
如果測試過程中存在 bug 需要修複，則直接由開發者在 release 分支修複并送出。
當測試完成之後，合并 release 分支到 master 和 develop 分支，此時 master 為最新代碼，用作上線。
以上規範不一定是必須的，一般是根據實際情況來的，總結下自己工作中的一些問題
- 自己的分支一定要自測，切記不要送出後，影響到其他代碼，更别說别人拉下代碼還報錯這種低級錯誤
- 本地分支要做到勤送出，分小功能送出，一次送出一大堆各種功能的做法也要杜絕
- 每天第一件事就是更新 develop 分支内容到本地分支，避免大規模 merge，太容易出錯了
- 疊代新版本時，一定要保證目前開發分支和線上分支一樣
送出規範
我們都知道，Git 每次送出代碼，都要寫 Commit message（送出說明），否則就不允許送出，這其實就是規範，但輸入的說明我們可以随便寫，之前我也會随便寫，被 XX 之後就，，，
$ git commit -m "hello world" 上面代碼的 -m 參數，就是用來指定 commit message 的。
如果一行不夠，可以隻執行git commit，就會跳出文本編輯器，讓你寫多行。
一般來說，commit message 應該清晰明了，說明本次送出的目的。而且多人協作的時候，有問題也友善檢視送出日志。
目前，社群有多種 Commit message 的寫法規範。來自Angular 規範是目前使用最廣的寫法，比較合理和系統化。如下圖：
每次送出，Commit message 都包括三個部分：Header，Body 和 Footer。
<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer> 其中，Header 是必需的，Body 和 Footer 可以省略。
不管是哪一個部分，任何一行都不要有太多字元。這是為了避免自動換行影響美觀。
Head
Header部分隻有一行，包括三個字段：
type
（必填）、
scope
（影響範圍，選填）和
subject
（必填）。
type
type
用于說明 commit 的類别，隻允許使用下面7個辨別（或者用對應的 emoji 表情，在前邊再加一個
:
就會顯示了）。
- feat：新功能（✨）
- fix：修補bug（ 🚑）
- docs：修改文檔（📚）
- style： 格式化代碼結構，沒有邏輯上的代碼修改（🎨)
- refactor：重構，即不是新增功能，也不是修改bug的代碼變動，比如重命名變量（🚜）
- test：增加測試代碼，單元測試一類的，沒有生産代碼的變更（🔬）
- chore：建構過程或輔助工具的變動（不會影響代碼運作）
scope
scope
用于定義
type
影響的範圍，比如資料層、控制層、視圖層等等，視項目不同而不同。
subject
subject
是 commit 目的的簡短描述，不超過50個字元。
Body
Body 部分是對本次 commit 的較長的描述，可以分成多行，每行盡量不超過72個字元。
Footer
Footer 部分隻用于兩種情況
- 不相容變動：如果目前代碼與上一個版本不相容，則 Footer 部分以
BREAKING CHANGE
- 關閉 Issue：如果目前 commit 針對某個issue，那麼可以在 Footer 部分關閉這個 issue 。
Closes #234 Closes #123, #245, #992
Revert
還有一種特殊情況，如果目前 commit 用于撤銷以前的 commit，則必須以
revert:
開頭，後面跟着被撤銷 Commit 的 Header。
revert: feat(pencil): add 'graphiteWidth' option
This reverts commit 667ecc1654a317a13331b17617d973392f415f02. 再推薦一個編寫 Commit message 的工具，Commitizen：
https://github.com/commitizen/cz-cli這麼多規範有什麼用嗎，如果項目中隻有兩三個人開發，其實也不需要嚴格的規範，隻要把送出内容寫清楚就行，但是大型項目，開發人員較多，規範送出還是有必要的
格式化的Commit message，有幾個好處
- 提供更多的曆史資訊，友善快速浏覽
比如，下面的指令顯示上次釋出後的變動，每個 commit 占據一行。你隻看行首，就知道某次 commit 的目的。
$ git log <last tag> HEAD --pretty=format:%s - 可以過濾某些commit（比如文檔改動），便于快速查找資訊
比如，下面的指令僅僅顯示本次釋出新增加的功能
$ git log <last release> HEAD --grep feature - 可以直接從 commit 生成 Change log（Change Log 是釋出新版本時，用來說明與上一個版本差異的文檔）
最後列出一些 git 送出支援的 emoji 表情，就算是看GitHub 或 GitLab，也很有意思，也是目前我們項目使用的方式。
| Emoji | Raw Emoji Code | Description |
|---|---|---|
| 🎨 | | when improving the format/structure of the code |
| 📰 | | when creating a new file |
| 📝 | | when performing minor changes/fixing the code or language |
| 🐎 | | when improving performance |
| 📚 | | when writing docs |
| 🐛 | | when reporting a bug, with |
| 🚑 | | when fixing a bug |
| 🐧 | | when fixing something on Linux |
| 🍎 | | when fixing something on Mac OS |
| 🏁 | | when fixing something on Windows |
| 🔥 | | when removing code or files, maybe with |
| 🚜 | | when change file structure. Usually together with 🎨 |
| 🔨 | | when refactoring code |
| ☔️ | | when adding tests |
| 🔬 | | when adding code coverage |
| 💚 | | when fixing the CI build |
| 🔒 | | when dealing with security |
| ⬆️ | | when upgrading dependencies |
| ⬇️ | | when downgrading dependencies |
| ⏩ | | when forward-porting features from an older version/branch |
| ⏪ | | when backporting features from a newer version/branch |
| 👕 | | when removing linter/strict/deprecation warnings |
| 💄 | | when improving UI/Cosmetic |
| ♿️ | | when improving accessibility |
| 🌐 | | when dealing with globalization/internationalization/i18n/g11n |
| 🚧 | | WIP(Work In Progress) Commits, maybe with |
| 💎 | | New Release |
| 🥚 | | New Release with Python egg |
| 🎡 | | New Release with Python wheel package |
| 🔖 | | Version Tags |
| 🎉 | | Initial Commit |
| 🔈 | | when Adding Logging |
| 🔇 | | when Reducing Logging |
| ✨ | | when introducing New Features |
| ⚡️ | | when introducing Backward-InCompatible Features, maybe with |
| 💡 | | New Idea, with |
| ❄️ | | changing Configuration, Usually together with 🐧 or 🎀 or 🚀 |
| 🎀 | | Customer requested application Customization, with |
| 🚀 | | Anything related to Deployments/DevOps |
| 🐘 | | PostgreSQL Database specific (Migrations, Scripts, Extensions, ...) |
| 🐬 | | MySQL Database specific (Migrations, Scripts, Extensions, ...) |
| 🍃 | | MongoDB Database specific (Migrations, Scripts, Extensions, ...) |
| 🏦 | | Generic Database specific (Migrations, Scripts, Extensions, ...) |
| 🐳 | | Docker Configuration |
| 🤝 | | when Merge files |
| 🍒 | | when Commit Arise from one or more Cherry-Pick Commit(s) |