前寫了一篇《如何選擇版本控制系統(tǒng) ---為什么選擇Git版本控制系統(tǒng)》，地址是：http://www.cnblogs.com/goldenfish/p/6876864.html，有興趣的可以去看看，本篇文章算是這個系列的第二篇文章。

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

Git工作模式

 

代碼提交過程

一次修改被成功提交到遠端倉庫會歷經(jīng)四個階段，1本地工作區(qū)->2緩存區(qū)->3版本庫->4遠端版本庫，通過執(zhí)行相應(yīng)的Git命令，文件在這四個區(qū)域跳轉(zhuǎn)，并呈現(xiàn)不同的狀態(tài)：

1.已修改（modified）：包括三種文件，新增文件，被修改的文件，被刪除的文件

2.已暫存（staged）：對已修改的文件執(zhí)行g(shù)it add或git rm操作，文件就變成已暫存狀態(tài)，進入暫存區(qū)。暫存區(qū)實際上就是一個文件索引目錄樹，記錄了所有文件名、文件狀態(tài)信息，它已索引的方式建立了文件名和文件內(nèi)容（在對象庫.git/objects中保存）的對應(yīng)關(guān)系。

3.已提交（committed）：對已暫存的文件執(zhí)行g(shù)it commit操作，文件就變成已提交狀態(tài)，進入本地版本倉庫。

4.已上傳：對已提交的文件執(zhí)行g(shù)it push操作，文件就變成已上傳狀態(tài)，進入遠端版本倉庫。

Git如何記錄每次提交

 

我們思考一下，版本控制系統(tǒng)應(yīng)該如何記錄每次提交呢？正常的思維肯定是記錄“差異”（delta），也就是前后兩個版本中文件內(nèi)容的不同，確實大多數(shù)版本控制系統(tǒng)是這么做的，比如我們所熟悉的CVS，SVN。但是，Git卻不這樣！每次提交更新時，Git會對全部文件作一個快照（snapshot），并保存指向這次快照的索引。

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

Git分支

 

Git新建分支的本質(zhì)就是創(chuàng)建一個指向最后一次提交的可變指針，所以，Git分支的創(chuàng)建不是復(fù)制版本庫的內(nèi)容，僅僅是新建了一個指針，它以40個字符長度SHA-1字串形式保存在文件中，這難以想象的輕量級就是源于“快照”保存的版本設(shè)計理念。

Git工作流

 

什么是Git工作流？你可以理解為代碼管理的分支策略。這里從典型的GitFlow工作流出發(fā)，配合我正在使用的代碼托管平臺(華為軟件開發(fā)云)，給大家詳細講解工作流是如何服務(wù)于項目流程管理和團隊協(xié)同開發(fā)。

?master：主線分支，版本有較強穩(wěn)定性，供生產(chǎn)環(huán)境部署使用，這個分支只能從其它分支合并，不能在這個分支上直接提交修改。

新建分支：

在開發(fā)云界面輸入新分支名，并選擇從哪個分支檢出即可。

 

?develop：主開發(fā)分支，用來集成測試最新合入的開發(fā)成果，包含要發(fā)布到下一個Release的代碼。

?feature：特性分支，每個特性一個分支，用于開發(fā)人員提交代碼并進行自測。一旦開發(fā)完成，我們合并回Develop分支進入下一個Release。

?hotfix：補丁分支，生產(chǎn)環(huán)境發(fā)現(xiàn)新Bug時創(chuàng)建的臨時分支，問題驗證后，合并到Master和Develop分支，所以Hotfix的改動會進入下一個Release

?release：發(fā)布分支，發(fā)布新版本時，基于Develop分支創(chuàng)建，發(fā)布完成后，合并到master和develop分支。

各個分支之間的關(guān)系可以從開發(fā)云的“倉庫網(wǎng)絡(luò)”中查看：

優(yōu)點：項目管理流程明確

缺點：相對復(fù)雜，需要同時維護兩個長期分支，不適合網(wǎng)站項目。

分支合并

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

場景：master分支新增了C4節(jié)點，hotfix分支新增了C3節(jié)點，現(xiàn)將hotfix分支合并到master分支：

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

a)PC端命令操作方式：

#git checkout master

#git merge hotfix

b)開發(fā)云平臺頁面操作：

第一步：

第二步：

2.衍合先將master分支新增節(jié)點C4以補丁形式保存在.git/rebase目錄中，然后同步hotfix分支最新代碼，再應(yīng)用補丁C4’。

#git checkout master

#git rebase hotfix

沖突解決

 

類型一：兩個合并分支修改了同一行代碼

解決方法：

1.分析哪種修改方法正確，手動合并；

2.提交修改。

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

解決方法：

1.確認哪個名字是正確的，刪除錯誤的；

2.提交修改。

結(jié)語

根據(jù)實際研發(fā)場景制定合理的工作流，能有效提高項目管理水平和團隊協(xié)同開發(fā)能力，而這些分支操作，對于不習(xí)慣使用命令的人來說，可以在PC端下載使用圖形化工具tortoisegit，也可以在代碼托管平臺華為軟件開發(fā)云配置管理服務(wù)使用頁面操作。下篇文章會詳細講解代碼托管平臺可視化操作方法。

http://www.cnblogs.com/goldenfish/p/6894161.html