牛逼！簡單的代碼提交能玩出這么多花樣

作者：佚名 2021-03-26 10:48:14

這篇文章帶領(lǐng)大家熟悉一下常用的代碼提交方式，大家可以根據(jù)自己所在公司的開發(fā)模式對號入座。

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

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

集中式工作流

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

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

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

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

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

集中式代碼提交流程

小結(jié)：這種模式不推薦大家使用，因為完全沒有發(fā)揮出 Git 的作用，類似于用倚天劍屠龍刀來切菜，太浪費了。

功能分支工作流

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

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

功能分支工作流

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

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

代碼提交流程

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

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

Gitflow 工作流

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

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

Gitflow 常見分支：

開發(fā)主分支：master 分支

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

開發(fā)主分支：develop分支

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

臨時分支：feature 分支

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

臨時分支：release 分支

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

臨時分支：hotfix 分支

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

各分支如何配合工作？

（1）master/develop分支

原則上master分支上所有的commit 都應(yīng)該打上Tag，因為一般情況下master不存在直接commit；

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

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

主分支工作流程

（2）feature 分支

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