使用GIT下團隊應該執行的風格與規範
2022 年 7 月 13 日
基本上版本控制已經是這個時代必須的工具了，許多git平台也一直不斷結合更多的功能，達到能推動軟體整體開發的工具。但在這部段更新的世界下，還是有些風格與規範是應該被遵守的。這邊整理了 Git Flow 和 Git Commit 兩個主要部份以共參考。
Git Commit
在版本控制系統中，提交（Commit）是紀錄程式改動的操作，根據設定不同，版本控制系統中的提交無限期地保存在存儲庫中，在任何時候我們都能回到特定版本下，特別是當你發現妳新改動的程式有問題的情況下。
因此我們會為了每一次的提交添加上一個 Message，這個訊息是為了說明這是程式更動的目的與內容。然而既然要寫文件（Message），就要有一個規範讓團隊來遵守，避免最後雜亂無章的管理結果。
如何寫一個好的Commit Message
每個團隊都會有自己的特別之處，這邊提供一個通用的基本原則，你應該要根據自己的團隊進行調整與修改。
- 使用英文進行撰寫
- 用空行將訊息切分成兩個部分，分別是標題與內文。
- 將標題長度限制為 50 個英文字母
- 在標題都以祈使語氣進行編寫
- 將內文應於 72 個單詞，必需少於80個單詞。
- 標題說明更新目的，內文說明調整項目、調整原因與調整方式
- 標題應該包含更新類型、影響範圍、調整摘要
這樣還不夠具體，我們需要一些範例。
# 基本結構
<Type>(<Scope>): <Short Summary>
<Body>Commit Type: build|ci|docs|feat|fix|perf|refactor|test
# 經常選用的標籤
- build：影響構建系統或外部依賴項的更改，也就是增加library之類的
- ci：對我們的 CI 配置文件和腳本的更改
- docs：僅文檔新增、更改
- feat：一個新功能
- fix：一個錯誤修復
- perf：提高性能的代碼更改
- refactor：既不修復錯誤也不添加功能的代碼更改
- test：添加缺失的測試或糾正現有的測試Commit Scope:
# 影響範圍，通常會有幾個方向可以選
# 根據專案: Video ad、EC、Shopping Mall
# 根據服務: Storage Service、Auth Service
# 根據檔案: config.json、.env
# 根據區塊: Animations、Core、Data Pipeline
# 根據物件: User、Client、Store、HostShort Summary：
# 別要忘記原則
# 將標題長度限制為 50 個英文字母
# 在標題都以祈使語氣進行編寫
- Refactor subsystem X for readability
- Update getting started documentation
- Remove deprecated methods
- Release version 1.0.0
- Merge pull request #123 from user/branch範例：
Simplify serialize.h's exception handling
Remove the 'state' and 'exceptmask' from serialize.h's stream
implementations, as well as related methods.
As exceptmask always included 'failbit', and setstate was always
called with bits = failbit, all it did was immediately raise an
exception. Get rid of those variables, and replace the setstate
with direct exception throwing (which also removes some dead
code).
As a result, good() is never reached after a failure (there are
only 2 calls, one of which is in tests), and can just be replaced
by !eof().
fail(), clear(n) and exceptions() are just never called. Delete
them.Git Flow
再來是Git Flow，基本上只是來說明應該要什麼時候進行分支，很多團隊都偏用根據魔法決定，但有個規範是不錯的。
基本上會分成四種類型
- develop
- release
- hotfix
- master除了develop可能會有很多條外，像是這樣
base on name: develop-tom、develop-simon
base on task: develop-mail-server、develop-user-auth其他的都應該只有個一條，說明一下各條功能與定位。
- release: 與develop合併的分支，通常會是測試主機使用的分支，測試主機應該與產品主機有相同的配置。
- hotfix: 從release長出來的分支，通常會是發現release分支有問題時，用來調整的用的分支，修正完成之後，會再與release和develop合併後消失。
- master: 產品主機用的分支，唯有系統已經成功在release分支上順利運行之後，才會進行合併，應要保持該分支維持最少量的更新。
