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

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


集中式和分佈式

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

image.png


git工作區和緩存區

git在本地工作的工作狀態如下所示,對於新添加/更新的文件只有通過git add添加到緩存區,然後通過git commit才能提交到倉庫中。

image.png


可能涉及到的操作。

  • 創建版本庫

    git init(這個用到的很少)

  • 添加文件並且提交

    git add & git commit

  • 查看提交日誌

    git log


gitlab遠程倉庫

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

image.png

git工作流

網上介紹工作流的文章也很多,大致分成下面三種:

  • Git flow

  • Github flow

  • Gitlab flow

感覺根據項目的實際情況都略有差別。我們的工作流採取如下方式:

image.png

開發步驟說明:

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是它的名字。

image.png

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

image.png


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

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


上線

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

image.png

常規上線流程

  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等擴展功能。


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章