git及gitlab在項目開發中的實踐應用一

以前總結過一篇關於git入門的文章，這幾天心血來潮，結合我在手機微博開發團隊中實際經驗談一談git在工做中的應用吧。

集中式和分佈式

git與以前的svn相比，主要體如今集中式和分佈式的區別。集中式主要依託於中央服務器，開發人員從中央服務器得到最新的代碼，開發完成後再提交到中央服務器，脫離了中央服務器，基本上服務就不行了。而分佈式版本管理系統在本地都有一個倉庫，能夠不依賴中央服務器進行開發提交代碼，在須要往遠端合併的時候才進行。

git工做區和緩存區

git在本地工做的工做狀態以下所示，對於新添加/更新的文件只有經過git add添加到緩存區，而後經過git commit才能提交到倉庫中。

可能涉及到的操做。

• 建立版本庫

  git init（這個用到的不多）

• 添加文件而且提交

  git add & git commit

• 查看提交日誌

  git log

  
  

gitlab遠程倉庫

由於內部商業代碼，因此咱們沒有託管到github，這裏使用和gitlhub類似的gitlab做爲遠程倉庫，咱們使用的社區版，雖然比商業版少了些功能，但基本上是夠用的。關於軟件的安裝咱們這裏就不作介紹了，週期性的會隨着gitlab的發佈而更新。

git工做流

網上介紹工做流的文章也不少，大體分紅下面三種：

• Git flow
  

• Github flow

• Gitlab flow

感受根據項目的實際狀況都略有差異。咱們的工做流採起以下方式：

開發步驟說明：

1. project fork

咱們的項目通常都隸屬於項目組，平常開發先把主倉庫fork到本身的空間下。

2. git clone

經過git clone把本身遠程倉庫上的項目代碼clone到本身本地目錄。

3. git branch & git checkout 

建立分支而且切換到分支上面，咱們的全部的功能都是基於分支進行開發的，每次有新的功能或者對代碼進行改進的時候，咱們都會建立一個新的分支進行開發。

4. git add & git commit

有更新或者添加的代碼，咱們執行git add和git commit 提交到本身本地倉庫。

5. git pull 

即上圖中的步驟5，同步代碼，開發功能的時候建立分支開始時，線上的代碼也是往前走的，功能開發完，代碼可能落後於master的代碼，這時就須要進行同步到最新的代碼，檢查你的功能代碼是否有代碼衝突。

6. git push

這一步是把代碼推送到遠端倉庫上。

7. create merge request

當接到產品或者業務測試的郵件，肯定能夠上線的時候，建立個merge request，這時代碼就能夠進入到待合併狀態，若是是常規上線，以後由專人進行合併，QA迴歸測試，而後上線。

git remote

上面的工做流中涉及到遠程倉庫的信息，如：git pull，你的代碼是經過你的遠程倉庫拷貝的，爲何能夠從遠程項目組倉庫進行代碼同步呢，在這裏說下git remote相關的內容。

咱們執行git remote -v 會看到一條通道信息，這個是你本地倉庫到遠程倉庫的通道，origin是它的名字。

而後咱們經過git remote add [remote_name] [remote_url] 便可添加一條通道，如上面的upstream（也能夠起其餘的名字）。這時你本地的倉庫就對應兩條通道了。

其中upstream是不能夠直接push代碼的，僅用於同步代碼。

git pull upstream master即從遠程master上同步最新的代碼。

上線

咱們以前採用的以下圖方式進行上線。

常規上線流程

1. 一條基準線master，master上面的代碼都是上線最新的代碼，全部人都經過master更新同步代碼。

2. 在某個時間點，好比今天的11點吧（我的推薦11:00左右上線，即上午上線），若是測試沒有問題，此時基於master建立個上線的tag，咱們命名爲release.0722.0，而後把它推上線。

3. 穩定以後，咱們進行下一個版本的準備，此時基於master建立一個分支branch，好比：online.0723.0。

4. 而後將準備在0723.0上線的merge request都合併到這個分支上面。而後建立QA迴歸測試tag 如candidate.0722.0，而後把這個測試tag推到仿真機器上測試。

5. 當QA測試沒有問題後，會給開發測試郵件，此時咱們會把上述online.0723.0的代碼合併到master上，而後基於master打出一個最新的常規上線包如release.0723.0上線，此時也確保master上面是最新的代碼。

  6. 如此反覆，進入下一階段的常規上線循環。

緊急上線流程

對於緊急上線流程的狀況，咱們這裏仍是十分常見的，好比緊急修復bug，緊急功能上線等狀況。

緊急上線必然有緊急的流程應對，首先，這個需求必須領導知道的。而後業務方測試沒有問題，在確認沒有問題的狀況下，這部分代碼是直接合併到master上，如圖中步驟6，而後基於最新的master代碼建立tag，如release.0723.1，而後上線。這個地方其實能夠加上一個emergency標識，告訴你們這個上線是個緊急上線。

好了，關於git和gitlab的基本功能就到這裏了，下一篇文章咱們介紹下git hooks和gitlab hooks以及gitlabCI等擴展功能。