快來看！簡單的代碼提交能玩出這么多花樣
本文轉載自微信公眾號「愛笑的架構師」，作者雷架。轉載本文請聯系愛笑的架構師公眾號。
作為一個開發人員每天必不可少要提交代碼，但是你真的懂代碼提交嗎?這篇文章帶領大家熟悉一下常用的代碼提交方式，大家可以根據自己所在公司的開發模式對號入座。
代碼提交方式可以用一個專業術語描述：代碼工作流，在 SVN 時代大家會使用集中式工作流，所有人都往一個主庫分支合入代碼;隨著技術的演進，以 Git 為代表的分布式代碼管理工具橫空出世，在 Git 的基礎上又逐漸出現了多種代碼管理工作流：功能分支工作流，Gitflow 工作流，Forking 工作流。搬好小板凳，下面一一位大家講解。
集中式工作流
集中式工作流這種工作方式對于使用過SVN的同學想必會非常的熟悉，讓我們思考下在 SVN下的協作體驗，不同的開發同學需要依次將本地的修改提交到服務器，如果有沖突就先解決本地的沖突再提交，這個過程中遠端的服務器就像是一個集中管理者，管理著所有人的代碼提交，所以 SVN的開發協作流程就是典型的集中式工作流。
如果切換到 Git 來維護代碼倉，但是開發人員又對 Git 的分支模式不熟悉，能不能用 Git 實現類似的集中式工作流呢?答案是當然可以。
每個開發人員將遠程倉庫的代碼 clone 下來變成了屬于自己的本地倉庫，提交代碼時先提交至本地倉庫，然后再推送到遠程倉庫。
這種模式相比 SVN 只是多了一個本地倉庫而已，有了 SVN 的經驗開發人員也很快能熟悉這種模式，在前些年有很多公司都是將 Git 作為 SVN 來用的。
從提交記錄來看，集中式工作流通常是一條直線往前走，如下圖：
集中式代碼提交流程
小結：這種模式不推薦大家使用，因為完全沒有發揮出 Git 的作用，類似于用倚天劍屠龍刀來切菜，太浪費了。
功能分支工作流
集中式工作流有一個很大的問題，隨著團隊內人員不斷增多，大家每一次提交代碼都可能會遇到沖突，提交代碼一分鐘解決沖突一小時。
為了便于大家并發開展工作，通常會基于 master 主干分支拉取幾個特性分支，每個開發人員關注于自己的分支，需要提交代碼時直接提交到本地庫的特性分支，在合入到主干分支前通常會拉取最新的代碼，如果有沖突先在本地解決好沖突，解決完提交 MR 申請將特性分支合入主干分支。
功能分支工作流
在功能分支工作流下，不會直接將代碼合入到主干分支(master)，通常是通過其他分支提交 MR(Merge Request)，這使得集成一些自動化操作變得簡單可行了。
提交 MR 之后團隊成員開始圍觀你寫的代碼，可以提交檢視意見(code review)，還可以進行投票(vote)，團隊 committer 據此合入或者駁回你的 MR。
代碼提交流程
新功能大量合并到 master 分支后容易造成 master 分支質量不穩定，不穩定會有什么問題?比如線上突然有個 bug 要解決，可能只需要修改一行代碼就能解決，但是 master 分支已經合入了大量新特性，測試人員還沒來得及測試，那最穩妥的辦法就是將代碼回退到上一次發版本的時間節點，基于這個節點再修改一行代碼，是不是太麻煩了?
為了解決這些問題，Vincent Driessen大佬基于開發實踐總結了一套 Git 分支管理的流程和規范，下面詳細介紹一下。
Gitflow 工作流
Gitflow 工作流是目前非常成熟的一個方案，它定義了一個圍繞項目發布的嚴格分支模型，通過為代碼研發、項目發布以及維護分配獨立的分支來讓項目的迭代過程更加地順暢，不同于之前的集中式工作流以及功能分支工作流，Gitflow 工作流常駐的分支有兩個：主干分支 master、開發分支 develop。
和功能分支工作流相比，Gitflow工作流沒有增加任何新的概念或命令，它給不同的分支指定了特定的角色，定義它們應該如何、什么時候交互。除了功能分支之外，還為準備發布、維護發布、記錄發布分別使用了單獨的分支。
Gitflow 常見分支：
- 開發主分支：master 分支
master 分支的代碼是可以直接部署到生成環境的，為了保持穩定性一般不會直接在這個分支上修改代碼，都是通過其他分支合并過來的。
- 開發主分支：develop分支
develop 分支是主開發分支，包含所有要發布到下一個release的代碼，主要是由feature分支合并過來的。
- 臨時分支：feature 分支
feature 分支主要是用來開發一個新特性，一旦開發完成會合入 develop 分支，feature 分支也隨即刪除掉。
- 臨時分支：release 分支
當需要一個發布一個新release版本時，會基于develop分支創建一個release分支，經過測試人員充分測試后再合入 master 分支和 develop 分支。
- 臨時分支：hotfix 分支
當在生成環境發現新的Bug時候，如果需要緊急修復，會創建一個hotfix分支， 充分測試后合入master和develop分支，隨后刪除該分支。
各分支如何配合工作?
(1)master/develop分支
原則上master分支上所有的commit 都應該打上Tag，因為一般情況下master不存在 直接commit;
devlop分支 是基于 master分支創建的，與 master 分支一樣都是主分支，不會被刪除。
develop 從 master 拉出來之后會獨立發展，不會與 master 直接產生聯系。
主分支工作流程
(2)feature 分支
通常一個獨立的特性都會基于 develop 拉出一個 feature 分支，feature 分支之間沒有任何交互，互不影響。feature 分支一旦開發完成后會立馬合入 develop 分支(采用 merge request 或者 pull request)，feature 分支的生命周期也隨之結束。
feature 分支工作流程
(3)release 分支
通常一個迭代上線會拉一個release 分支，開發人員開發完畢所有的代碼都已合入 develop 分支，這時候會基于 develop 分支拉出一個 release 分支，測試人員基于該分支進行測試。
release 分支工作流程
(4)hotfix 分支
hotfix分支基于master分支創建，開發完后需要同時回合到master和develop分支，同時在master上打一個tag。
hotfix 分支工作流程
分支命名規范
團隊內部可以約定每個分支的命名樣式，這里舉個例子，大家可以參考：
- feature分支：以feature_開頭，如 feature_order
- release分支：以release_開頭，如 release_v1.0
- hotfix分支：以hotfix_開頭，如hotfix_20210117
- tag標記：如果是release分支合并，則以release_開頭，如果是hotfix分支合并，則以hotfix_開頭。
Forking 工作流
Forking 工作流是以 Github 為代表的一種代碼協作方式，開發者通過克隆(fork)源倉庫進行編寫代碼，一旦完成會發起 pull request，源倉庫作者可以選擇是否接受該 PR。
下面通過 Github 詳細講解 Forking 工作流模式。
隨便找一個Github 開源項目，
https://github.com/smileArchitect/JavaMap
右上角有三個按鈕：Watch，Star，Fork
Watch 是關注的意思，一旦你點擊了之后該項目有任何改動都會第一時間通知到你;
Star 類似于點贊的意思，多給開源項目點個贊，鼓勵一下作者;
Fork 本意是分叉，實際上是克隆的意思，點了之后會將該項目拷貝一份到自己的 github 遠程倉庫中。
fork 示例
在本地執行 git clone 命令將代碼克隆到本地，一頓修改操作后提交代碼并 push到個人遠程倉庫中，然后在界面上發起 pull request，項目的原作者會看到你提交的 PR，根據提交的質量作者可以選擇接受或拒絕。
Github 工作流程
Forking 工作流非常適合于類似 Github 這種開源項目，任何一個開發者都可以通過fork + pull request 向項目中貢獻代碼。
總結
文章介紹了四種工作流，分別是集中式工作流，功能分支工作流，Gitflow 工作流，Forking 工作流。
集中式工作流在 SVN 時代比較常見，切到 Git 后不建議再使用這種方式了。
功能分支工作流通常是一個主干 master 分支 + 多個 feature 分支，一般適用于小團隊開發。
Gitflow 工作流是在功能分支工作流的基礎上進一步演進而來，采用 master + develop 雙主分支再加上多個臨時功能分支，這是一個非常成熟的代碼協作管理的方式，推薦大家使用。
Forking 工作流主要采取 fork + pull request 的模式進行協作，主要用于開源項目。
最后：這四種工作流方式各有特色，開發團隊可根據自身的特點去選擇，不必嚴格拘泥于某一種方式，適合自己的才是最優的。大家學會了嗎?
