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分支的使命已經完成，沒有什麼做用了，將其刪除掉。只剩下一個主分支。

 

原文地址：http://www.cnblogs.com/Josiah-Lin/p/6847973.html