簡介個人-Git-Work-Flow

重要性

咱們從重要性提及。

團隊開發中要重視有潔癖的人，這種人每每對糟糕的工做流不斷提出意見、對 Git 的使用方式提出要求。若是你的團隊中這種人正在不斷的被忽視，那麼你的團隊必定出現了管理混亂、代碼質量不高等等等等問題。

統一的工做流程是相當重要的，無論對於哪個行業的做業來講都同樣。對於咱們開發人員，工做流包含了開發時 Git 的使用規範、Repo 管理的規範、測試過程的規範、設計交互的管理規範等等。因爲測試、交互等設計到更多的人員，本篇文章暫且不表，重點說 Git 的使用規範和 repo 管理的規範。

本篇文章將講述我在工做中一直使用的 Work Flow，但願對你們有幫助。

常見 Git 使用規範

先舉一個例子，放上幾張 Network 的圖形截圖。爲了你的工程不變成下面這個樣子，請善待 Git 的使用：

這樣一個亂糟糟的 Git，大家能忍我不能忍。

先來講說幾張圖種的問題：

1. 反向拉取 develop 分支
2. 不通過 Pull Request 的合併
3. 重複使用已經合併的分支
4. 沒有意義的 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 開發流。這裏是經典文章。

大體的意思爲：

1. master 是長期分支，通常用於管理對外發布版本，每一個 commit 對一個 tag，也就是一個發佈版本
2. develop 是長期分支，通常用於做爲平常開發彙總，即開發版的代碼
3. feature 是短時間分支，通常用於一個新功能的開發
4. hotfix 是短時間分支 ，通常用於正式發佈之後，出現 bug，須要建立一個分支，進行 bug 修補。
5. release 是短時間分支，通常用於發佈正式版本以前（即合併到 master 分支以前），須要有的預發佈的版本進行測試。release 分支在經歷測試以後，測試確認驗收，將會被合併的 develop 和 master

具體的也能夠參考 Git 工做流程。

Github Flow

在開發中 Git 每每搭配持續交付平臺，Github 也好，GitLab 也好，都提供了完備的持續交付管理功能。配合這些就有了 Github Flow

大體意思爲：

1. master 開出新分支，不區分功能分支或補丁分支。
2. 新分支開發完成後，或者須要討論的時候，就向 master 發起一個 Pull Request。
3. 項目內人一塊兒評審和討論你的代碼。對話過程當中，你還能夠不斷提交代碼。
4. Pull Request 經過，合併進 master，原分支就被刪除。

能夠看出 Github Flow 是 Git Flow 的簡化版本，可是加上了一些合做關節的把控。

個人 Git Work Flow

我一般但願團隊中的開發流程相似 Git Flow，但更爲詳細，大體爲：

1、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 修補

2、Git 操做部分

commit 規範

1. commit message 言簡意賅，不要寫無用信息。不要出現 『update』，『Bug Fix』，這樣讓別人不能領其意的描述
2. 添加一個新的 Pod 庫或 pod update 後，單獨提交一個 commit，統一 commit message 爲『pod add xxx』或 『pod update』
3. commit 之間保持獨立，不要有修改同一個文件的狀況。好比一個 Pull Request 中 commit1 在 FileA 中改了一個變量名， commit2 改回了變量名。緣由是：審覈代碼時，審覈人一般會逐個 commit查看，而不是直接看 Changes（能夠直接忽略掉 pod update 這樣的 commit 不看）

rebase

不要出現反向拉取代碼的狀況，即文章開頭第一張、第二張圖片中的狀況——看到 develop 有更新，就將 develop 的代碼拉取 merge 進本身的分支。

緣由是：

1. merge 會致使你的分支都會引入一個外來的合併提交。若是 develop 很是活躍的話，或多或少會污染你的分支。
2. 醜，Network 複雜，增長理解項目歷史的難度。

如何解決當前 develop 有更新的狀況？

請使用 rebase！

rebase 用中文直譯就是 變基。上張圖幫助你們理解：

rebase 在進行時，須要選擇一個 commit 點，將當前分支從根基整個移到指定 commit 點，名副其實——變基。

這樣你既能夠獲得一個好看的 Network，又能夠及時控制衝突。不過在多人開發中你須要多多關注 develop 的狀況，及時 rebase，避免長時間不更新代碼忽然 rebase 到最新後發現了大量衝突。固然，控制和分配比較好的項目自己也不多產生衝突。

3、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 審覈人應當檢查的內容不是硬性的，但至少應當包括：

1. 代碼規範
2. 基本語法和基本邏輯錯誤
3. 業務邏輯的一些經驗
4. ...

在發現錯誤時，應當及時的添加 comment。

當審覈人所有審覈完畢，添加完全部的 comment 以後須要在 Discussion 區域 @提交人 review done，通知提交人。

一樣，提交人在按照 comment 修改完後，也應當在 Discussion 區域 @相關審覈人 修改完成，請從新審覈。

須要着重說明的是：提交人的全部修改，不容許新提交 commit，應當在本地修改完成後，ammend 追加到最後 commit。

可是這一點，只是我一直使用的方式，緣由一樣是遵循『commit 之間保持獨立』，若是提交新的 commit 致使兩個 commit 修改了同一個文件。

固然也有人認爲新加 commit 能夠更清晰的看到提交者的新變更，也更符合 Github Flow。關於這裏，就沒有什麼強制了，更喜歡什麼就什麼。

總結

最後，但願你們都收穫一個清爽如風的 Network。

---

有什麼問題均可以在博文後面留言，或者微博上私信我，或者郵件我 coderfish@163.com。

博主是 iOS 妹子一枚。

但願你們一塊兒進步。

個人微博：小魚周凌宇