為什么使用Git

Git 是 Linus Torvalds 為了幫助管理 Linux 內(nèi)核開發(fā)而開發(fā)的一個(gè)開放源碼的版本控制軟件厢汹。大神就是大神，在開發(fā)了Linux之后，Git 是又一抗鼎之作拾因。這是唯一的理由么？

Git在軟件開發(fā)中位置——配置管理SCM

Software configuration management (SCM, or just plain CM) is an organizational framework — that is, a discipline — for managing the evolution of computer systems throughout all stages of systems development.

軟件配置管理:通過執(zhí)行版本控制仑氛、變更控制的規(guī)程械荷，以及使用合適的配置管理軟件，來保證所有配置資源的完整性和可跟蹤性版仔。配置管理是對(duì)工作成果的一種有效保護(hù)游盲。沒有軟件配置管理，最大的麻煩是工作成果無法回溯蛮粮。

配置管理的內(nèi)容和目標(biāo)

配置管理的內(nèi)容：

一類是屬于產(chǎn)品的組成部分益缎，例如需求文檔、設(shè)計(jì)文檔然想、源代碼莺奔、測(cè)試用例等等；
另一類是在管理過程中產(chǎn)生的文檔变泄，例如各種計(jì)劃弊仪、報(bào)告等

軟件配置管理是在貫穿整個(gè)軟件生命周期中建立和維護(hù)項(xiàng)目產(chǎn)品的完整性熙卡。它的基本目標(biāo)包括：

1. 軟件配置管理的各項(xiàng)工作是有計(jì)劃進(jìn)行的。
2. 被選擇的項(xiàng)目產(chǎn)品得到識(shí)別励饵，控制并且可以被相關(guān)人員獲取驳癌。
3. 已識(shí)別出的項(xiàng)目產(chǎn)品的更改得到控制。
4. 使相關(guān)組別和個(gè)人及時(shí)了解軟件基準(zhǔn)的狀態(tài)和內(nèi)容役听。

配置管理的主要任務(wù)

軟件配置管理的主要任務(wù)也就歸結(jié)為以下幾條：
（1）制定項(xiàng)目的配置計(jì)劃颓鲜；
（2）對(duì)配置項(xiàng)進(jìn)行標(biāo)識(shí)；
（3）對(duì)配置項(xiàng)進(jìn)行版本控制典予；
（4）對(duì)配置項(xiàng)進(jìn)行變更控制甜滨；
（5）定期進(jìn)行配置審計(jì)；
（6）向相關(guān)人員報(bào)告配置的狀態(tài)瘤袖。

版本控制

版本控制是軟件配置管理的核心功能衣摩。所有位于配置資源庫中的元素都應(yīng)自動(dòng)予以版本的標(biāo)識(shí)，并保證版本命名的唯一性捂敌。版本在生成過程中艾扮，自動(dòng)依照設(shè)定的使用模型自動(dòng)分支、演進(jìn)占婉。

版本控制(Revision control)確保由不同人所編輯的同一檔案都得到更新泡嘴。

版本控制中的基本概念

1）簽入，提交逆济，檢出
2）沖突酌予，解決，合并
3）分支奖慌，版本
4）鎖定抛虫，hook

常見的版本控制工具

作為一個(gè)老碼農(nóng)，枚舉一下曾經(jīng)使用過的版本控制工具简僧。

1. VSS： visual source safe, 微軟的東東建椰，97年寫VC程序時(shí)使用，人多的時(shí)候性能較差涎劈，不知道現(xiàn)在的升級(jí)版怎樣了
2. clearcase： 99年開發(fā)Unix 上分布式式應(yīng)用時(shí)使用，功能強(qiáng)大阅茶，不只限于版本控制蛛枚，有錢的大團(tuán)隊(duì)才去用
3. CVS: 02年在互聯(lián)網(wǎng)熱潮的時(shí)候使用，開源產(chǎn)品脸哀，當(dāng)時(shí)“Copy-Modify-Merge"開發(fā)模型眼前一亮蹦浦。
4. SVN：曾經(jīng)的摯愛，在曾工作的合資公司使用撞蜂，權(quán)限管理和分支合并等方面做的很出色盲镶，并在多個(gè)公司推廣使用侥袜。還記得TortoiseSVN么?那只可愛的小烏龜。
5. perforce:是一款具有輕便快速的SCM工具溉贿、真正的客戶端/服務(wù)器系統(tǒng)等特點(diǎn)的商業(yè)軟件枫吧。高通內(nèi)部使用的版本管理工具。確實(shí)不錯(cuò)宇色。
6. git：現(xiàn)在的最愛......
   比較一下cvs,svn,和git：

開源版本控制工具比較

Git 簡(jiǎn)要

GIT 是一款免費(fèi)的九杂、開源的、分布式的版本控制系統(tǒng)宣蠕。每一個(gè)GIT克隆都是一個(gè)完整的文件庫例隆，含有全部歷史記錄和修訂追蹤能力。其最大特色就是“分支”及“合并”操作快速抢蚀、簡(jiǎn)便镀层。支持離線工作，GIT是整個(gè)項(xiàng)目范圍的原子提交皿曲，而且GIT中的每個(gè)工作樹都包含一個(gè)具有完整項(xiàng)目歷史的倉(cāng)庫唱逢。

核心特點(diǎn)：

1. Git 底層自行維護(hù)的存儲(chǔ)文件系統(tǒng)：存儲(chǔ)的是文件快照，即整個(gè)文件內(nèi)容谷饿，并保存指向快照的索引
2. 去中心化的分布式控制

優(yōu)缺點(diǎn)：

優(yōu)點(diǎn)：

• 適合分布式開發(fā)惶我，強(qiáng)調(diào)個(gè)體。
• 公共服務(wù)器壓力和數(shù)據(jù)量都不會(huì)太大博投， 速度快绸贡、靈活。
• 任意兩個(gè)開發(fā)者之間可以很容易的解決沖突毅哗。
• 離線工作听怕。

缺點(diǎn)：

• 學(xué)習(xí)周期相對(duì)而言比較長(zhǎng)。
• 不符合常規(guī)思維虑绵。
• 代碼保密性差尿瞭，一旦開發(fā)者把整個(gè)庫克隆下來就可以完全公開所有代碼和版本信息。

Git 原理

Git的目錄結(jié)構(gòu)

不論通過git init 還是克隆下來的git 倉(cāng)庫翅睛，都有如下的目錄結(jié)構(gòu)：

這里寫圖片描述

主要目錄結(jié)構(gòu)描述見下表：
<table >

<tr><th>子目錄名<th> 簡(jiǎn)要描述<tr>

<tr><th>branches<th>Git 項(xiàng)目分支信息声搁，新版 Git 已經(jīng)不再使用該目錄<tr>
<tr><th>config <th>Git 項(xiàng)目配置信息<tr>
<tr><th>description <th>Git 項(xiàng)目描述信息<tr>
<tr><th>HEAD<th>指向 Git 項(xiàng)目當(dāng)前分支的頭指針<tr>
<tr><th>hooks<th>默認(rèn)的"hooks"腳本，被特定事件發(fā)生前后觸發(fā)捕发。<tr>
<tr><th>info<th>里面含一個(gè) exclude 文件疏旨，指 Git 項(xiàng)目要忽略的文件。<tr>
<tr><th>objects<th>Git 的數(shù)據(jù)對(duì)象扎酷，包括：commits, trees, blobs, tags檐涝。<tr>
<tr><th>refs<th>指向所有 Git 項(xiàng)目分支的指針<tr>

</table>

所有的分支指針保存在 .git/refs/heads 目錄下，HEAD 在 .git/HEAD 目錄下，標(biāo)簽在 .git/refs/tags 目錄下谁榜。

快照

例如： 一個(gè)工程中有兩個(gè)文件A和B幅聘， 有3個(gè)版本:
V1.0 A和B，V1.5 A1和B窃植，V2.0 A1和B1
在Git 的實(shí)際存儲(chǔ)中實(shí)際存了3個(gè)快照 4個(gè)文件帝蒿。

Git對(duì)文件進(jìn)行 SHA-1 計(jì)算作為文件的唯一ID，并校驗(yàn)了文件完整性撕瞧。

SHA-1 算法將文件中的內(nèi)容通過計(jì)算生成一個(gè) 40 位的 Hash 值陵叽。SHA-1 算法的特點(diǎn)：
由文件內(nèi)容計(jì)算出的 Hash 值；Hash 值相同丛版，文件內(nèi)容相同巩掺。

這里寫圖片描述

使用 SHA-1 的前兩位創(chuàng)建了文件夾，剩下的 38 位為文件名页畦。

這些 Obj 文件胖替，其實(shí)分為四種類型，分別是 Blob豫缨、Tree独令、Commit、Tag好芭。

Blob

用來存放項(xiàng)目文件的內(nèi)容燃箭，但是不包括文件的路徑、名字舍败、格式等其它描述信息招狸。項(xiàng)目的任意文件的任意版本都是以 Blob 的形式存放的。

Tree

Tree 用來表示目錄邻薯。我們知道項(xiàng)目就是一個(gè)目錄裙戏，目錄中有文件、有子目錄厕诡。因此 Tree 中有 Blob累榜、子 Tree，且都是使用 SHA-1值引用的灵嫌。這是與目錄對(duì)應(yīng)的壹罚。從頂層的 Tree 縱覽整個(gè)樹狀的結(jié)構(gòu)，葉子結(jié)點(diǎn)就是 Blob寿羞，表示文件的內(nèi)容猖凛，非葉子結(jié)點(diǎn)表示項(xiàng)目的目錄，頂層的 Tree 對(duì)象就代表了當(dāng)前項(xiàng)目的快照稠曼。

Commit

表示一次提交形病，有 Parent 字段，用來引用父提交霞幅。指向了一個(gè)頂層 Tree漠吻，表示了項(xiàng)目的快照，還有一些其它的信息司恳，比如上一個(gè)提交 Committer途乃、Author、Message 等信息扔傅。

存儲(chǔ)區(qū)

Git中有4個(gè)類型的存儲(chǔ)區(qū)：遠(yuǎn)程倉(cāng)庫耍共，工作區(qū)，本地倉(cāng)庫和緩存區(qū)猎塞。

暫存區(qū)的好處：

1. 為了能夠?qū)崿F(xiàn)部分提交
2. 為了不在工作區(qū)創(chuàng)建狀態(tài)文件试读、會(huì)污染工作區(qū)。
3. 暫存區(qū)記錄文件的修改時(shí)間等信息荠耽，提高文件比較的效率钩骇。
   暫存區(qū)是用來構(gòu)建項(xiàng)目快照的區(qū)域。暫存區(qū)是一個(gè)文件铝量，路徑為： .Git/index

暫存區(qū)的樣子

它是一個(gè)二進(jìn)制文件倘屹，第四列是文件名，第三列是文件的沖突狀態(tài)慢叨，第二列指的是文件的 Blob纽匙。

Commit 命令，將暫存區(qū)的內(nèi)容永久保存到本地倉(cāng)庫拍谐。提交時(shí) Git 會(huì)使用暫存區(qū)的這些信息生成 Tree 對(duì)象烛缔，也就是項(xiàng)目快照，永久保存到數(shù)據(jù)庫中赠尾。

文件的狀態(tài)可以分為兩類力穗。一類是暫存區(qū)與本地倉(cāng)庫比較得出的狀態(tài)，另一類是工作區(qū)與暫存區(qū)比較得出的狀態(tài)气嫁。為什么要分成兩類的愿意也很簡(jiǎn)單当窗，因?yàn)榈谝活悹顟B(tài)在提交時(shí)，會(huì)直接寫入本地倉(cāng)庫寸宵。而第二種則不會(huì)崖面。一個(gè)文件可以同時(shí)擁有兩種狀態(tài)。

分支

分支的目的是讓我們可以并行的進(jìn)行開發(fā)梯影。 .Git/HEAD 文件巫员，它保存了當(dāng)前的分支。

分支簡(jiǎn)要

分支指向了一次提交甲棍，也是 Git 中的分支為什么這么輕量的原因简识。

因?yàn)榉种Ь褪侵赶蛄艘粋€(gè) Commit 的指針，當(dāng)提交新的 Commit，這個(gè)分支的指向只需要跟著更新就可以了七扰，而創(chuàng)建分支僅僅是創(chuàng)建一個(gè)指針奢赂。

Git 必備技能

常見命令速查

常見命令速查表

git add 和 git commit

Add 操作是將修改保存到暫存區(qū)，Commit 是將暫存區(qū)的內(nèi)容永久保存到本地倉(cāng)庫颈走。

每當(dāng)將修改的文件加入到暫存區(qū)膳灶，Git 都會(huì)根據(jù)文件的內(nèi)容計(jì)算出 SHA-1，并將內(nèi)容轉(zhuǎn)換成 Blob立由，寫入數(shù)據(jù)庫轧钓。然后使用 SHA-1 值更新該列表中的文件項(xiàng)。

在暫存區(qū)的文件列表中锐膜，每一個(gè)文件名毕箍，都會(huì)對(duì)應(yīng)一個(gè) SHA-1 值，用于指向文件的實(shí)際內(nèi)容道盏。最后提交的那一刻霉晕，Git 會(huì)將這個(gè)列表信息轉(zhuǎn)換為項(xiàng)目的快照，也就是 Tree 對(duì)象捞奕。寫入數(shù)據(jù)庫牺堰，并再構(gòu)建一個(gè) Commit 對(duì)象，寫入數(shù)據(jù)庫颅围。然后更新分支指向伟葫。

分支合并: merge 和rebase

沖突的狀態(tài)

• DELETED_BY_THEM;
• DELETED_BY_US;
• BOTH_ADDED;
• BOTH_MODIFIED

遇到不可自動(dòng)合并沖突時(shí)，Git 會(huì)將這些狀態(tài)寫入到暫存區(qū)院促。

merge

在解決完沖突后筏养，我們可以將修改的內(nèi)容提交為一個(gè)新的提交。這就是 Merge常拓。
Merge 之后仍可以做出新的提交渐溶。

merge

rebase

Rebase 會(huì)把從 Merge Base 以來的所有提交，以補(bǔ)丁的形式一個(gè)一個(gè)重新達(dá)到目標(biāo)分支上弄抬。這使得目標(biāo)分支合并該分支的時(shí)候會(huì)直接 Fast Forward茎辐，即不會(huì)產(chǎn)生任何沖突。

rebase

Rebase 主要在 .Git/Rebase-Merge 下生成了兩個(gè)文件掂恕，分別為 Git-Rebase-todo 和 Done 文件拖陆，Git-Rebase-todo 存放了 Rebase 將要操作的 Commit。而 Done 存放正在操作或已經(jīng)操作完畢的 Commit懊亡。

Rebase 的一個(gè)缺點(diǎn)依啰，那就是修改了分支的歷史提交。如果已經(jīng)將分支推送到了遠(yuǎn)程倉(cāng)庫店枣，會(huì)導(dǎo)致無法將修改后的分支推送上去速警，必須使用 -f 參數(shù)（Force）強(qiáng)行推送叹誉。

所以使用 Rebase 最好不要在公共分支上進(jìn)行操作。

checkout

經(jīng)常用來切換分支闷旧、或者切換到某一次提交桂对。

Checkout 找到目標(biāo)提交（Commit），目標(biāo)提交中的快照也就是 Tree 對(duì)象就是我們要檢出的項(xiàng)目版本鸠匀。

Checkout 首先根據(jù)Tree生成暫存區(qū)的內(nèi)容，再根據(jù) Tree 與其包含的 Blob 轉(zhuǎn)換成我們的項(xiàng)目文件逾柿。然后修改 HEAD 的指向缀棍，表示切換分支。

Checkout 并沒有修改提交的歷史記錄机错。只是將對(duì)應(yīng)版本的項(xiàng)目?jī)?nèi)容提取出來爬范。

revert

revert 實(shí)現(xiàn)了反向提交，就是舊版本添加了的內(nèi)容弱匪，要在新版本中刪除青瀑；舊版本中刪除了的內(nèi)容，要在新版本中添加萧诫。這在分支已經(jīng)推送到遠(yuǎn)程倉(cāng)庫的情境下非常有用斥难。

Revert 也不會(huì)修改歷史提交記錄，實(shí)際的操作相當(dāng)于是檢出目標(biāo)提交的項(xiàng)目快照到工作區(qū)與暫存區(qū)帘饶，然后用一個(gè)新的提交完成版本的“回退”哑诊。

reset

在當(dāng)前分支進(jìn)行版本的“回退”，Reset 是會(huì)修改歷史提交記錄的及刻。

Reset 常用的選項(xiàng)有三個(gè)镀裤，分別是 —Soft, —Mixed, —Hard。他們的作用域依次增大缴饭。
Soft 會(huì)僅僅修改分支指向暑劝。而不修改工作區(qū)與暫存區(qū)的內(nèi)容，
Mixed 比 Soft 的作用域多了一個(gè) 暫存區(qū)颗搂。實(shí)際上 Mixed 選項(xiàng)與 Soft 只差了一個(gè) Add 操作担猛。
Hard 會(huì)比 Mixed作用域又多了一個(gè)工作區(qū)。

注意：在丟失后可以使用 Git Reset --Hard ORIG_HEAD 立即恢復(fù)丢氢，或者使用 reflog 命令查看之前分支的引用

stash

有時(shí)毁习，在一個(gè)分支上做了一些工作，修改了很多代碼卖丸，而這時(shí)需要切換到另一個(gè)分支干點(diǎn)別的事纺且。但又不想將只做了一半的工作提交。

Stash 將工作區(qū)與暫存區(qū)中的內(nèi)容做一個(gè)提交稍浆，保存起來载碌，然后使用Reset Hard 選項(xiàng)恢復(fù)工作區(qū)與暫存區(qū)內(nèi)容猜嘱。我們可以隨時(shí)使用 Stash Apply 將修改應(yīng)用回來。

Stash 實(shí)現(xiàn)思路將我們的修改提交到本地倉(cāng)庫嫁艇，使用特殊的分支指針（.Git/refs/Stash）引用該提交朗伶，然后在恢復(fù)的時(shí)候，將該提交恢復(fù)即可步咪。

Git 典型實(shí)踐

一個(gè)典型的git 并行開發(fā)的流程模型如下：

git 典型實(shí)踐

主要分支

把origin/master作為主要分支论皆，源碼的HEAD總是表示production-ready(可隨時(shí)部署)狀態(tài)。

master和develop

origin/develop上的代碼是為下一次的代碼發(fā)布準(zhǔn)備的猾漫。每日構(gòu)建也是基于此分支点晴。
當(dāng)develop分支達(dá)到了一個(gè)穩(wěn)定狀態(tài)并準(zhǔn)備發(fā)布時(shí)，所有的改變都要合并到master分支悯周，并標(biāo)上版本號(hào)粒督。

輔助分支

Feature branches

繼承與合并都與develop 分支相關(guān)，用來開發(fā)新特性的(短期禽翼，遠(yuǎn)期都可以)屠橄。

feature和develop

當(dāng)要?jiǎng)?chuàng)建一個(gè)新特性時(shí)，從develop分支上再創(chuàng)建一個(gè) Feature branch闰挡。
$ git checkout -b myfeature develop
合并feature 到develop

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557 (Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop

merge without FF

Release branches

繼承分支: develop
合并分支：develop 和 master
命名規(guī)范：release-*

創(chuàng)建一個(gè)release 分支

Release branch是通過develop分支而創(chuàng)建.

$ git checkout -b release-1.2 develop    
Switched to a new branch "release-1.2"

$ ./bump-version.sh 1.2
Files modified successfully, version bumped to 1.2.

$ git commit -a -m "Bumped version number to 1.2"
[release-1.2 74d9424] Bumped version number to 1.2
1 files changed, 1 insertions(+), 1 deletions(-)

完成一個(gè)release 分支

當(dāng)release branch已經(jīng)準(zhǔn)備就緒锐墙，需要做幾件事。

1. release分支被合并到master分支上(每一個(gè)提交到master上的commit都是一個(gè)新版 本长酗，切記)贮匕。
2. master上的commit都要添加tag，方便將來查看和回滾花枫。
3. release上所做的修改必須合并到develop分支上刻盐，保證bug已被修補(bǔ)。
   前兩個(gè)步驟：

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2

為了把release上的改變保存到develop劳翰，需要合并到develop敦锌。

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)

這個(gè)步驟可能會(huì)導(dǎo)致沖突，如果這樣的話佳簸，解決沖突乙墙，然后再提交。
最后生均，可以刪除release 分支听想。

$ git branch -d release-1.2
Deleted branch release-1.2 (was ff452fe).

Hotfix branches

繼承分支: master
合并分支：develop 和 master
命名規(guī)范：hotfix-*
運(yùn)行過程中發(fā)現(xiàn)了bug，就必須快速解決马胧，這時(shí)就可以創(chuàng)建一個(gè)Hotfix branch汉买，解決完后合并到master分支上。好處是開發(fā)人員可以繼續(xù)工作佩脊，有專人來負(fù)責(zé)搞定這個(gè)bug蛙粘。

創(chuàng)建hotfix分支

$ git checkout -b hotfix-1.2.1 master
Switched to a new branch "hotfix-1.2.1"
$ ./bump-version.sh 1.2.1
Files modified successfully, version bumped to 1.2.1.
$ git commit -a -m "Bumped version number to 1.2.1"
[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
1 files changed, 1 insertions(+), 1 deletions(-)

fix bug, 解決問題

需要一次或幾次commit

$ git commit -m "Fixed severe production problem"
[hotfix-1.2.1 abbe5d6] Fixed severe production problem
5 files changed, 32 insertions(+), 17 deletions(-)

完成Hotfix branch

當(dāng)結(jié)束時(shí)垫卤，bugfix要被合并到master，同時(shí)也要合并到develop出牧，保證下個(gè)版本發(fā)布時(shí)該bug已被修復(fù)穴肘。這跟release branch完成時(shí)一樣。
首先更新master和tag release

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2.1

接下來與develop合并

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)

有一個(gè)例外舔痕，就是當(dāng)一個(gè)release branch存在時(shí)评抚，bugfix要被合并到release而不是develop，因?yàn)閞elease最終會(huì)被合并到develop伯复。

最后移除branch

$ git branch -d hotfix-1.2.1 
Deleted branch hotfix-1.2.1 (was abbe5d6).

總結(jié)

了解Git 在軟件工程及敏捷開發(fā)中的地位慨代，明白git與其他版本控制工具之間的區(qū)別，掌握Git 工作的基本原理和必備操作边翼，復(fù)雜問題可以查找git的相關(guān)命令，應(yīng)用git開發(fā)的流程模型鸣剪，讓Git 成為我們的真正利器组底。

參考資料：
1）http://nvie.com/posts/a-successful-git-branching-model/
2）https://community.qingcloud.com/topic/457/%E6%8A%80%E6%9C%AF%E5%9F%B9%E8%AE%AD-git-%E4%BD%A0%E7%9C%9F%E7%9A%84%E4%BC%9A%E7%94%A8%E4%B9%88/2