文章收錄在 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 |
|---|---|---|
| 🎨 | :art: |
when improving the format/structure of the code |
| 📰 | :newspaper: |
when creating a new file |
| 📝 | :pencil: |
when performing minor changes/fixing the code or language |
| 🐎 | :racehorse: |
when improving performance |
| 📚 | :books: |
when writing docs |
| 🐛 | :bug: |
when reporting a bug, with @FIXMEComment Tag |
| 🚑 | :ambulance: |
when fixing a bug |
| 🐧 | :penguin: |
when fixing something on Linux |
| 🍎 | :apple: |
when fixing something on Mac OS |
| 🏁 | :checkered_flag: |
when fixing something on Windows |
| 🔥 | :fire: |
when removing code or files, maybe with @CHANGED Comment Tag |
| 🚜 | :tractor: |
when change file structure. Usually together with 🎨 |
| 🔨 | :hammer: |
when refactoring code |
| ☔️ | :umbrella: |
when adding tests |
| 🔬 | :microscope: |
when adding code coverage |
| 💚 | :green_heart: |
when fixing the CI build |
| 🔒 | :lock: |
when dealing with security |
| ⬆️ | :arrow_up: |
when upgrading dependencies |
| ⬇️ | :arrow_down: |
when downgrading dependencies |
| ⏩ | :fast_forward: |
when forward-porting features from an older version/branch |
| ⏪ | :rewind: |
when backporting features from a newer version/branch |
| 👕 | :shirt: |
when removing linter/strict/deprecation warnings |
| 💄 | :lipstick: |
when improving UI/Cosmetic |
| ♿️ | :wheelchair: |
when improving accessibility |
| 🌐 | :globe_with_meridians: |
when dealing with globalization/internationalization/i18n/g11n |
| 🚧 | :construction: |
WIP(Work In Progress) Commits, maybe with @REVIEW Comment Tag |
| 💎 | :gem: |
New Release |
| 🥚 | :egg: |
New Release with Python egg |
| 🎡 | :ferris_wheel: |
New Release with Python wheel package |
| 🔖 | :bookmark: |
Version Tags |
| 🎉 | :tada: |
Initial Commit |
| 🔈 | :speaker: |
when Adding Logging |
| 🔇 | :mute: |
when Reducing Logging |
| ✨ | :sparkles: |
when introducing New Features |
| ⚡️ | :zap: |
when introducing Backward-InCompatible Features, maybe with @CHANGED Comment Tag |
| 💡 | :bulb: |
New Idea, with @IDEA Comment Tag |
| ❄️ | :snowflake: |
changing Configuration, Usually together with 🐧 or 🎀 or 🚀 |
| 🎀 | :ribbon: |
Customer requested application Customization, with @HACK Comment Tag |
| 🚀 | :rocket: |
Anything related to Deployments/DevOps |
| 🐘 | :elephant: |
PostgreSQL Database specific (Migrations, Scripts, Extensions, ...) |
| 🐬 | :dolphin: |
MySQL Database specific (Migrations, Scripts, Extensions, ...) |
| 🍃 | :leaves: |
MongoDB Database specific (Migrations, Scripts, Extensions, ...) |
| 🏦 | :bank: |
Generic Database specific (Migrations, Scripts, Extensions, ...) |
| 🐳 | :whale: |
Docker Configuration |
| 🤝 | :handshake: |
when Merge files |
| 🍒 | :cherries: |
when Commit Arise from one or more Cherry-Pick Commit(s) |
參考
https://github.com/slashsBin/styleguide-git-commit-message
http://www.ruanyifeng.com/blog/2016/01/commit_message_change_log.html
