[[376820]]

本文轉(zhuǎn)載自微信公眾號(hào)「愛(ài)笑的架構(gòu)師」，作者雷架。轉(zhuǎn)載本文請(qǐng)聯(lián)系愛(ài)笑的架構(gòu)師公眾號(hào)。

作為一個(gè)開(kāi)發(fā)人員每天必不可少要提交代碼，但是你真的懂代碼提交嗎?這篇文章帶領(lǐng)大家熟悉一下常用的代碼提交方式，大家可以根據(jù)自己所在公司的開(kāi)發(fā)模式對(duì)號(hào)入座。

代碼提交方式可以用一個(gè)專業(yè)術(shù)語(yǔ)描述：代碼工作流，在 SVN 時(shí)代大家會(huì)使用集中式工作流，所有人都往一個(gè)主庫(kù)分支合入代碼;隨著技術(shù)的演進(jìn)，以 Git 為代表的分布式代碼管理工具橫空出世，在 Git 的基礎(chǔ)上又逐漸出現(xiàn)了多種代碼管理工作流：功能分支工作流，Gitflow 工作流，F(xiàn)orking 工作流。搬好小板凳，下面一一位大家講解。

集中式工作流

集中式工作流這種工作方式對(duì)于使用過(guò)SVN的同學(xué)想必會(huì)非常的熟悉，讓我們思考下在 SVN下的協(xié)作體驗(yàn)，不同的開(kāi)發(fā)同學(xué)需要依次將本地的修改提交到服務(wù)器，如果有沖突就先解決本地的沖突再提交，這個(gè)過(guò)程中遠(yuǎn)端的服務(wù)器就像是一個(gè)集中管理者，管理著所有人的代碼提交，所以 SVN的開(kāi)發(fā)協(xié)作流程就是典型的集中式工作流。

如果切換到 Git 來(lái)維護(hù)代碼倉(cāng)，但是開(kāi)發(fā)人員又對(duì) Git 的分支模式不熟悉，能不能用 Git 實(shí)現(xiàn)類似的集中式工作流呢?答案是當(dāng)然可以。

每個(gè)開(kāi)發(fā)人員將遠(yuǎn)程倉(cāng)庫(kù)的代碼 clone 下來(lái)變成了屬于自己的本地倉(cāng)庫(kù)，提交代碼時(shí)先提交至本地倉(cāng)庫(kù)，然后再推送到遠(yuǎn)程倉(cāng)庫(kù)。

這種模式相比 SVN 只是多了一個(gè)本地倉(cāng)庫(kù)而已，有了 SVN 的經(jīng)驗(yàn)開(kāi)發(fā)人員也很快能熟悉這種模式，在前些年有很多公司都是將 Git 作為 SVN 來(lái)用的。

從提交記錄來(lái)看，集中式工作流通常是一條直線往前走，如下圖：

集中式代碼提交流程

小結(jié)：這種模式不推薦大家使用，因?yàn)橥耆珱](méi)有發(fā)揮出 Git 的作用，類似于用倚天劍屠龍刀來(lái)切菜，太浪費(fèi)了。

功能分支工作流

集中式工作流有一個(gè)很大的問(wèn)題，隨著團(tuán)隊(duì)內(nèi)人員不斷增多，大家每一次提交代碼都可能會(huì)遇到?jīng)_突，提交代碼一分鐘解決沖突一小時(shí)。

為了便于大家并發(fā)開(kāi)展工作，通常會(huì)基于 master 主干分支拉取幾個(gè)特性分支，每個(gè)開(kāi)發(fā)人員關(guān)注于自己的分支，需要提交代碼時(shí)直接提交到本地庫(kù)的特性分支，在合入到主干分支前通常會(huì)拉取最新的代碼，如果有沖突先在本地解決好沖突，解決完提交 MR 申請(qǐng)將特性分支合入主干分支。

功能分支工作流

在功能分支工作流下，不會(huì)直接將代碼合入到主干分支(master)，通常是通過(guò)其他分支提交 MR(Merge Request)，這使得集成一些自動(dòng)化操作變得簡(jiǎn)單可行了。

提交 MR 之后團(tuán)隊(duì)成員開(kāi)始圍觀你寫的代碼，可以提交檢視意見(jiàn)(code review)，還可以進(jìn)行投票(vote)，團(tuán)隊(duì) committer 據(jù)此合入或者駁回你的 MR。

代碼提交流程

新功能大量合并到 master 分支后容易造成 master 分支質(zhì)量不穩(wěn)定，不穩(wěn)定會(huì)有什么問(wèn)題?比如線上突然有個(gè) bug 要解決，可能只需要修改一行代碼就能解決，但是 master 分支已經(jīng)合入了大量新特性，測(cè)試人員還沒(méi)來(lái)得及測(cè)試，那最穩(wěn)妥的辦法就是將代碼回退到上一次發(fā)版本的時(shí)間節(jié)點(diǎn)，基于這個(gè)節(jié)點(diǎn)再修改一行代碼，是不是太麻煩了?

為了解決這些問(wèn)題，Vincent Driessen大佬基于開(kāi)發(fā)實(shí)踐總結(jié)了一套 Git 分支管理的流程和規(guī)范，下面詳細(xì)介紹一下。

Gitflow 工作流

Gitflow 工作流是目前非常成熟的一個(gè)方案，它定義了一個(gè)圍繞項(xiàng)目發(fā)布的嚴(yán)格分支模型，通過(guò)為代碼研發(fā)、項(xiàng)目發(fā)布以及維護(hù)分配獨(dú)立的分支來(lái)讓項(xiàng)目的迭代過(guò)程更加地順暢，不同于之前的集中式工作流以及功能分支工作流，Gitflow 工作流常駐的分支有兩個(gè)：主干分支 master、開(kāi)發(fā)分支 develop。

和功能分支工作流相比，Gitflow工作流沒(méi)有增加任何新的概念或命令，它給不同的分支指定了特定的角色，定義它們應(yīng)該如何、什么時(shí)候交互。除了功能分支之外，還為準(zhǔn)備發(fā)布、維護(hù)發(fā)布、記錄發(fā)布分別使用了單獨(dú)的分支。

Gitflow 常見(jiàn)分支：

• 開(kāi)發(fā)主分支：master 分支

master 分支的代碼是可以直接部署到生成環(huán)境的，為了保持穩(wěn)定性一般不會(huì)直接在這個(gè)分支上修改代碼，都是通過(guò)其他分支合并過(guò)來(lái)的。

• 開(kāi)發(fā)主分支：develop分支

develop 分支是主開(kāi)發(fā)分支，包含所有要發(fā)布到下一個(gè)release的代碼，主要是由feature分支合并過(guò)來(lái)的。

• 臨時(shí)分支：feature 分支

feature 分支主要是用來(lái)開(kāi)發(fā)一個(gè)新特性，一旦開(kāi)發(fā)完成會(huì)合入 develop 分支，feature 分支也隨即刪除掉。

• 臨時(shí)分支：release 分支

當(dāng)需要一個(gè)發(fā)布一個(gè)新release版本時(shí)，會(huì)基于develop分支創(chuàng)建一個(gè)release分支，經(jīng)過(guò)測(cè)試人員充分測(cè)試后再合入 master 分支和 develop 分支。

• 臨時(shí)分支：hotfix 分支

當(dāng)在生成環(huán)境發(fā)現(xiàn)新的Bug時(shí)候，如果需要緊急修復(fù)，會(huì)創(chuàng)建一個(gè)hotfix分支， 充分測(cè)試后合入master和develop分支，隨后刪除該分支。

各分支如何配合工作?

(1)master/develop分支

原則上master分支上所有的commit 都應(yīng)該打上Tag，因?yàn)橐话闱闆r下master不存在 直接commit;

devlop分支 是基于 master分支創(chuàng)建的，與 master 分支一樣都是主分支，不會(huì)被刪除。

develop 從 master 拉出來(lái)之后會(huì)獨(dú)立發(fā)展，不會(huì)與 master 直接產(chǎn)生聯(lián)系。

主分支工作流程

(2)feature 分支

通常一個(gè)獨(dú)立的特性都會(huì)基于 develop 拉出一個(gè) feature 分支，feature 分支之間沒(méi)有任何交互，互不影響。feature 分支一旦開(kāi)發(fā)完成后會(huì)立馬合入 develop 分支(采用 merge request 或者 pull request)，feature 分支的生命周期也隨之結(jié)束。

feature 分支工作流程

(3)release 分支

通常一個(gè)迭代上線會(huì)拉一個(gè)release 分支，開(kāi)發(fā)人員開(kāi)發(fā)完畢所有的代碼都已合入 develop 分支，這時(shí)候會(huì)基于 develop 分支拉出一個(gè) release 分支，測(cè)試人員基于該分支進(jìn)行測(cè)試。

release 分支工作流程

(4)hotfix 分支

hotfix分支基于master分支創(chuàng)建，開(kāi)發(fā)完后需要同時(shí)回合到master和develop分支，同時(shí)在master上打一個(gè)tag。

hotfix 分支工作流程

分支命名規(guī)范

團(tuán)隊(duì)內(nèi)部可以約定每個(gè)分支的命名樣式，這里舉個(gè)例子，大家可以參考：

1. feature分支：以feature_開(kāi)頭，如 feature_order
2. release分支：以release_開(kāi)頭，如 release_v1.0
3. hotfix分支：以hotfix_開(kāi)頭，如hotfix_20210117
4. tag標(biāo)記：如果是release分支合并，則以release_開(kāi)頭，如果是hotfix分支合并，則以hotfix_開(kāi)頭。

Forking 工作流

Forking 工作流是以 Github 為代表的一種代碼協(xié)作方式，開(kāi)發(fā)者通過(guò)克隆(fork)源倉(cāng)庫(kù)進(jìn)行編寫代碼，一旦完成會(huì)發(fā)起 pull request，源倉(cāng)庫(kù)作者可以選擇是否接受該 PR。

下面通過(guò) Github 詳細(xì)講解 Forking 工作流模式。

隨便找一個(gè)Github 開(kāi)源項(xiàng)目，

https://github.com/smileArchitect/JavaMap

右上角有三個(gè)按鈕：Watch，Star，F(xiàn)ork

Watch 是關(guān)注的意思，一旦你點(diǎn)擊了之后該項(xiàng)目有任何改動(dòng)都會(huì)第一時(shí)間通知到你;

Star 類似于點(diǎn)贊的意思，多給開(kāi)源項(xiàng)目點(diǎn)個(gè)贊，鼓勵(lì)一下作者;

Fork 本意是分叉，實(shí)際上是克隆的意思，點(diǎn)了之后會(huì)將該項(xiàng)目拷貝一份到自己的 github 遠(yuǎn)程倉(cāng)庫(kù)中。

fork 示例

在本地執(zhí)行 git clone 命令將代碼克隆到本地，一頓修改操作后提交代碼并 push到個(gè)人遠(yuǎn)程倉(cāng)庫(kù)中，然后在界面上發(fā)起 pull request，項(xiàng)目的原作者會(huì)看到你提交的 PR，根據(jù)提交的質(zhì)量作者可以選擇接受或拒絕。

Github 工作流程

Forking 工作流非常適合于類似 Github 這種開(kāi)源項(xiàng)目，任何一個(gè)開(kāi)發(fā)者都可以通過(guò)fork + pull request 向項(xiàng)目中貢獻(xiàn)代碼。

總結(jié)

文章介紹了四種工作流，分別是集中式工作流，功能分支工作流，Gitflow 工作流，F(xiàn)orking 工作流。

集中式工作流在 SVN 時(shí)代比較常見(jiàn)，切到 Git 后不建議再使用這種方式了。

功能分支工作流通常是一個(gè)主干 master 分支 + 多個(gè) feature 分支，一般適用于小團(tuán)隊(duì)開(kāi)發(fā)。

Gitflow 工作流是在功能分支工作流的基礎(chǔ)上進(jìn)一步演進(jìn)而來(lái)，采用 master + develop 雙主分支再加上多個(gè)臨時(shí)功能分支，這是一個(gè)非常成熟的代碼協(xié)作管理的方式，推薦大家使用。

Forking 工作流主要采取 fork + pull request 的模式進(jìn)行協(xié)作，主要用于開(kāi)源項(xiàng)目。

最后：這四種工作流方式各有特色，開(kāi)發(fā)團(tuán)隊(duì)可根據(jù)自身的特點(diǎn)去選擇，不必嚴(yán)格拘泥于某一種方式，適合自己的才是最優(yōu)的。大家學(xué)會(huì)了嗎?