快捷導(dǎo)航

Git基礎(chǔ)之git在項(xiàng)目中的協(xié)作模式

更新時(shí)間：2022年04月22日 17:37:17 作者：繁華似錦Fighting

這篇文章主要為大家介紹了Git基礎(chǔ)之git在項(xiàng)目中的協(xié)作模式，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪

1、分布式工作流程

與傳統(tǒng)的集中式版本控制系統(tǒng)（CVCS）相反，Git 的分布式特性，使開發(fā)者間的協(xié)作變得更加靈活多樣。

在集中式版本控制系統(tǒng)中，每個(gè)開發(fā)者就像是連接在集線器上的節(jié)點(diǎn)，彼此的工作方式大體相像。而在 Git 中，每個(gè)開發(fā)者同時(shí)扮演著節(jié)點(diǎn)和集線器的角色。也就是說，每個(gè)開發(fā)者既可以將自己的代碼貢獻(xiàn)到其他的倉庫中，同時(shí)也能維護(hù)自己的公開倉庫，讓其他人可以在其基礎(chǔ)上工作并貢獻(xiàn)代碼。

由此，Git 的分布式協(xié)作可以為你的項(xiàng)目和團(tuán)隊(duì)，衍生出種種不同的工作流程，接下來會(huì)介紹幾種常見Git工作流程。

你可以選擇使用其中的某一種，或者將它們的特性混合搭配使用。

2、集中式工作流

Git為了便于客戶機(jī)之間的協(xié)同工作，Git版本控制系統(tǒng)一般會(huì)設(shè)置一個(gè)中央版本庫服務(wù)器，目的是讓所有客戶機(jī)都從該主機(jī)更新版本，提交最新版本，該工作模式下的客戶機(jī)地位都平等。

集中式工作流像SVN一樣，以中央倉庫作為項(xiàng)目所有修改的單點(diǎn)實(shí)體，所有修改都提交到 Master分支上。這種方式與 SVN 的主要區(qū)別就是開發(fā)人員有本地庫，但是Git 很多特性并沒有用到。

如下圖：

上圖說明：

一個(gè)遠(yuǎn)程倉庫。
一個(gè)主分支master。
團(tuán)隊(duì)每個(gè)成員都有一個(gè)本地倉庫，在本地倉庫中進(jìn)行代碼的編輯、暫存和提交工作。

集中式工作流總結(jié)：

適用人群：小型開發(fā)小團(tuán)隊(duì)，習(xí)慣使用SVN工具的小團(tuán)隊(duì)。

工作方式：

團(tuán)隊(duì)組長(zhǎng)創(chuàng)建遠(yuǎn)程倉庫，創(chuàng)建一個(gè)master分支，組員可讀可寫。
每個(gè)開發(fā)人員都git clone遠(yuǎn)程倉庫到本地倉庫，在master分支上開發(fā)。
每次開發(fā)都要git pull更新遠(yuǎn)程倉庫的master分支版本到本地。
每次開發(fā)完成就git commit到本地倉庫，接著git push到遠(yuǎn)程倉庫。

缺點(diǎn)：

忘了git push，一直會(huì)提交到本地倉庫，沒有推送到遠(yuǎn)程倉庫。
忘了git pull，導(dǎo)致本地倉庫與中央倉庫不一致，發(fā)生文件沖突。
大量操作git pull，導(dǎo)致增加Git分支合并次數(shù)，增加了Git變基次數(shù)，降低了Git的性能。

3、分支工作流

功能分支工作流在集中式工作流的基礎(chǔ)上，為各個(gè)新功能分配一個(gè)專門的分支來開發(fā)，即在master主分支外在創(chuàng)建一個(gè)分支，程序員開發(fā)的新功能全部push到此分支上，等到功能成熟的時(shí)候，再把此分支合并到主分支master上。

如下圖：

分支工作流總結(jié)：

適用人群：小型開發(fā)團(tuán)隊(duì)，熟悉Git分支的團(tuán)隊(duì)。

工作方式：

團(tuán)隊(duì)組長(zhǎng)創(chuàng)建遠(yuǎn)程倉庫，創(chuàng)建一個(gè)master分支，組員可讀不可寫。
每個(gè)開發(fā)人員都git clone遠(yuǎn)程倉庫到本地倉庫。
每個(gè)開發(fā)人員創(chuàng)建自己的feature分支，在feature分支上開發(fā)。（記住，feature分支是基于master分支）
每個(gè)開發(fā)人員每次開發(fā)完成就git commit到本地倉庫中自己的feature分支，接著git push到遠(yuǎn)程倉庫。
通過pull request提醒團(tuán)隊(duì)組長(zhǎng)，瀏覽組員提交feature分支。
組長(zhǎng)把feature分支拉下來，然后合并到自己本地倉庫的master分支上測(cè)試。
組長(zhǎng)測(cè)試feature分支通過之后，由組長(zhǎng)負(fù)責(zé)把feature分支合并到遠(yuǎn)程倉庫的master分支上。
組長(zhǎng)在遠(yuǎn)程倉庫把合并過的feature分支刪除。
組員在本地倉庫把合并過的feature分支刪除。
組員將本地倉庫分支切換為master分支，然后git pull將本地倉庫的master分支更新到遠(yuǎn)程倉庫的master分支版本。

缺點(diǎn)：

增加團(tuán)隊(duì)組長(zhǎng)的工作量。
增加團(tuán)隊(duì)組員提交步驟。

說明：Pull Request作用是可以讓其他組員或組長(zhǎng)可以查看你的代碼，并可以提出代碼修改意見或者討論。

4、GitFlow 工作流(最流行)

Gitflow工作流沒有用超出上面功能分支工作流的概念和命令，而是為不同的分支，分配一個(gè)很明確的角色，并定義分支之間如何交互，和什么時(shí)候進(jìn)行交互。

除了有master主分支（用于存儲(chǔ)正式發(fā)布的歷史版本）外，還有一個(gè)作為功能集成分支的develop分支。
當(dāng)初始化完成后，某個(gè)程序員想要開發(fā)一個(gè)功能，并不是直接從master分支上拉出新分支，而是使用develop分支作為父分支來拉出新分支。
當(dāng)新功能完成后，再合并回父分支，新功能的提交并不與master分支直接交互。
一旦develop分支上有了做一次發(fā)布（或者說快到了既定的發(fā)布日）的足夠功能，就從develop分支上checkout一個(gè)發(fā)布分支。
新建的發(fā)布分支用于開始發(fā)布循環(huán)，所以從這個(gè)時(shí)間點(diǎn)開始之后新的功能，不能再加到這個(gè)分支上，該分支只應(yīng)該做Bug修復(fù)、文檔生成和其它面向發(fā)布任務(wù)。
一旦對(duì)外發(fā)布的工作都完成了，發(fā)布分支合并到master分支，并分配一個(gè)版本號(hào)打好Tag。
另外，這些從新建發(fā)布分支以來的做的修改，要合并回develop分支上。
維護(hù)分支或說是熱修復(fù)（hotfix）分支用于，快速給產(chǎn)品發(fā)布版本（production releases）打補(bǔ)丁，這是唯一可以直接從master分支fork出來的分支。
修復(fù)完成，修改應(yīng)該馬上合并回master分支和develop分支（當(dāng)前的發(fā)布分支），master分支應(yīng)該用新的版本號(hào)打好Tag。
為Bug修復(fù)使用專門分支，讓團(tuán)隊(duì)可以快速處理掉問題，而不用打斷其它工作或是等待下一個(gè)發(fā)布循環(huán)。
你可以把維護(hù)分支想成是一個(gè)直接在master分支上處理的臨時(shí)發(fā)布。

總結(jié)就是：Gitflow 工作流通過為功能開發(fā)、發(fā)布準(zhǔn)備和維護(hù)設(shè)立了獨(dú)立的分支，讓發(fā)布迭代過程更流暢，充分的利用了分支的特點(diǎn)。嚴(yán)格的分支模型也為大型項(xiàng)目提供了一些非常必要的結(jié)構(gòu)。

下圖是完整的Gitflow 工作流開發(fā)方式圖，但實(shí)際開發(fā)工作環(huán)境可能會(huì)精簡(jiǎn)：

Gitflow工作流總結(jié)：

適用人群：任何開發(fā)團(tuán)隊(duì)，熟悉Git分支的團(tuán)隊(duì)。

工作方式：

項(xiàng)目維護(hù)者創(chuàng)建項(xiàng)目維護(hù)者的遠(yuǎn)程倉庫，創(chuàng)建master分支與develop分支，貢獻(xiàn)者可讀不可寫。
每個(gè)貢獻(xiàn)者git clone遠(yuǎn)程倉庫中的develop分支到本地倉庫。（記住，develop分支相當(dāng)于master的分支，包括功能開發(fā)，修改，測(cè)試。master分支相當(dāng)于最終分支）
每個(gè)貢獻(xiàn)者在本地倉庫創(chuàng)建自己的feature分支，在feature分支上開發(fā)。
在feature分支又可以創(chuàng)建多個(gè)feature分支，繼續(xù)開發(fā)項(xiàng)目。
每個(gè)貢獻(xiàn)者每次開發(fā)完成就git commit到本地倉庫中自己的feature分支，接著git push到遠(yuǎn)程倉庫。
通過pull request提醒項(xiàng)目維護(hù)者，瀏覽貢獻(xiàn)者提交feature分支。
項(xiàng)目維護(hù)者把feature分支拉下來，然后合并到自己本地倉庫的develop分支上測(cè)試。
組長(zhǎng)測(cè)試feature分支通過之后，由組長(zhǎng)負(fù)責(zé)把feature分支合并到遠(yuǎn)程倉庫的develop分支上。
項(xiàng)目維護(hù)者會(huì)release分支上git tag打上版本號(hào)。
項(xiàng)目維護(hù)者可以從develop分支創(chuàng)建release分支，接著把release分支合并到master分支上，同時(shí)master分支同步到develop分支。
項(xiàng)目維護(hù)者在遠(yuǎn)程倉庫把合并過的feature分支刪除。
每個(gè)貢獻(xiàn)者在本地倉庫把合并過的feature分支刪除。
每個(gè)貢獻(xiàn)者將本地倉庫分支切換為develop分支，然后git pull將本地倉庫的master分支更新到遠(yuǎn)程倉庫的develop分支版本。

說明：Gitflow工作流是Vincent Driessen工程師提出的多分支工作流。

5、Forking 工作流(偶爾使用)

分叉(Forking)工作流也可以叫做分布式工作流，是在 GitFlow工作流的基礎(chǔ)上的衍生，充分利用了Git在分支和克隆上的優(yōu)勢(shì)，再加上pull request 的功能，以達(dá)到代碼審核的目的。既可以管理大團(tuán)隊(duì)的開發(fā)者（developer）的提交，也可以接受不信任貢獻(xiàn)者（contributor）的提交。

這種工作流使得每個(gè)開發(fā)者都有一個(gè)服務(wù)端倉庫（此倉庫只有自己可以push推送，但是所有人都可以pull拉取修改），每個(gè)程序員都push代碼到自己的服務(wù)端倉庫，但不能push到正式倉庫，只有項(xiàng)目維護(hù)者才能push到正式倉庫，這樣項(xiàng)目維護(hù)者可以接受任何開發(fā)者的提交，但無需給他正式代碼庫的寫權(quán)限。

這種工作流適合開源社區(qū)的開源項(xiàng)目，大家統(tǒng)一對(duì)項(xiàng)目做貢獻(xiàn)，但是有一個(gè)人或一個(gè)團(tuán)隊(duì)作為開發(fā)者來管理項(xiàng)目，所有的貢獻(xiàn)者的代碼由開發(fā)者審核，其功能完善之后再由開發(fā)者push到正式倉庫中。

總結(jié)：

分叉(Forking)工作流更適合安全可靠地管理大團(tuán)隊(duì)的開發(fā)者，而且能接受不信任貢獻(xiàn)者的提交。
在實(shí)際工作中，如果偶爾有需要團(tuán)隊(duì)外的成員幫我們解決問題時(shí)，可能會(huì)用到。
這種工作流程并不常用，只有當(dāng)項(xiàng)目極為龐雜，或者需要多級(jí)別管理時(shí)，才會(huì)體現(xiàn)出優(yōu)勢(shì)。利用這種方式，項(xiàng)目總負(fù)責(zé)人（即主管）可以把大量分散的集成工作，委托給不同的小組負(fù)責(zé)人分別處理，然后在不同時(shí)刻將大塊的代碼子集統(tǒng)籌起來，用于之后的整合。

圖示如下：

提示：

每個(gè)成員都可以從中央版本庫中拉取代碼。
每級(jí)成員都只能向上一級(jí)提交代碼。
上一級(jí)合并代碼之后繼續(xù)向上級(jí)提交代碼。
最后只有獨(dú)裁者才能向中央版本庫提交代碼。

分叉工作流（分布式倉庫工作流）總結(jié)：

適用人群：大型開發(fā)團(tuán)隊(duì)，熟悉Git分支的團(tuán)隊(duì)。

工作方式：

主項(xiàng)目維護(hù)者創(chuàng)建遠(yuǎn)程倉庫，創(chuàng)建一個(gè)master分支，從項(xiàng)目維護(hù)者可讀不可寫。
從項(xiàng)目維護(hù)者通過fork主項(xiàng)目維護(hù)者的遠(yuǎn)程倉庫的副本，到自己的遠(yuǎn)程倉庫，包括master分支。（記住，從項(xiàng)目維護(hù)者的遠(yuǎn)程倉庫獨(dú)立于主項(xiàng)目維護(hù)者的遠(yuǎn)程倉庫）
從項(xiàng)目維護(hù)者git clone主項(xiàng)目維護(hù)者的遠(yuǎn)程倉庫的副本到本地倉庫。
從項(xiàng)目維護(hù)者創(chuàng)建自己的feature分支，在feature分支上開發(fā)。
從項(xiàng)目維護(hù)者每次開發(fā)完成就git commit到本地倉庫中自己的feature分支，接著git push到遠(yuǎn)程倉庫。
通過pull request命令，從項(xiàng)目維護(hù)者合并自己feature分支，到從項(xiàng)目維護(hù)者的遠(yuǎn)程倉庫的master分支上。
從項(xiàng)目維護(hù)者在遠(yuǎn)程倉庫把合并過的feature分支刪除。
從項(xiàng)目維護(hù)者在本地倉庫把合并過的feature分支刪除。
從項(xiàng)目維護(hù)者在遠(yuǎn)程倉庫通過pull request向主項(xiàng)目維護(hù)者的遠(yuǎn)程倉庫的推送。
主項(xiàng)目維護(hù)者通過pull request獲取從項(xiàng)目維護(hù)者的遠(yuǎn)程倉庫的推送。
主項(xiàng)目維護(hù)者進(jìn)行從項(xiàng)目維護(hù)者的遠(yuǎn)程倉庫代碼審查，測(cè)試。
主項(xiàng)目維護(hù)者確認(rèn)無誤后，可以直接合并到主項(xiàng)目維護(hù)者的遠(yuǎn)程倉庫。