Git的研發(fā)應(yīng)用場(chǎng)景是怎樣的

Git的研發(fā)應(yīng)用場(chǎng)景是怎樣的，很多新手對(duì)此不是很清楚，為了幫助大家解決這個(gè)難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來(lái)學(xué)習(xí)下，希望你能有所收獲。

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

Git工作模式

代碼提交過(guò)程

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

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

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

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

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

Git如何記錄每次提交

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

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

Git分支

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

Git工作流

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

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

新建分支：

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

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

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

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

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

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

優(yōu)點(diǎn)：項(xiàng)目管理流程明確

缺點(diǎn)：相對(duì)復(fù)雜，需要同時(shí)維護(hù)兩個(gè)長(zhǎng)期分支，不適合網(wǎng)站項(xiàng)目。

分支合并

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

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

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

a)PC端命令操作方式：

#git checkout master

#git merge hotfix

b)開發(fā)云平臺(tái)頁(yè)面操作：

第一步：

第二步：

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

#git checkout master

#git rebase hotfix

沖突解決

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

解決方法：

1.分析哪種修改方法正確，手動(dòng)合并；

2.提交修改。

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

解決方法：

1.確認(rèn)哪個(gè)名字是正確的，刪除錯(cuò)誤的；

2.提交修改。

看完上述內(nèi)容是否對(duì)您有幫助呢？如果還想對(duì)相關(guān)知識(shí)有進(jìn)一步的了解或閱讀更多相關(guān)文章，請(qǐng)關(guān)注億速云行業(yè)資訊頻道，感謝您對(duì)億速云的支持。