使用GIT下團隊應該執行的風格與規範

基本上版本控制已經是這個時代必須的工具了，許多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、Host

Short 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分支上順利運行之後，才會進行合併，應要保持該分支維持最少量的更新。