Git在項目中的協(xié)作模式是什么

今天小編給大家分享一下Git在項目中的協(xié)作模式是什么的相關知識點，內(nèi)容詳細，邏輯清晰，相信大部分人都還太了解這方面的知識，所以分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后有所收獲，下面我們一起來了解一下吧。

1、分布式工作流程

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

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

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

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

2、集中式工作流

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

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

如下圖：

上圖說明：

• 一個遠程倉庫。

• 一個主分支master。

• 團隊每個成員都有一個本地倉庫，在本地倉庫中進行代碼的編輯、暫存和提交工作。

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

適用人群：小型開發(fā)小團隊，習慣使用SVN工具的小團隊。

工作方式：

• 團隊組長創(chuàng)建遠程倉庫，創(chuàng)建一個master分支，組員可讀可寫。

• 每個開發(fā)人員都git clone遠程倉庫到本地倉庫，在master分支上開發(fā)。

• 每次開發(fā)都要git pull更新遠程倉庫的master分支版本到本地。

• 每次開發(fā)完成就git commit到本地倉庫， 接著git push到遠程倉庫。

缺點：

• 忘了git push，一直會提交到本地倉庫，沒有推送到遠程倉庫。

• 忘了git pull，導致本地倉庫與中央倉庫不一致，發(fā)生文件沖突。

• 大量操作git pull，導致增加Git分支合并次數(shù)，增加了Git變基次數(shù)，降低了Git的性能。

3、分支工作流

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

如下圖：

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

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

工作方式：

• 團隊組長創(chuàng)建遠程倉庫，創(chuàng)建一個master分支，組員可讀不可寫。

• 每個開發(fā)人員都git clone遠程倉庫到本地倉庫。

• 每個開發(fā)人員創(chuàng)建自己的feature分支，在feature分支上開發(fā)。（記住，feature分支是基于master分支）

• 每個開發(fā)人員每次開發(fā)完成就git commit到本地倉庫中自己的feature分支， 接著git push到遠程倉庫。

• 通過pull request提醒團隊組長，瀏覽組員提交feature分支。

• 組長把feature分支拉下來，然后合并到自己本地倉庫的master分支上測試。

• 組長測試feature分支通過之后，由組長負責把feature分支合并到遠程倉庫的master分支上。

• 組長在遠程倉庫把合并過的feature分支刪除。

• 組員在本地倉庫把合并過的feature分支刪除。

• 組員將本地倉庫分支切換為master分支，然后git pull將本地倉庫的master分支更新到遠程倉庫的master分支版本。

缺點：

• 增加團隊組長的工作量。

• 增加團隊組員提交步驟。

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

4、GitFlow 工作流(最流行)

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

• 除了有master主分支（用于存儲正式發(fā)布的歷史版本）外，還有一個作為功能集成分支的develop分支。
  當初始化完成后，某個程序員想要開發(fā)一個功能，并不是直接從master分支上拉出新分支，而是使用develop分支作為父分支來拉出新分支。
  當新功能完成后，再合并回父分支，新功能的提交并不與master分支直接交互。

• 一旦develop分支上有了做一次發(fā)布（或者說快到了既定的發(fā)布日）的足夠功能，就從develop分支上checkout一個發(fā)布分支。
  新建的發(fā)布分支用于開始發(fā)布循環(huán)，所以從這個時間點開始之后新的功能，不能再加到這個分支上，該分支只應該做Bug修復、文檔生成和其它面向發(fā)布任務。
  一旦對外發(fā)布的工作都完成了，發(fā)布分支合并到master分支，并分配一個版本號打好Tag。
  另外，這些從新建發(fā)布分支以來的做的修改，要合并回develop分支上。

• 維護分支或說是熱修復（hotfix）分支用于，快速給產(chǎn)品發(fā)布版本（production releases）打補丁，這是唯一可以直接從master分支fork出來的分支。
  修復完成，修改應該馬上合并回master分支和develop分支（當前的發(fā)布分支），master分支應該用新的版本號打好Tag。
  為Bug修復使用專門分支，讓團隊可以快速處理掉問題，而不用打斷其它工作或是等待下一個發(fā)布循環(huán)。
  你可以把維護分支想成是一個直接在master分支上處理的臨時發(fā)布。

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

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

Gitflow工作流總結(jié)：

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

工作方式：

• 項目維護者創(chuàng)建項目維護者的遠程倉庫，創(chuàng)建master分支與develop分支，貢獻者可讀不可寫。

• 每個貢獻者git clone遠程倉庫中的develop分支到本地倉庫。（記住，develop分支相當于master的分支，包括功能開發(fā)，修改，測試。master分支相當于最終分支）

• 每個貢獻者在本地倉庫創(chuàng)建自己的feature分支，在feature分支上開發(fā)。

• 在feature分支又可以創(chuàng)建多個feature分支，繼續(xù)開發(fā)項目。

• 每個貢獻者每次開發(fā)完成就git commit到本地倉庫中自己的feature分支， 接著git push到遠程倉庫。

• 通過pull request提醒項目維護者，瀏覽貢獻者提交feature分支。

• 項目維護者把feature分支拉下來，然后合并到自己本地倉庫的develop分支上測試。

• 組長測試feature分支通過之后，由組長負責把feature分支合并到遠程倉庫的develop分支上。

• 項目維護者會release分支上git tag打上版本號。

• 項目維護者可以從develop分支創(chuàng)建release分支，接著把release分支合并到master分支上，同時master分支同步到develop分支。

• 項目維護者在遠程倉庫把合并過的feature分支刪除。

• 每個貢獻者在本地倉庫把合并過的feature分支刪除。

• 每個貢獻者將本地倉庫分支切換為develop分支，然后git pull將本地倉庫的master分支更新到遠程倉庫的develop分支版本。

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

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

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

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

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

總結(jié)：

• 分叉(Forking)工作流更適合安全可靠地管理大團隊的開發(fā)者，而且能接受不信任貢獻者的提交。

• 在實際工作中，如果偶爾有需要團隊外的成員幫我們解決問題時，可能會用到。

• 這種工作流程并不常用，只有當項目極為龐雜，或者需要多級別管理時，才會體現(xiàn)出優(yōu)勢。 利用這種方式，項目總負責人（即主管）可以把大量分散的集成工作，委托給不同的小組負責人分別處理，然后在不同時刻將大塊的代碼子集統(tǒng)籌起來，用于之后的整合。

圖示如下：

提示：

• 每個成員都可以從中央版本庫中拉取代碼。

• 每級成員都只能向上一級提交代碼。

• 上一級合并代碼之后繼續(xù)向上級提交代碼。

• 最后只有獨裁者才能向中央版本庫提交代碼。

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

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

工作方式：

• 主項目維護者創(chuàng)建遠程倉庫，創(chuàng)建一個master分支，從項目維護者可讀不可寫。

• 從項目維護者通過fork主項目維護者的遠程倉庫的副本，到自己的遠程倉庫，包括master分支。（記住，從項目維護者的遠程倉庫獨立于主項目維護者的遠程倉庫）

• 從項目維護者git clone主項目維護者的遠程倉庫的副本到本地倉庫。

• 從項目維護者創(chuàng)建自己的feature分支，在feature分支上開發(fā)。

• 從項目維護者每次開發(fā)完成就git commit到本地倉庫中自己的feature分支， 接著git push到遠程倉庫。

• 通過pull request命令，從項目維護者合并自己feature分支，到從項目維護者的遠程倉庫的master分支上。

• 從項目維護者在遠程倉庫把合并過的feature分支刪除。

• 從項目維護者在本地倉庫把合并過的feature分支刪除。

• 從項目維護者在遠程倉庫通過pull request向主項目維護者的遠程倉庫的推送。

• 主項目維護者通過pull request獲取從項目維護者的遠程倉庫的推送。

• 主項目維護者進行從項目維護者的遠程倉庫代碼審查，測試。

• 主項目維護者確認無誤后，可以直接合并到主項目維護者的遠程倉庫。

以上就是“Git在項目中的協(xié)作模式是什么”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家閱讀完這篇文章都有很大的收獲，小編每天都會為大家更新不同的知識，如果還想學習更多的知識，請關注億速云行業(yè)資訊頻道。