如何選擇版本控制系統之二——Git的研發應用場景

Git 軟件 Linux 華為 程序員那點事 2017-05-25

之前寫了一篇《如何選擇版本控制系統 ---為什麼選擇Git版本控制系統》,有興趣的可以去看看,本篇文章算是這個系列的第二篇文章。

如何選擇版本控制系統之二——Git的研發應用場景

Git誕生於2002年,由Linux之父Linus Torvalds和他的團隊開發並不斷完善,它秉承了Linux的開源精神,為廣大研發團隊帶來了非常棒的版本控制體驗。本文立足Git的工作原理,深入探討各種研發場景中工作流等問題。

Git工作模式

代碼提交過程

一次修改被成功提交到遠端倉庫會歷經四個階段,1本地工作區->2緩存區->3版本庫->4遠端版本庫,通過執行相應的Git命令,文件在這四個區域跳轉,並呈現不同的狀態:

1.已修改(modified):包括三種文件,新增文件,被修改的文件,被刪除的文件

2.已暫存(staged):對已修改的文件執行git add或git rm操作,文件就變成已暫存狀態,進入暫存區。暫存區實際上就是一個文件索引目錄樹,記錄了所有文件名、文件狀態信息,它已索引的方式建立了文件名和文件內容(在對象庫.git/objects中保存)的對應關係。

3.已提交(committed):對已暫存的文件執行git commit操作,文件就變成已提交狀態,進入本地版本倉庫。

4.已上傳:對已提交的文件執行git push操作,文件就變成已上傳狀態,進入遠端版本倉庫。

如何選擇版本控制系統之二——Git的研發應用場景

Git如何記錄每次提交

我們思考一下,版本控制系統應該如何記錄每次提交呢?正常的思維肯定是記錄“差異”(delta),也就是前後兩個版本中文件內容的不同,確實大多數版本控制系統是這麼做的,比如我們所熟悉的CVS,SVN。但是,Git卻不這樣!每次提交更新時,Git會對全部文件作一個快照(snapshot),並保存指向這次快照的索引。

這種保存方式帶來很多好處,切換版本時,直接引用指向目標版本的索引即可,不需要像差異存儲那樣,需要版本之間的merge,速度會快很多,更重要的是,為後文所講到的輕量級分支切換提供了前提條件。

如何選擇版本控制系統之二——Git的研發應用場景

Git分支

Git新建分支的本質就是創建一個指向最後一次提交的可變指針,所以,Git分支的創建不是複製版本庫的內容,僅僅是新建了一個指針,它以40個字符長度SHA-1字串形式保存在文件中,這難以想象的輕量級就是源於“快照”保存的版本設計理念。

如何選擇版本控制系統之二——Git的研發應用場景

Git工作流

什麼是Git工作流?你可以理解為代碼管理的分支策略。這裡從典型的GitFlow工作流出發,配合我正在使用的代碼託管平臺(華為軟件開發雲),給大家詳細講解工作流是如何服務於項目流程管理和團隊協同開發。

Ømaster:主線分支,版本有較強穩定性,供生產環境部署使用,這個分支只能從其它分支合併,不能在這個分支上直接提交修改。

新建分支:

在開發雲界面輸入新分支名,並選擇從哪個分支檢出即可。

如何選擇版本控制系統之二——Git的研發應用場景

Ødevelop:主開發分支,用來集成測試最新合入的開發成果,包含要發佈到下一個Release的代碼。

Øfeature:特性分支,每個特性一個分支,用於開發人員提交代碼並進行自測。一旦開發完成,我們合併回Develop分支進入下一個Release。

Øhotfix:補丁分支,生產環境發現新Bug時創建的臨時分支,問題驗證後,合併到Master和Develop分支,所以Hotfix的改動會進入下一個Release

Ørelease:發佈分支,發佈新版本時,基於Develop分支創建,發佈完成後,合併到master和develop分支。

各個分支之間的關係可以從開發雲的“倉庫網絡”中查看:

如何選擇版本控制系統之二——Git的研發應用場景

優點:項目管理流程明確

缺點:相對複雜,需要同時維護兩個長期分支,不適合網站項目。

分支合併

無論哪種工作流都會涉及到分支合併(把一個分支中的修改整合到當前分支),主要有兩種方法:三方合併(merge)和衍合(rebase)。我們通過對同一種場景進行不同操作體會兩種合併方法的區別。

場景:master分支新增了C4節點,hotfix分支新增了C3節點,現將hotfix分支合併到master分支:

1.三方包括hotfix新增節點C3,master新增節點C4,以及兩者的共同祖先節點C2。這種合併操作簡單,但新增合併節點C5,形成了環形,版本記錄可讀性差。

a)PC端命令操作方式:

#git checkout master

#git merge hotfix

b)開發雲平臺頁面操作:

第一步:

如何選擇版本控制系統之二——Git的研發應用場景

第二步:

如何選擇版本控制系統之二——Git的研發應用場景

如何選擇版本控制系統之二——Git的研發應用場景

2.衍合先將master分支新增節點C4以補丁形式保存在.git/rebase目錄中,然後同步hotfix分支最新代碼,再應用補丁C4’。

#git checkout master

#git rebase hotfix

如何選擇版本控制系統之二——Git的研發應用場景

衝突解決

類型一:兩個合併分支修改了同一行代碼

如何選擇版本控制系統之二——Git的研發應用場景

解決方法:

1.分析哪種修改方法正確,手動合併;

2.提交修改。

類型二:文件被重命名為不同的名字

解決方法:

1.確認哪個名字是正確的,刪除錯誤的;

2.提交修改。

結語

根據實際研發場景制定合理的工作流,能有效提高項目管理水平和團隊協同開發能力,而這些分支操作,對於不習慣使用命令的人來說,可以在PC端下載使用圖形化工具tortoisegit,也可以在代碼託管平臺華為軟件開發雲(https://www.hwclouds.com/devcloud/)配置管理服務使用頁面操作。下篇文章會詳細講解代碼託管平臺可視化操作方法。

相關推薦

推薦中...