重要性
我們從重要性說起。
團隊開發中要重視有潔癖的人，這種人往往對糟糕的工作流不斷提出意見、對 Git 的使用方式提出要求。如果你的團隊中這種人正在不斷的被忽視，那麼你的團隊一定出現了管理混亂、程式碼質量不高等等等等問題。
統一的工作流程是至關重要的，不管對於哪一個行業的作業來說都一樣。對於我們開發人員，工作流包含了開發時 Git 的使用規範、Repo 管理的規範、測試過程的規範、設計互動的管理規範等等。由於測試、互動等設計到更多的人員，本篇文章暫且不表，重點說 Git 的使用規範和 repo 管理的規範。
本篇文章將講述我在工作中一直使用的 Work Flow，希望對大家有幫助。
常見 Git 使用規範
先舉一個例子，放上幾張 Network 的圖形截圖。為了你的工程不變成下面這個樣子，請善待 Git 的使用：
這樣一個亂糟糟的 Git，你們能忍我不能忍。
先來說說幾張圖種的問題：
- 反向拉取
develop分支 - 不經過
Pull Request的合併 - 重複使用已經合併的分支
- 沒有意義的
Commit Message
對於問題 1，敢問這位同學，能不能用 rebase？很多同學在開發分支過程中，發現 develop 有更新，就去拉取 develop 的內容 Merge 進自己當前分支。對於 rebase 和 merge，請參考 這篇文章 。引用裡面的話：
每次合併上游更改時
feature分支都會引入一個外來的合併提交。如果develop非常活躍的話，這或多或少會汙染你的分支歷史。雖然高階的git log選項可以減輕這個問題，但對於開發者來說，還是會增加理解專案歷史的難度。
對於問題 2，完全就是習慣問題，對於所有的合併，如果是你自己的兩個分支之間，如果非要直接 Merge 也不是不可，但是如果是兩個人分別開發的分支，直接的 Merge 是不負責任的。Pull Request 或者 Merge Request 可以更早的幫你發現合併衝突，並且強制你 review 程式碼，這在保證程式碼質量方面起著至關重要的作用。
對於問題 3，已經合併入 develop 分支的分支，最好在 Pull Request 合併時直接勾選移除原分支，更容易保持和 develop 的同步。
對於問題 4，是最最最常見的問題，看看自己的專案，裡面有多少個連續的 Commit Message 是『bug fix』、『update』、『pod add』、『修復』等等這樣完全看不出啥內容的描述。敢問這樣寫的同學，你們的專案 Owner 看到 Network 時候是不是心裡充滿了 WTF？Commit Message 應當簡短幹練的描述這個 commit 做了什麼。
下面再看一個正面的示例，無比清爽的 Network：
關於我的 Work Flow，我們從基本的 Git 開發流接著介紹。
Git Flow
廣為人知的 Git Flow 定義了一套標準的 Git 開發流。這裡是經典文章。
大致的意思為：
master是長期分支，一般用於管理對外發布版本，每個 commit 對一個 tag，也就是一個釋出版本develop是長期分支，一般用於作為日常開發彙總，即開發版的程式碼feature是短期分支，一般用於一個新功能的開發hotfix是短期分支 ，一般用於正式釋出以後，出現 bug，需要建立一個分支，進行 bug 修補。release是短期分支，一般用於釋出正式版本之前（即合併到master分支之前），需要有的預釋出的版本進行測試。release分支在經歷測試之後，測試確認驗收，將會被合併的develop和master
具體的也可以參考 Git 工作流程。
Github Flow
在開發中 Git 往往搭配持續交付平臺，Github 也好，GitLab 也好，都提供了完備的持續交付管理功能。配合這些就有了 Github Flow
大致意思為：
master開出新分支，不區分功能分支或補丁分支。- 新分支開發完成後，或者需要討論的時候，就向
master發起一個Pull Request。 - 專案內人一起評審和討論你的程式碼。對話過程中，你還可以不斷提交程式碼。
Pull Request通過，合併進master，原分支就被刪除。
可以看出 Github Flow 是 Git Flow 的簡化版本，但是加上了一些合作關節的把控。
我的 Git Work Flow
我通常希望團隊中的開發流程類似 Git Flow，但更為詳細，大致為：
一、Git 分支部分
master
長期分支，每個 commit 對一個 tag（一個釋出版本）
develop
長期分支，日常開發彙總（開發版的程式碼）。
開發一個新的 feature 直接新在 develop 新開一個臨時的 feature 分支，開發完成向 develop 提 Pull Request``Pull Request。
release
短期分支，feature 開發完成後從 develop 拉出的分支，用於測試階段，期間新增的 commit 基本都是 bug fix，開發結束後同時和並進 develop 和 master，master 打上釋出 tag。
hotfix
短期分支，正式釋出以後，進行 bug 修補
二、Git 操作部分
commit 規範
commit message言簡意賅，不要寫無用資訊。不要出現 『update』，『Bug Fix』，這樣讓別人不能領其意的描述- 新增一個新的
Pod庫或pod update後，單獨提交一個commit，統一commit message為『pod add xxx』或 『pod update』 commit之間保持獨立，不要有修改同一個檔案的情況。比如一個Pull Request中 commit1 在 FileA 中改了一個變數名， commit2 改回了變數名。原因是：稽核程式碼時，稽核人通常會逐個commit檢視，而不是直接看Changes（可以直接忽略掉 pod update 這樣的commit不看）
rebase
不要出現反向拉取程式碼的情況，即文章開頭第一張、第二張圖片中的情況——看到 develop 有更新，就將 develop 的程式碼拉取 merge 進自己的分支。
原因是：
merge會導致你的分支都會引入一個外來的合併提交。如果develop非常活躍的話，或多或少會汙染你的分支。- 醜，Network 複雜，增加理解專案歷史的難度。
如何解決當前 develop 有更新的情況？
請使用 rebase！
rebase 用中文直譯就是 變基。上張圖幫助大家理解：
rebase 在進行時，需要選擇一個 commit 點，將當前分支從根基整個移到指定 commit 點，名副其實——變基。
這樣你既可以得到一個好看的 Network，又可以及時控制衝突。不過在多人開發中你需要多多關注 develop 的情況，及時 rebase，避免長時間不更新程式碼突然 rebase 到最新後發現了大量衝突。當然，控制和分配比較好的專案本身也很少產生衝突。
三、GitLab 管理規範
issue
日常 Github 玩的轉的同學都知道 issue 可以做很多事，比如：意見管理、Bug 管理、任務管理，可以只做一種功能，也能通過不同的 Label 同時使用所有的功能。
我的 Work Flow 中，issue 用來做任務管理，因為 issue 可以方便的指派，及時收到郵件通知。
每次新版本迭代開始，PRD 稽核通過時，組內協商好任務分配後將任務拆成最小單元，由 Owner 分別建立 issue，大家自行領取。
如果有開發過程中發現的需要改進的地方，同樣可以建立 issue。
關於 Label，我通常會分為：optimizing、bug fix、feature
一個任務完成時，通常會提 Pull Request，如果該 Pull Request 中完成了所有的任務，Pull Request 的 Title 應當類似以下格式：
『close #13 首頁滾動欄切換效果完善』
GitLab 和 Github 都能識別 close #{issue id}，如果在 Title 中這樣寫，在 Pull Request 通過稽核時，相應的 issue 會自動被關閉。
Milestones
Milestones 即里程碑，issue 在建立的時候可以選擇 Milestones，如果合理的使用了 Milestones，在 Milestones 頁面，就可以得到一個清晰的專案進度。
Pull Request
所有的合併都需要提 Pull Request，包括自己的分支合併到自己的分支，可以更好的幫助大家養成 Code Review 的好習慣。
Pull Request 的標題應該簡介的介紹該次合併所做的事。更詳細的內容應當在 Description 中逐條列出。如有相關文件連結也應列出。
注意選擇合適的 Milestone 和 Labels。選擇一位 Assignee 來稽核，如果覺得該 Pull Request 內容過多，或有需要大家共同討論的地方，再 Pull Request 提交後，在 Discussion 區域 @ 其他人，所有人都會及時收到郵件。
Code Review
Code Review 是一個很值得說的點。很多時候大家會以為 Code Review 是一定要讀懂別人的程式碼，然後進行分析、稽核。其實 Code Review 更多的是扮演了團隊內經驗傳遞的作用。
舉個例子，程式碼規範這樣的東西，就算是一個團隊有了很詳細的文件，但大家也不一定會去完整記下。對於新人，完成了 feature 後提 Pull Request，交由其他人 Code Review 時，由其他人稽核程式碼規範，不合規要求繼續修正，來回四五次，就再基本不會有問題了。
這也是我的親身經歷，我之前的一位 leader 對於 Work Flow 管理非常有經驗，我在最初時提了幾次 Pull Request，很快就熟悉了團隊內的程式碼規範。
所以 Code Review 稽核人應當檢查的內容不是硬性的，但至少應當包括：
- 程式碼規範
- 基本語法和基本邏輯錯誤
- 業務邏輯的一些經驗
- ...
在發現錯誤時，應當及時的新增 comment。
當稽核人全部稽核完畢，新增完所有的 comment 之後需要在 Discussion 區域 @提交人 review done，通知提交人。
同樣，提交人在按照 comment 修改完後，也應當在 Discussion 區域 @相關稽核人 修改完成，請重新稽核。
需要著重說明的是：提交人的所有修改，不允許新提交 commit，應當在本地修改完成後，ammend 追加到最後 commit。
但是這一點，只是我一直使用的方式，原因同樣是遵循『commit 之間保持獨立』，如果提交新的 commit 導致兩個 commit 修改了同一個檔案。
當然也有人認為新加 commit 可以更清晰的看到提交者的新變動，也更符合 Github Flow。關於這裡，就沒有什麼強制了，更喜歡什麼就什麼。
總結
最後，希望大家都收穫一個清爽如風的 Network。
有什麼問題都可以在博文後面留言，或者微博上私信我，或者郵件我 coderfish@163.com。
博主是 iOS 妹子一枚。
希望大家一起進步。
我的微博：小魚周凌宇
如有任何智慧財產權、版權問題或理論錯誤，還請指正。
轉載請註明原作者及以上資訊。