1. 程式人生 > >Git 多人協作開發的過程

Git 多人協作開發的過程

Git可以完成兩件事情:

1. 版本控制

2.多人協作開發

如今的專案,規模越來越大,功能越來越多,需要有一個團隊進行開發。

如果有多個開發人員共同開發一個專案,如何進行協作的呢。

Git提供了一個非常好的解決方案 ---- 多人協作開發。

1.多人協作原理

典型的做法是,首先建立一個git伺服器,被多個人所操作。

1.多人協助實現

分為如下幾個步驟:

1.建立一個git裸伺服器 (git init --bare)

2.從裸伺服器將版本庫克隆至本地(git clone )

3.本地常規操作

4.推送版本至伺服器 (git remote +  git push origin master)

5.從遠端伺服器拉取版本(git pull)

一般而言,我們需要在Linux伺服器上來搭建我們的git版本伺服器,每個公司都會有。

由專案負責人開始。

我們現在是windows系統上模擬這個操作過程。

(1).建立一個git裸伺服器 (git init --bare)

由負責人來完成的。伺服器新建一個專案目錄,如git-server

建立完畢,我們發現git-server內容和上次的不太一樣。

上次使用git init 建立之後,會有一個隱藏的.git目錄。目錄中的才是現在看到的內容。

也就是說,現在根本就沒有.git目錄了。

這就意味著在這個目錄中,不能做常規的開發。

(2).從裸伺服器將版本庫克隆至本地(git clone )

在git版本伺服器,一般是不做任何開發工作的。如果要開發專案,就需要將版本庫從伺服器克隆到本地。

假設有一個程式設計師甲,開始自己的工作了。

使用命令 git clone git版本伺服器地址

在windows下面,就是使用絕對路徑,如下:

然後,甲就可以在這個目錄下,進行常規開發。

我們可以在這個目錄下,建立自己的工作區目錄,完成常規開發。

(3).本地常規操作

甲可以,在本地進行常規開發。

這個過程,可以反覆進行。

我的第一個模組(功能)開發完畢。需要將其推送到伺服器。

(4).推送版本至伺服器 (git remote +  git push origin master)

當在本地完成一個模組(功能),需要推送到伺服器,供其他同事使用。

第一件事情,需要知道伺服器在哪兒?

git remote

第二件事情,直接推送即可

git push origin master

其中origin就是使用git remote得到的遠端伺服器的名稱。

master表示是主分支。

對於甲來說,它的工作已經告一段落了,該輪到乙程式設計師出場了。

乙程式設計師,首先將版本庫從git伺服器上克隆到本地。

 

開啟這個目錄,然後進可以看到最新新的內容,如下:

對於乙而言,可以在本地進行常規開發。與此同時,甲繼續他的常規開發。

模擬乙程式設計師在本地的開發。

將完成的工作,推送到git伺服器。

回頭,再看看甲的開發。

甲收工,準備下班了。在下班之前,需要將最新版本推送到git伺服器。

開始使用命令,執行如下:

結果出錯了,why?

之所以會出錯,原因在於:其他程式設計師已經將最新的一個版本提交到git伺服器上,但是你在提交之前,已經不是最新的。

在這種情況下,甲,需要先從伺服器拉取最新的版本。

(5).從遠端伺服器拉取版本(git pull)

在多人協助開發時,每個開發人員在推送自己的最新版本時,都需要確保當前版本是最新的,所以就需要先獲取最新版本,也就是說需要從伺服器拉取最新版本到本地。

需要使用 git pull命令

如此一來,甲當前就是最新的版本。

然後再次使用 git push 命令推送至伺服器。

接下來需要分兩種情況:

如果有新的開發人員加入進來,重複2~5過程。

如果不是新的開發人員,重複3~5過程。

比如,對於乙而言,其實它現在已經不是最新的版本了,所以需要使用 git pull 拉取最新版本。

所以,對很多開發人員而言,一開啟電腦,馬上先git pull,拉取最新的。然後進行常規開發,

開發完畢之後,在git push之前,還需要使用git pull再拉取一遍。

如果還有一個新的程式設計師丙,加入了,怎麼辦呢?

需要先git clone

然後就進行常規開發,推送版本、拉取版本。

在整個協作開發時,有時候會出現衝突。通常都是由於開發人員分工不明確導致的,所以如果出現這種情況,需要兩個程式設計師協商解決。

3.分支

(1).什麼是分支

在前面所有的操作當中,我們一直使用的是master主分支。以剛才的專案版本控制為例

有四個版本,在我們的版本庫中,都是存在於master主分支上的。

圖示如下:

如果我們的專案本身比較簡單,只需要有主分支master就夠了。

但是,實際上並不是這樣的。

在這個世界上,有一種軟體叫做開源軟體 -- 原始碼開發,所有的人都可以免費使用。

開源軟體是由世界上無數的程式設計師共同來開發。

每個程式設計師都可以建立一個自己的分支,這個自己分支和主master完全獨立的兩個分支。

相應的,每個程式設計師都可以擁有自己的分支,可以進行任何的開發,此時和master沒有什麼關係的。

一旦開發完畢,就可以將你的分支合併到主分支上去。

什麼時候會用到分支呢?

假設你準備開發一個新功能,但是需要兩週才能完成,第一週你寫了50%的程式碼,如果立刻提交,由於程式碼還沒寫完,不完整的程式碼庫會導致別人不能幹活了。如果等程式碼全部寫完再一次提交,又存在丟失每天進度的巨大風險,怎麼辦?

你可以建立一個屬於自己的分支,別人看不見,還繼續在原來的分支上工作,而你在自己的分支上進行開發,等開發完畢,合併即可。

在開源世界中,需用大量的程式設計師共同維護一個專案。也是需要使用分支,如Jquery。

(2).分支的基本操作

基本操作有如下幾個:

1. 檢視當前分支 (git branch)

2. 建立分支 (git branch 分支名)

3.切換分支(git checkout 分支名)

4.分支上的常規操作

5.分支的合併 (git checkout master + git merge 分支名)

6.分支的刪除(git branch -d 分支名)

檢視當前分支 (git branch)

 

其中的 * 表示 當前分支。

預設情況下,只有一個master主分支。

建立分支 (git branch 分支名)

切換分支(git checkout 分支名)

建立完成之後,就有了一個新的分支,但是並沒有立即切換到新的分支,需要使用命令切換一下。

分支上的常規操作

已經切換到b1分支上,就可以在b1分支進行常規開發和操作。

 

使用git add 和git commit提交。

使用git log檢視即可:

與之對應的,我們再次切換到master分支上看看是什麼情況:

說明在master分支上,並沒有新提交的內容。

分支的合併 (git checkout master + git merge 分支名)

分支的合併,一定是在 主分支上進行的。

只能在主分支合併其它分支。

需要兩步:

1) 切換到主分支

2) 使用git merge 分支名 進行合併

再次檢視master的一個log情況,如下:

分支的刪除(git branch -d 分支名)

使用命令git branch -d 分支名

如果你發現你的分支中所做的開發沒有任何用處,也可以不合並直接刪除。

(3).分支的原理

分支的過程及原理如下:

預設只有master的情況下,master總是指向最新的版本,而HEAD指標總是指向master的。

現在,我建立了一個新的分支dev,將當前分支指定為dev,此時,master和dev都指向當前最新版本,但是HEAD指標已經指向了dev分支。

接下來,我們提交了新的版本,dev指向最新版本,而master則原地不動。

HEAD指向當前分支dev的。

當在dev分支上完成開發之後,可以將它合併到主分支master上。

合併時,需要先切換到master,意味著HEAD指向了master,合併的時候其實就是將master和dev的最新版本同步。

dev分支的使命已經完成,沒有什麼作用了,將其刪除掉。只剩下一個主分支。