git及gitlab在項目開發(fā)中的實踐應(yīng)用一

之前總結(jié)過一篇關(guān)于git入門的文章，這幾天心血來潮，結(jié)合我在手機微博開發(fā)團隊中實際經(jīng)驗談一談git在工作中的應(yīng)用吧。

集中式和分布式

git與之前的svn相比，主要體現(xiàn)在集中式和分布式的區(qū)別。集中式主要依托于中央服務(wù)器，開發(fā)人員從中央服務(wù)器獲得最新的代碼，開發(fā)完成后再提交到中央服務(wù)器，脫離了中央服務(wù)器，基本上服務(wù)就不行了。而分布式版本管理系統(tǒng)在本地都有一個倉庫，可以不依賴中央服務(wù)器進行開發(fā)提交代碼，在需要往遠端合并的時候才進行。

git工作區(qū)和緩存區(qū)

git在本地工作的工作狀態(tài)如下所示，對于新添加/更新的文件只有通過git add添加到緩存區(qū)，然后通過git commit才能提交到倉庫中。

可能涉及到的操作。

• 創(chuàng)建版本庫

  git init（這個用到的很少）

• 添加文件并且提交

  git add & git commit

• 查看提交日志

  git log

  
  

gitlab遠程倉庫

因為內(nèi)部商業(yè)代碼，所以我們沒有托管到github，這里使用和gitlhub相似的gitlab作為遠程倉庫，我們使用的社區(qū)版，雖然比商業(yè)版少了些功能，但基本上是夠用的。關(guān)于軟件的安裝我們這里就不做介紹了，周期性的會隨著gitlab的發(fā)布而更新。

git工作流

網(wǎng)上介紹工作流的文章也很多，大致分成下面三種：

• Git flow
  

• Github flow

• Gitlab flow

感覺根據(jù)項目的實際情況都略有差別。我們的工作流采取如下方式：

開發(fā)步驟說明：

1.?project fork

我們的項目一般都隸屬于項目組，日常開發(fā)先把主倉庫fork到自己的空間下。

2.?git clone

通過git clone把自己遠程倉庫上的項目代碼clone到自己本地目錄。

3. git branch & git checkout?

創(chuàng)建分支并且切換到分支上面，我們的所有的功能都是基于分支進行開發(fā)的，每次有新的功能或者對代碼進行改進的時候，我們都會創(chuàng)建一個新的分支進行開發(fā)。

4.?git add & git commit

有更新或者添加的代碼，我們執(zhí)行g(shù)it add和git commit 提交到自己本地倉庫。

5. git pull?

即上圖中的步驟5，同步代碼，開發(fā)功能的時候創(chuàng)建分支開始時，線上的代碼也是往前走的，功能開發(fā)完，代碼可能落后于master的代碼，這時就需要進行同步到最新的代碼，檢查你的功能代碼是否有代碼沖突。

6. git push

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

7. create merge request

當(dāng)接到產(chǎn)品或者業(yè)務(wù)測試的郵件，確定可以上線的時候，創(chuàng)建個merge request，這時代碼就可以進入到待合并狀態(tài)，如果是常規(guī)上線，之后由專人進行合并，QA回歸測試，然后上線。

git remote

上面的工作流中涉及到遠程倉庫的信息，如：git pull，你的代碼是通過你的遠程倉庫拷貝的，為什么可以從遠程項目組倉庫進行代碼同步呢，在這里說下git remote相關(guān)的內(nèi)容。

我們執(zhí)行g(shù)it remote -v 會看到一條通道信息，這個是你本地倉庫到遠程倉庫的通道，origin是它的名字。

然后我們通過git remote add [remote_name] [remote_url] 即可添加一條通道，如上面的upstream（也可以起其他的名字）。這時你本地的倉庫就對應(yīng)兩條通道了。

其中upstream是不可以直接push代碼的，僅用于同步代碼。

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

上線

我們之前采用的如下圖方式進行上線。

常規(guī)上線流程

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

2. 在某個時間點，比如今天的11點吧（個人推薦11:00左右上線，即上午上線），如果測試沒有問題，此時基于master創(chuàng)建個上線的tag，我們命名為release.0722.0，然后把它推上線。

3. 穩(wěn)定之后，我們進行下一個版本的準備，此時基于master創(chuàng)建一個分支branch，比如：online.0723.0。

4. 然后將準備在0723.0上線的merge request都合并到這個分支上面。然后創(chuàng)建QA回歸測試tag 如candidate.0722.0，然后把這個測試tag推到仿真機器上測試。

5. 當(dāng)QA測試沒有問題后，會給開發(fā)測試郵件，此時我們會把上述online.0723.0的代碼合并到master上，然后基于master打出一個最新的常規(guī)上線包如release.0723.0上線，此時也確保master上面是最新的代碼。

? 6. 如此反復(fù)，進入下一階段的常規(guī)上線循環(huán)。

緊急上線流程

對于緊急上線流程的情況，我們這里還是十分常見的，比如緊急修復(fù)bug，緊急功能上線等情況。

緊急上線必然有緊急的流程應(yīng)對，首先，這個需求必須領(lǐng)導(dǎo)知道的。然后業(yè)務(wù)方測試沒有問題，在確認沒有問題的情況下，這部分代碼是直接合并到master上，如圖中步驟6，然后基于最新的master代碼創(chuàng)建tag，如release.0723.1，然后上線。這個地方其實可以加上一個emergency標識，告訴大家這個上線是個緊急上線。

好了，關(guān)于git和gitlab的基本功能就到這里了，下一篇文章我們介紹下git hooks和gitlab hooks以及gitlabCI等擴展功能。