gitflow 進階規范
git cz
通過工具 git-cz 規范 git commit 提交信息。
使用
$ npm install -g git-cz
git commit 的講究
通過工具使用可以看出 git 本身及 github 社區對 git 提交單位及提交信息是有非常講究的要求的，這或許也是我之前給國外 repo 提 PR 被dis的主要原因??。
優點
可以通過命令快速對 log 進行篩選
$ git log <last release> HEAD --grep feat # 通過 feat 關鍵在查詢功能變更
具體如下：
- 如何界定何時提交一個 commit，如何定義 commit 提交目標
- 詳細待我口述
- 如何書寫 git message
- message 其實包含三部分: header、body、footer
- header 包含兩部分: type、subject
<type>[(<scope>)]: <emoji> <subject> // header 部分
[BLANK LINE] //空行
[body] // 長描述
[BLANK LINE]
[breaking changes] //
[BLANK LINE]
[footer]
其中，只有 header 為強制 message 必選項。
其中 header 限制為 50 個字符，其他每行不超過72個字符，主要為了美觀，避免換行
- subject
- 動詞開頭，第一人稱一般現在時祈使句。比如 change 而不是 changes 或 changed
- 首字母小寫
- 結尾不加句號（.）
- BREAKING CHANGE (不兼容改動)
當代碼改動與上個版本不兼容時，需要對 BREAKING CHANGE 進行描述，通常會記錄對改動的描述，改動的原因，以及遷移的方法。 - 關閉 Issue
當前 commit 針對某個 issue 時，可以填寫 Issue id
#234
husky （自動化神器，git hook 完美輔助）
知乎上有篇文章大概講了下這個神器。
主要能力是通過安裝 husky npm 包及工程根目錄的 package.json 部署 git hook。
hook 管理同 repo 一起，避免尷尬的 git hook 復制粘貼式維護，并且支持 node 腳本。
husky 配置已在單獨feat分支配置完畢，有興趣可以看上面的文章和 github 文檔學習。
- 使用
$ npm install husky --save-dev // 注意一定要用 --save-dev 安裝到本地，而非 -g 全局
lint-staged
那么問題來了，有了 husky，可以書寫一些提交的校驗腳本，但是卻無法區分校驗的內容是新提交的還是舊的已經有的。
不用怕，既然我們能想到，社區一定會有人遇到同樣的問題。祭出終極殺手锏，lint-staged。
這個東東一定要配合著 husky 使用才有效果，一樣，也是為了提供在提交時進行預處理的能力衍生的工具。
- 使用
$ npm install lint-staged --save-dev // 注意一定要用 --save-dev 安裝到本地，而非 -g 全局
問題及bug處理
- 當lint工具誤判或提交文件太多導致出錯時，可在操作后面加上 --no-verify 繞過lint檢查。
參考
- imagemin-lint-staged
- 手牽手使用Husky & Nodejs自定義你的Git鉤子
- 利用 ESlint、lint-staged 半自動提升項目代碼質量
- 用 husky 和 lint-staged 構建超溜的代碼檢查工作流
- Clean code linter
- 優雅的提交你的 Git Commit Message
- 【工具推薦】使用 husky 避免糟糕的 git commit
github-flow VS gitlab-flow 【三稿】
主干分支開發
特性分支開發
git flow
我們在 Google 上查關鍵詞“branch model”（也就是“分支模型”），有一篇排名比較靠前的文章“A successful Git branching model”，它介紹了 Git Flow 模型。
Git 剛出來的那些年，可參考的模型不多，所以 Git Flow 模型在 2011 年左右被大家當作了推薦的分支模型，至今也還有項目團隊在使用。然而，Git Flow 煩瑣的流程也被許多研發團隊吐槽，大家普遍認為 hotfix 和 release 分支顯得多余，平時都不會去用。
簡單解釋一下：
master
主干分支，用于保存已經發布的穩定代碼。圖中按時間線該分支已經從 0.1、0.2 發展到了 1.0版本。
develop
開發主干分支，從 master 分支切出，用于平時的集成開發和集成測試，其中的代碼主要用于下一次 relaese 發布，圖中的節點表示的是 1.0 的下一個版本。
feature branches
用于將來要發布的某個發布版本準備的 feature 特性分支，從 develop 分支切出。這個分支的含義非常豐富。舉例：圖中從左往右第一個分支，他的feature特性只是說會在將來某個版本上，但沒有確定，一般以做完的時間為主。而第二個feature分支卻是下個版本主要的特性分支代碼。
release branches
用于做發版的分支，一般承載下個版本的代碼發布，當然可以存在多個。在某個節點要發版時從 develop 切出。切出后這個分支只會為之后版本發布做 bug fix 相關的 commit 提交。在發版結束后，會同時向 develop 分支和 master 進行合并。并在 master 打 tag。release 分支即可刪除。
hotfix branches
一般用于發布后版本的 bug 修復，例如圖中，由于要修復 0.1 的一個bug，從 master 0.1 tag處切出 hotfix分支，修復完成后，將 hotfix 合入 develop 分支和 master 分支，在 master 打tag，并刪除 hotfix 分支。
GitHub Flow
GitHub Flow 是 GitHub 所使用的一種簡單流程。該流程只使用 master 和特性分支，并借助 GitHub 的 pull request 功能。
在 GitHub Flow 中，master 分支中包含穩定的代碼，它已經或即將被部署到生產環境。任何開發人員都不允許把未測試或未審查的代碼直接提交到 master 分支。對代碼的任何修改，包括 Bug 修復、熱修復、新功能開發等都在單獨的分支中進行。不管是一行代碼的小改動，還是需要幾個星期開發的新功能，都采用同樣的方式來管理。
當需要修改時，從 master 分支創建一個新的分支，所有相關的代碼修改都在新分支中進行。開發人員可以自由地提交代碼和提交到遠程倉庫。
當新分支中的代碼全部完成之后，通過 GitHub 提交一個新的 pull request。團隊中的其他人員會對代碼進行審查，提出相關的修改意見。由持續集成服務器（如 Jenkins）對新分支進行自動化測試。當代碼通過自動化測試和代碼審查之后，該分支的代碼被合并到 master 分支。再從 master 分支部署到生產環境。
GitHub Flow 的好處在于非常簡單實用，開發人員需要注意的事項非常少，很容易形成習慣。當需要修改時，只要從 master 分支創建新分支，完成之后通過 pull request 和相關的代碼審查，合并回 master 分支就可以了。
Gitlab flow
上面提到的 GitHub Flow，適用于特性分支合入 master 后就能馬上部署到線上的這類項目，但并不是所有團隊都使用 GitHub 或使用 pull request 功能，而是使用開源平臺 GitLab，特別是對于公司級別而言，代碼作為資產，不會隨意維護在較公開的 GitHub 上（除非采用企業版）。
GitLab Flow 針對不同的發布場景，在 GitHub Flow（特性分支加 master 分支）的基礎上做了改良，額外衍生出了三個子類模型，如表 2 所示。
GitLab Flow 的特性分支合入 master 用的是“Merge Request”，功能與 GitHub Flow 的“pull request”相同，這里不再贅述。
通過 Git Flow、GitHub Flow 和 GitLab Flow（3 個衍生類別） 這幾個具體模型的介紹，我給你總結一下特性分支開發的優缺點。如表 3 所示。
選出最合適的分支策略
上面我跟你講到的分支模型，都是 IT 研發領域比較流行的。雖然有些策略帶上了代碼平臺的標識，如 GitHub Flow，但并不意味著該策略僅限于 GitHub 代碼平臺使用，你完全可以在自己搭建的代碼平臺上使用這些策略。
接下來，我就總體歸納一下什么情況下應該選擇什么樣的分支策略。如表 4 所示。
SwiftLint 使用
熱烈慶祝 SwiftLint 加入 lint-staged 豪華午餐 ?? ?? ??
（之后對項目 swift 整理治理后，會考慮集成到編譯腳本中，每次build都會lint檢測）
簡單說一下需要注意的問題。
首先 SwiftLint 使用 lint-staged 集成，對開發人員基本無感知，在代碼提交時會進行 lint操作，并同時進行檢測。
lint 成功
如果你的代碼符合 lint 規則。
恭喜，你的提交會正常進入git commit log。
lint 失敗
你會看到如下提示
husky > pre-commit (node v8.9.1)
↓ Stashing changes... [skipped]
→ No partially staged files found...
? Running linters...
↓ Running tasks for *.{png,jpeg,jpg,gif,svg} [skipped]
→ No staged files match *.{png,jpeg,jpg,gif,svg}
? Running tasks for *.swift
? Pods/SwiftLint/swiftlint lint
? Pods/SwiftLint/swiftlint lint found some errors. Please fix them and try committing again.
?? Line 27: Line should be 120 characters or less: currently 218 characters
?? Line 40: Line should be 120 characters or less: currently 128 characters
?? Line 36: Line should be 120 characters or less: currently 194 characters
...
Linting Swift files at paths /Users/chaoyang/Dev/YCMath_New_iOS/b.swift
Linting 'b.swift' (1/1)
Done linting! Found 9 violations, 2 serious in 1 file.
husky > pre-commit hook failed (add --no-verify to bypass)
如何解讀錯誤？
?? Line 27: Line should be 120 characters or less: currently 218 characters
此處是一處錯誤(error)，在 b.swift 文件中27行,該行長度超出約定，應該控制在 120 字符以內，現在是 218個，嚴重超標，請立即進行修改。
?? Line 40: Line should be 120 characters or less: currently 128 characters
此處是一處警告(warning)，在 b.swift 文件中40行開始。該行長度超出約定，應該控制在 120 字符以內，現在是 128個，請注意。
修復
根據命令行提示修復結束后，需要通過 git add 添加你修改好的文件（沒有特殊要求 git add .即可）。
add 結束后，通過 git commit 進行提交即可通過。
更多教程可點擊SwiftLint 中文說明的規則部分查看。
feat 分支開發及合并流程【初稿】
note
下文可能會涉及到 git rebase 的使用，在不熟悉的情況下請遵守以下黃金法則。
1. develop、master、hotfix等多人共用分支請勿直接提交任何 commit，只用于日常的代碼拉取和合并。
2. 如果某次操作間隔中發生1的情況，請勿使用 rebase 合并線上代碼到本地。
3. rebase 僅限于 1、2、條件滿足時的遠程代碼同步，例如：git rebase origin/develop(分支名)
- 抓取線上代碼到本地鏡像
這里需要注意，在代碼合并前推薦對遠程倉庫鏡像進行抓取，方便后續在合并時根據情況自由的選擇合并的方式，選擇不同的方式合并，產生的 git log 和分支合并痕跡也是不同的。
$ git fetch origin develop # 抓取主機名為 origin 下的遠程倉庫的 develop
# 其中 origin 和 develop 為可選參數，用于更精確的數據抓取, zsh 可配置縮寫為 gfod
- 合并鏡像分支到本地
a. 這里本地分支主要指純潔的沒有本地提交過的公共分支(master、develop、hotfix等)，及其他私有分支(feat/xxx，fix/xxx)。
# 公共分支更新
$ git checkout develop # zsh 縮寫為 gco develop
$ git rebase origin/develop # rebase 合并鏡像分支 origin/develop 到本地 develop , zsh 為 grb origin/develop
# 私有分支更新
$ git checkout feat/xxxx
$ git rebase origin/develop
b. 如果 a 中公共分支不純潔，則采用 git merge 進行分支合并
$ git checkout develop
$ git merge origin/develop # 使用 merge 合并
- feat、fix 分支創建及開發
# 基于當前的分支創建私有分支
$ git checkout develop
$ git checkout -b feat/xxxx
開發
這里需要注意規范 commit message 的信息，可使用 git cz 進行控制，后續會講到用法
$ git add .
$ git cz # 根據提示輸入選項
- 私有分支合并主干分支
a. 使用 gitlab 進行 merge request 申請，并勾選 squash commit。
git 提交的一些陋習及解決方案
to be continue...
