公眾號(hào)內(nèi)發(fā)送Git獲取Git官方PDF教程

版本控制

版本控制是一種記錄一個(gè)或若干個(gè)文件內(nèi)容變化、以便將來(lái)查閱特定版本修訂情況的系統(tǒng)。

本地版本控制系統(tǒng)

很久以前就開(kāi)發(fā)了許多本地版本控制系統(tǒng)、大多都是采用某種簡(jiǎn)單的數(shù)據(jù)庫(kù)來(lái)記錄文件的歷次更新差異。

其中最流行的一種叫做 RCS、現(xiàn)今許多計(jì)算機(jī)系統(tǒng)上都還看得到他的蹤影。RCS 的工作原理是在硬盤(pán)上保存補(bǔ)丁集、通過(guò)應(yīng)用所有的補(bǔ)丁、可以重新計(jì)算出各個(gè)版本的文件內(nèi)容。

集中化版本控制系統(tǒng)

讓不同系統(tǒng)上的開(kāi)發(fā)者協(xié)同工作、集中化版本控制系統(tǒng)應(yīng)運(yùn)而生。有一個(gè)單一的集中管理的服務(wù)器、保存所有文件的修訂版本、而協(xié)同工作的人們都通過(guò)客戶端連到這臺(tái)服務(wù)器、取出最新的文件或者提交更新。

壞處

• 單點(diǎn)故障
• 無(wú)備份

分布式版本控制系統(tǒng)

在分布式版本控制系統(tǒng)中、客戶端不只是提取最新版本的文件快照、而是把代碼倉(cāng)庫(kù)完整地鏡像下來(lái)、包括完整的歷史記錄。

這么一來(lái)、任何一處協(xié)同工作用的服務(wù)器發(fā)生故障、事后都可以用任何一個(gè)鏡像出來(lái)的本地倉(cāng)庫(kù)恢復(fù)。

Git 簡(jiǎn)史

Git 的設(shè)計(jì)目標(biāo)

• 速度
• 簡(jiǎn)單的設(shè)計(jì)
• 對(duì)非線性開(kāi)發(fā)模式的強(qiáng)力支持(允許成千上萬(wàn)個(gè)并行開(kāi)發(fā)分支)
• 完全分布式
• 有能力高效管理類似 Linux 內(nèi)核一樣的超大規(guī)模項(xiàng)目

直接記錄快照、而非差異比較

Git 喝其他版本控制系統(tǒng)(Subversion) 的主要差別在于 Git 對(duì)待數(shù)據(jù)的方法。

從概念上來(lái)說(shuō)、其他大部分系統(tǒng)以文件變更列表的方式存儲(chǔ)信息、這類系統(tǒng)將它們存儲(chǔ)的信息看作是一組基本文件喝每個(gè)文件隨時(shí)間逐步累積的差異，稱之為基于差異的版本控制

Git 不按照以上方式對(duì)待或保存數(shù)據(jù)、Git 更像是把數(shù)據(jù)看作是對(duì)小型文件系統(tǒng)的一系列快照。在 Git 中、每當(dāng)你提交更新或保存項(xiàng)目狀態(tài)時(shí)、它基本上就會(huì)對(duì)當(dāng)時(shí)的全部文件創(chuàng)建一個(gè)快照并保存這個(gè)快照的索引。為了效率、如果文件沒(méi)有修改、Git 則不再重新存儲(chǔ)文件、只是保留一個(gè)指向之前存儲(chǔ)的文件。Git 對(duì)待數(shù)據(jù)更像是一個(gè)快照流。

Git 幾乎與所有其他版本控制系統(tǒng)的重要區(qū)別就是在于這個(gè)地方。

近乎所有操作都是本地執(zhí)行

在 Git 中絕大多數(shù)操作都只需要訪問(wèn)本地文件和資源、一般不需要來(lái)自網(wǎng)絡(luò)上其他計(jì)算機(jī)的信息。

Git 保證完整性

Git 中所有的數(shù)據(jù)在存儲(chǔ)前都計(jì)算檢驗(yàn)和、然后以檢驗(yàn)和來(lái)飲用。

Git 用以計(jì)算校驗(yàn)和的機(jī)制叫做 SHA-1 散列。是由 40 個(gè)十六進(jìn)制自發(fā)組成的字符串、基于 Git 中文件內(nèi)容或目錄結(jié)構(gòu)計(jì)算出來(lái)的。

Git 一般只添加數(shù)據(jù)

你執(zhí)行的 Git 操作、幾乎只往 Git 數(shù)據(jù)庫(kù)中添加數(shù)據(jù)

三種狀態(tài)

Git 有三種狀態(tài)、你的文件可能處于其中的一種

• 已修改
  表示修改了文件、但沒(méi)保存到數(shù)據(jù)庫(kù)中
• 已暫存
  表示對(duì)一個(gè)已修改文件到當(dāng)前版本做了標(biāo)記、使之在下次提交到快照中
• 已提交
  表示數(shù)據(jù)已經(jīng)安全地保存在本地?cái)?shù)據(jù)庫(kù)中。

這會(huì)讓我們的 Git 項(xiàng)目擁有三個(gè)階段:工作區(qū)、暫存區(qū)、Git 目錄。

工作區(qū)是對(duì)項(xiàng)目的某個(gè)版本獨(dú)立提取出來(lái)的內(nèi)容。這些從 Git 倉(cāng)庫(kù)的壓縮數(shù)據(jù)庫(kù)中提取出來(lái)的文件、放在磁盤(pán)供你使用或修改。

暫存區(qū)是一個(gè)文件、保存了下次將要提交的文件列表信息、一般在 Git 倉(cāng)庫(kù)目錄中。按照 Git 的術(shù)語(yǔ)叫做“索引”。

Git 倉(cāng)庫(kù)目錄是 Git 用來(lái)保存項(xiàng)目的元數(shù)據(jù)和對(duì)象數(shù)據(jù)庫(kù)的地方。這是Git 中最重要的部分。從其他計(jì)算機(jī)克隆倉(cāng)庫(kù)時(shí)、復(fù)制的就是這里的數(shù)據(jù)。

基本的 Git 工作流程如下

• 在工作區(qū)中修改文件
• 將你想要下次提交的更改選擇性地暫存、這樣只會(huì)將更改的部分添加到暫存區(qū)。
• 提交更新、找到暫存區(qū)的文件、將快照永久性存儲(chǔ)到 Git 目錄。

Git 初次接觸

查看版本&查看配置

git --version
git config --list
// 查看單獨(dú)某項(xiàng)配置
git config user.name

配置

git config --global user.name "coderLi"
git config --global user.email "coderLi@xxx.com"

如果使用了 --global 選項(xiàng)、那么該命令只需要運(yùn)行一次、因?yàn)橹鬅o(wú)論你在該系統(tǒng)上做任何事情、Git 都會(huì)使用那些信息。

由于 Git 會(huì)從多個(gè)文件中讀取同一配置的變量的不同值?？梢酝ㄟ^(guò)查詢 Git 中該變量的原始值、它會(huì)告訴你哪一個(gè)配置文件最后設(shè)置了該值

git config --show-origin user.name
file:/Users/coderLi/.gitconfig coderLi

獲取幫助

git help <verb>
git <verb>--help
man git-<verb>
git add -h

Git 基礎(chǔ)

• 配置并初始化一個(gè)倉(cāng)庫(kù)
• 開(kāi)始或停止跟蹤文件
• 暫存或提交更改

獲取倉(cāng)庫(kù)

獲取 Git 倉(cāng)庫(kù)通常有兩種方式

• 將尚未進(jìn)行版本控制的本地目錄轉(zhuǎn)為 Git 倉(cāng)庫(kù)
• 從其他服務(wù)器克隆一個(gè)已存在的 Git 倉(cāng)庫(kù)

初始化倉(cāng)庫(kù)

cd /Users/user/my-project
git init

該命令創(chuàng)建一個(gè)名為 .git 的字幕了、這個(gè)子目錄有你初始化 Git 倉(cāng)庫(kù)中所有的必須文件、這些文件是 Git 的倉(cāng)庫(kù)骨干。

如果該文件夾下有問(wèn)價(jià)需要進(jìn)行版本控制、你應(yīng)該開(kāi)始追蹤這些文件并進(jìn)行初始提交。

可以通過(guò) git add 命令來(lái)制定所需的文件進(jìn)行追蹤、然后執(zhí)行 git commit

git add *.java
git add readme.md
git commit -m 'initial project version'

克隆現(xiàn)有的倉(cāng)庫(kù)

這時(shí)就要使用 Git clone 命令、如果你對(duì)其他 VCS很熟悉、請(qǐng)留意一下你所使用的命令是 “clone” 而不是 “checkout” 。這是 Git 區(qū)別于其他吧版本控制系統(tǒng)的一個(gè)重要特性、Git 克隆的是 Git倉(cāng)庫(kù)服務(wù)器上的幾乎所有數(shù)據(jù)、而不是僅僅復(fù)制完成你的工作所需要的文件。當(dāng)執(zhí)行 git clone 命令時(shí)、默認(rèn)配置下原創(chuàng) Git 倉(cāng)庫(kù)中的每一個(gè)文件的每一個(gè)版本都將被拉取下來(lái)。事實(shí)上、如果你的服務(wù)器磁盤(pán)壞掉了、你通?？梢允褂萌魏我粋€(gè)克隆下來(lái)的用戶端重建服務(wù)器上的倉(cāng)庫(kù)

# git clone <url>
git clone https://github.com/libgit2/libgit2

會(huì)在當(dāng)前目錄下創(chuàng)建一個(gè)名為 libgit2 的目錄、并在這個(gè)目錄下初始化一個(gè).git 文件夾、從遠(yuǎn)程倉(cāng)庫(kù)拉取下所有數(shù)據(jù)放入.git 文佳佳、然后從中讀取最新版本的文件拷貝。如果你進(jìn)入到新建的這個(gè)libgit2 文件夾中、你會(huì)發(fā)現(xiàn)所有的項(xiàng)目文件已經(jīng)在里面了、準(zhǔn)備就緒等后續(xù)開(kāi)發(fā)和使用。

如果你想自定義本地倉(cāng)庫(kù)等名字、可以通過(guò)額外參數(shù)指定

git clone https://github.com/libgit2/libgit2 mylibgit

本地倉(cāng)庫(kù)名就變?yōu)榱?mylibgit

記錄每次更新到倉(cāng)庫(kù)

工作目錄下的每個(gè)文件都不外乎這兩種狀態(tài)：

• 已跟蹤、是指那些被納入了版本控制的文件、在上一次快照中有它們的記錄、在工作一段時(shí)間之后、它們的狀態(tài)可能是未修改、已修改或已經(jīng)放入暫存區(qū)。簡(jiǎn)而言之、已跟蹤的文件就是 GIt 已經(jīng)知道的文件
• 工作目錄中除已跟蹤文件外其他的文件都屬于未跟蹤文件、它們既不存在上一次的快照中、也米有被放入暫存區(qū)。初次克隆某個(gè)倉(cāng)庫(kù)時(shí)、工作目錄中的所有文件都屬于已跟蹤文件、并處于未修改狀態(tài)

檢測(cè)當(dāng)前文件狀態(tài)

git status 命令產(chǎn)看哪些文件處于什么狀態(tài)

跟蹤新文件

git add README

使用 git add 開(kāi)始跟蹤一個(gè)文件、并將其放入到暫存區(qū)。如果此時(shí)提交、那么該文件在你運(yùn)行 git add 時(shí)的版本將被留存在后續(xù)的歷史記錄中。git add 命令使用文件或目錄的路徑作為參數(shù)、如果參數(shù)時(shí)目錄的路徑、該命令將遞歸地跟蹤該目錄下的所有文件

暫存已修改的文件

git add 是一個(gè)多功能命令、可以用它來(lái)跟蹤新文件、或者把已跟蹤的文件放入暫存區(qū)、還能用于合并時(shí)把有沖突的文件標(biāo)為已解決狀態(tài)。

這個(gè)命令可以理解為：精確地將內(nèi)容添加到下一次提交中。

狀態(tài)概覽

git status 命令輸出十分詳細(xì)、但其用于有些繁瑣、使用 git status -s 簡(jiǎn)化輸出方式

忽略文件

一般我們總有一些文件無(wú)需納入 Git 的管理、也不希望它們出現(xiàn)在未跟蹤文件列表中。在這種情況下、我們可以創(chuàng)建一個(gè)名為.gitignore的文件、列出要忽略的文件的模式。

*.[oa]
*~

第一行告訴 Git 忽略所有以.o或.a 結(jié)尾的文件。

第二行告訴我們忽略所有名字以~結(jié)尾的文件。

查看已暫存和未暫存的修改

git diff 比較的是工作目錄中當(dāng)前文件和暫存區(qū)快照之間的差異、也就是修改之后還沒(méi)暫存起來(lái)的變化內(nèi)容。

若要查看已暫存的將要添加都下次提交里的內(nèi)容、可以使用 git diff --staged 命令、git diff --cached

需要注意的是、git diff 本身只現(xiàn)實(shí)尚未暫存的改動(dòng)、而不是自上次提交以來(lái)所做的所有改動(dòng)。所以如果你一下子暫存了所有更新過(guò)的文件、運(yùn)行 git diff 后卻什么也沒(méi)有、就是這個(gè)原因。

提交更新

現(xiàn)在暫存區(qū)已經(jīng)準(zhǔn)備就緒、可以提交了。

git commit -m 'information'

跳過(guò)使用暫存區(qū)

盡管使用暫存區(qū)域的方式可以精心準(zhǔn)備要提交的細(xì)節(jié)、但有時(shí)候這么做顯得繁瑣、Git 提供了一個(gè)跳過(guò)使用暫存區(qū)域的方式、只要在提交時(shí)、在 git commit 加上 -a 選項(xiàng)、Git 就會(huì)自動(dòng)把所有已經(jīng)追蹤過(guò)的文件暫存起來(lái)一并提交、從而逃過(guò) git add 步驟。

移除文件

從 Git 中移除某個(gè)文件、就必須從暫存區(qū)中移除、然后提交。git rm 命令可以完成此項(xiàng)工作、并連帶從工作目錄中刪除置頂文件、這樣以后就不會(huì)出現(xiàn)在未跟蹤文件清單中了。

$ls 
DijkstraJourneyGeneratorTest.java cassandra    redis
Generic.java    ehcache     repository
$git rm Generic.java
$git status
Changes to be committed:(use "git restore --staged <file>..." to unstage)deleted:    Generic.java

如果只是單純的在工作目錄中刪除文件、而沒(méi)有對(duì)齊進(jìn)行提交、是不能在 Git 中刪除該文件的

$ls
DijkstraJourneyGeneratorTest.java cassandra    redis
Generic.java    ehcache     repository
$rm Generic.java
$git status
Changes not staged for commit:(use "git add/rm <file>..." to update what will be committed)(use "git restore <file>..." to discard changes in working directory)deleted:    Generic.java

這個(gè)時(shí)候你還是要執(zhí)行 git rm Generic.java 來(lái)將這個(gè)刪除添加到暫存區(qū)

如果要?jiǎng)h除已經(jīng)放到暫存區(qū)的文件、則必須使用強(qiáng)制刪除項(xiàng) -f

$ vi Generic.java 
$ git add Generic.java 

第一步我們修改了 Generic.java 這個(gè)文件、然后將其放入到暫存區(qū)、但是這個(gè)時(shí)候我們想刪除這個(gè) Generic.java 文件并且想將此次提交到暫存區(qū)的版本也刪除掉

$git rm -f Generic.java
$git status
Changes to be committed:(use "git restore --staged <file>..." to unstage)deleted:    Generic.java

這個(gè)時(shí)候、我們工作目錄下也刪除了 Generic.java 的問(wèn)價(jià)、并且剛剛修改Generic.java的版本也在暫存區(qū)中刪除了。

移動(dòng)文件

git mv file_from file_to$git mv Generic.java Generic01.java
$git status
Changes to be committed:(use "git restore --staged <file>..." to unstage)renamed:    Generic.java -> Generic01.java

其實(shí)運(yùn)行 git mv就相當(dāng)于運(yùn)行了下面三條命了

$mv Generic.java Generic01.java
$git rm Generic.java
$git add Generic01.java

查看提交歷史

git log 在不傳入任何參數(shù)的默認(rèn)情況下、git log 會(huì)按時(shí)間先后順序列出所有的提交、最精的更新排在最上面。

git log 有很多選項(xiàng)幫助你搜尋你所要查找的提交、其中最有用的就是 -p/-patch 選項(xiàng)、它會(huì)顯示每次提交所引入的差異(按補(bǔ)丁格式顯示)。

也可以限制顯示日志的條目數(shù)量、例如使用 -2 顯示最近的兩次提交。

撤銷操作

在任何一個(gè)階段、你都有可能想要撤銷某些操作。有時(shí)候我們提交完了才發(fā)現(xiàn)漏掉了幾個(gè)文件沒(méi)有添加、或者提交信息寫(xiě)錯(cuò)了、此時(shí)、可以使用帶有 --amend 選項(xiàng)來(lái)提交命令重新提交

git commit -m 'renew' -amend

這個(gè)命令會(huì)將暫存區(qū)中的文件提交、如果自上次提交以來(lái)你還未做任何修改、那么快照將會(huì)保持不變、而你修改的只是提交信息。

最終只會(huì)有一個(gè)提交、而第二次提交將會(huì)代替第一次提交的結(jié)果。 第一次的提交就像從未存在過(guò)一、它并不會(huì)出現(xiàn)在倉(cāng)庫(kù)的歷史中。

取消暫存的文件

git add -A
git status
Changes to be committed:(use "git restore --staged <file>..." to unstage)..........

我們可以使用該命令將暫存區(qū)的版本刪除掉

git restore --staged xxx.java

撤銷對(duì)文件的修改

同樣也是使用 git restore xxx.java

撤銷commit

當(dāng)我們想撤回一個(gè)本地的 commit 的時(shí)候、怎么辦

可以使用 git reset HEAD^ 這樣就可以成功撤銷你的 commit

head^ 等同于 head~1 表示git 倉(cāng)庫(kù)的上一個(gè)版本
如果你提交了兩個(gè) commit 都想撤回、可以使用 head~2 表示

還可以在這個(gè)命令中加上選項(xiàng)參數(shù)

• --mixed 不刪除工作空間改動(dòng)代碼、撤銷 commit 并且撤銷 git add 操作、默認(rèn)使用就是這個(gè)參數(shù)
• --soft 不刪除工作空間改動(dòng)代碼、撤銷 commit、但是不撤銷 git add
• --hard 刪除工作空間改動(dòng)代碼、撤銷 commit、撤銷 git add 相當(dāng)于回到上一次commit狀態(tài)

https://blog.csdn.net/w958796636/article/details/53611133

git checkout

git checkout 最常見(jiàn)的用法莫過(guò)于對(duì)工作分支的切換了

git checkout branchName
# 該命令會(huì)將當(dāng)前工作分支切換到 branchName中

也可以通過(guò)下面的命令在新分支創(chuàng)建的同時(shí)切換分支

git checkout -b newBranch

該命令相當(dāng)于

git branch newBranch
git checkout newBranch

該命令完整語(yǔ)法為

git checkout -b new-branch-name copy-branch

該命令的主要關(guān)聯(lián)目標(biāo)其實(shí)是.git文件夾下的HEAD文件、HEAD文件記錄了當(dāng)前HEAD的信息

擴(kuò)展用法

git checkout yyy.java
git checkout origin/master xxx.java

該命令主要用于檢出某一個(gè)指定文件。如果不填寫(xiě) commit id、則默認(rèn)從暫存區(qū)檢出該文件、如果暫存區(qū)為空、則該文件會(huì)回滾到最近一次提交狀態(tài)

也可以指定從遠(yuǎn)程分支中checkout某個(gè)文件

https://www.jianshu.com/p/cad4d2ec4da5

遠(yuǎn)程倉(cāng)庫(kù)的使用

查看你已經(jīng)配置的遠(yuǎn)程倉(cāng)庫(kù)服務(wù)器、可以使用 git remote 命令、它會(huì)列出你指定的每一個(gè)遠(yuǎn)程服務(wù)器的簡(jiǎn)寫(xiě)。如果你已經(jīng)克隆了自己的倉(cāng)庫(kù)、那么至少應(yīng)該能看到origin、這是 Git 給你克隆倉(cāng)庫(kù)服務(wù)器的默認(rèn)名字

git remote
# 顯示對(duì)應(yīng)的 url
git remote -v

添加遠(yuǎn)程倉(cāng)庫(kù)可以使用 git remote add

從遠(yuǎn)程倉(cāng)庫(kù)中抓取和拉取

• git fetch 命令只會(huì)將數(shù)據(jù)下載到你的本地倉(cāng)庫(kù)--它并不會(huì)自動(dòng)合并或修改你當(dāng)前的工作空間、當(dāng)準(zhǔn)備好時(shí)你必須手動(dòng)將其合并
• git pull 通常會(huì)從最初克隆的服務(wù)器上抓取數(shù)據(jù)并自動(dòng)嘗試合并到當(dāng)前所在的分支

推送到遠(yuǎn)程分支

git push origin master

可以使用命令查看遠(yuǎn)程倉(cāng)庫(kù)的情況

git remote show orign

打標(biāo)簽

Git 可以給倉(cāng)庫(kù)歷史中的某個(gè)提交打上標(biāo)簽、以示重視。Git 支持兩種標(biāo)簽、一種是輕量級(jí)標(biāo)簽、一種是附注標(biāo)簽。

輕量級(jí)標(biāo)簽很想一個(gè)不會(huì)改變的分支--它只是某一個(gè)特定提交的飲用

而附注標(biāo)簽是存儲(chǔ)在 Git 參考中的一個(gè)完整對(duì)象、它是可以被檢驗(yàn)的、其中包含打標(biāo)簽的行嗎、電子郵件地址、日期時(shí)間、還有標(biāo)簽信息。

通常會(huì)建議創(chuàng)建附注標(biāo)簽。

• 列出標(biāo)簽 git tag -l
• 創(chuàng)建標(biāo)簽 git tag tagName / git tag -a tagName -m 'message about tag'。加上 -a 創(chuàng)建的是附注標(biāo)簽、不加上的是一個(gè)輕量級(jí)標(biāo)簽
• 展示某個(gè)標(biāo)簽內(nèi)容 git show tagName
• 刪除標(biāo)簽 git tag -d tagName

默認(rèn)情況下、git push 命令并不會(huì)傳送標(biāo)簽到遠(yuǎn)程倉(cāng)庫(kù)服務(wù)器上。在創(chuàng)建萬(wàn)標(biāo)簽后你必須顯示地將標(biāo)簽推送到服務(wù)器上、這個(gè)過(guò)程就行你共享遠(yuǎn)程分支一樣。git push orign tagName

Git 分支

幾乎所有到版本系統(tǒng)都以某種形式支持分支、使用分支意味著你可以把你的工作從開(kāi)發(fā)主線上分離出來(lái)、一面影響開(kāi)發(fā)主線。在很多版本控制系統(tǒng)中、這是一個(gè)略微低效的過(guò)程、通常需要完成創(chuàng)建一個(gè)源代碼的副本。對(duì)于大項(xiàng)目來(lái)說(shuō)、這樣的過(guò)程會(huì)耗費(fèi)很多時(shí)間。

Git 處理分支的方式可謂是難以置信的輕量、創(chuàng)建分支這一操作幾乎能在瞬間完成、并且在不同分支之間的切換也是一樣便捷。與其他版本控制系統(tǒng)不同、Git 鼓勵(lì)在工作流中頻繁地使用分支與合并。

Git 保持的不是文件的變化或者差異、而是一系列不同時(shí)刻的快照。在進(jìn)行提交操作時(shí)、Git 會(huì)保存一個(gè)提交對(duì)象。

在進(jìn)行提交操作時(shí)、Git 會(huì)保存一個(gè)提交對(duì)象。知道了Git 保存數(shù)據(jù)的方式、我們可以自然的想到--該提交對(duì)象會(huì)包含一個(gè)只想暫存內(nèi)容快照的指針，還包含作者的姓名和郵箱、提交輸入的信息以及指向它的父對(duì)象的指針。首次提交對(duì)象沒(méi)有父對(duì)象、普通提交操作產(chǎn)生的提交對(duì)象有一個(gè)父對(duì)象、而由多個(gè)分支合并產(chǎn)生的提交對(duì)象有多個(gè)父對(duì)象。

我們假設(shè)現(xiàn)在的工作目錄中有三個(gè)要被暫存和提交的文件。暫存操作會(huì)為每一個(gè)文件計(jì)算校驗(yàn)和、然后會(huì)把當(dāng)前版本的文件快照保存到暫存區(qū)中

git add README test.rb LICENSE
git commit -m 'initial commit of my project'

進(jìn)行提交時(shí)、Git 會(huì)先計(jì)算每個(gè)子目錄的檢驗(yàn)和、然后在 Git 倉(cāng)庫(kù)中將這些檢驗(yàn)和保存為樹(shù)對(duì)象。隨后 Git 會(huì)創(chuàng)建一個(gè)提交對(duì)象、它除了包含上面提到的信息外、還包含了指向這個(gè)樹(shù)對(duì)象的指針、如此以來(lái)、Git 就可以在需要的時(shí)候重現(xiàn)此次保存的快照。

現(xiàn)在 Git倉(cāng)庫(kù)中包含五個(gè)對(duì)象、三個(gè)blob 對(duì)象(保存著文件快照)、一個(gè)樹(shù)對(duì)象(記錄著目錄結(jié)構(gòu)和blob對(duì)象索引)以及一個(gè)提交對(duì)象(包含指向樹(shù)對(duì)象的指針以及所有提交信息)

做些修改后再次提交、那么這次產(chǎn)生的提交對(duì)象會(huì)包含一個(gè)指向上次提交對(duì)象的指針

Git 的分支、其實(shí)本質(zhì)上僅僅是一個(gè)指向提交對(duì)象的可變指針。Git 的默認(rèn)分支名字是 master。在多次提交操作之后、你其實(shí)已經(jīng)有一個(gè)指向最后那個(gè)提交對(duì)象的 master 分支。master 分支會(huì)在每次提交時(shí)自動(dòng)向前移動(dòng)。

分支創(chuàng)建

git branch testing

Git 創(chuàng)建分支只是為你創(chuàng)建了一個(gè)可移動(dòng)的新指針、它會(huì)在你當(dāng)前所在的提交對(duì)象上創(chuàng)建一個(gè)指針

那么 Git 是如何知道當(dāng)前在哪個(gè)分支上的、它使用一個(gè)名為 HEAD 的特殊指針。在 Git 中、它是一個(gè)指針、指向當(dāng)前所在的本地分支。Git Branch 命令僅僅創(chuàng)建一個(gè)新分支、并不會(huì)自動(dòng)切換到新分支中去

可以使用 git log --decorate 查看各個(gè)分支當(dāng)前所指的對(duì)象

分支切換

切換到一個(gè)已存在的分支、可以使用 git checkout 命令

git checkout other-branch

這樣 HEAD 就指向了 other-branch 分支了

如果我們這個(gè)時(shí)候修改某個(gè)文件、再次 commit

testing 分支向前移動(dòng)了、但是 master 分支卻沒(méi)有、它仍然指向運(yùn)行 git checkout 時(shí)所指的對(duì)象。

然后我們現(xiàn)在切換回 master 分支

git checkout master

這個(gè)命令做了兩件事、第一件事就是使 HEAD 指回 master 分支、而是將工作目錄恢復(fù)成 master 分支所指向的快照內(nèi)容。也就是說(shuō)、你現(xiàn)在所做修改的話、項(xiàng)目將回到一個(gè)較舊的版本。本質(zhì)上來(lái)說(shuō)、這就是忽略 testing 粉做所做的修改。

這個(gè)時(shí)候我們?cè)?master 分支上進(jìn)行一次 commit

分支的新建與合并

新建分支

git checkout -b iss53
Switched to a new branch "iss53"

$ vim index.html
$ git commit -a -m 'added a new footer [issue 53]'

線上出現(xiàn)問(wèn)題、需要緊急修復(fù)

git checkout master
git checkout -b hotfix
............
git commit -m 'hotfix information'

將hotfix 合并到master 分支然后緊急部署上線

$git checkout master
$git merge hotfix
Updating f42c576..3a0874c Fast-forward
index.html | 2 ++
1 file changed, 2 insertions(+)

在合并到時(shí)候、可以看到 “fast forward” 快進(jìn) 這個(gè)詞。由于想要合并到分支 hotfix 所指向的提交 C4 是 C2 的直接后繼、因此 Git 會(huì)直接將指針向前移動(dòng)。換句話說(shuō)、當(dāng)你試圖合并兩個(gè)分支時(shí)、如果順著一個(gè)分支走下去能夠到達(dá)另一個(gè)分支、那么 Git 合并它時(shí)、只會(huì)簡(jiǎn)單講指針向前推進(jìn)。這種情況下的合并沒(méi)有需要解決的分歧、叫做快進(jìn)。

部署緊急修復(fù)到生產(chǎn)、然后就可以刪除 hotfix 分支了、然后切換到 iss53 中繼續(xù)工作

git branch -d hotfix
git checkout iss53
.......
git commit -m 'iss53 some commit information'

現(xiàn)在打算將 iss53 合并到 master 分支中、

git checkout master
git merge iss53

這和之前合并 hotfix 分支的時(shí)候不一樣、在這種情況下、iss53的開(kāi)發(fā)歷史從一個(gè)更早的地方開(kāi)叉出來(lái)、因?yàn)閙aster 分支所在提交并不是 iss53 所在提交的直接祖先、Git 不得不做一些額外工作。

Git 使用兩個(gè)分支的末端所指的快照(C4 和 C5) 以及這兩個(gè)分支的公共祖先(C2)、做一個(gè)簡(jiǎn)單的三方合并。

和之前分支指針向前推薦所不同的是、Git將此次三方合并的結(jié)果做了一個(gè)新的快照并自動(dòng)創(chuàng)建一個(gè)新的提交指向它、這個(gè)被稱作是合并提交、它的特別之處在于它不止有一個(gè)父提交。

遇到?jīng)_突時(shí)的分支合并

有時(shí)候合并并不會(huì)那么順利。如果你在兩個(gè)不同的分支中、對(duì)同一文件的同一個(gè)部分進(jìn)行了不同的修改、Git 就無(wú)法干凈的將它們合并。Git 會(huì)暫停下來(lái)、等待你解決合并產(chǎn)生的重提、在合并沖突的任意時(shí)刻使用 git status 命令來(lái)查看那些因合并沖突而處于未合并狀態(tài)的文件。出現(xiàn)沖突的文件會(huì)包含一些特殊的區(qū)段、看上去如下

這表示 HEAD 所指示的版本在這個(gè)區(qū)段的上半部分、而 iss53 分支所指示的版本在 ======= 的下半部分。為了解決沖突、你必須選擇使用 ======= 分割的兩部分中的一個(gè)、或者你可以自行合并這些內(nèi)容。

 <div id="footer">
please contact us at email.support@github.com </div>

上述的沖突解決方案保留了其中一個(gè)分支的修改、并將<<<<<< 和 =======和>>>>>>這些刪除掉。

在你解決了所有文件里的沖突之后、對(duì)每個(gè)文件使用 git add 命令來(lái)將其表尾沖突已解決。一旦暫存這些原本有沖突的文件、Git 就會(huì)將它們標(biāo)為沖突已解決。

分支管理

git branch 命令不僅可以創(chuàng)建和刪除分支。如果不加任何參數(shù)運(yùn)行它、則會(huì)得到當(dāng)前所有分支的一個(gè)列表。

--merged 與 --no-merged 這兩個(gè)有用的選項(xiàng)可以過(guò)濾這個(gè)列表中已經(jīng)合并或尚未合并到當(dāng)前分支的分支。

拉取

當(dāng) git fetch 命令從服務(wù)器上抓取本地沒(méi)有到數(shù)據(jù)時(shí)、它并不會(huì)修改工作目錄中的內(nèi)容。它只會(huì)獲取數(shù)據(jù)然后讓你合并。然后有一個(gè)命令叫做 git pull 在大多數(shù)情況下它的含義是一個(gè) git fetch 緊接著一個(gè) git merge命令。git pull 會(huì)查找當(dāng)前所在分支所跟蹤的服務(wù)器的分支、然后從服務(wù)器抓取數(shù)據(jù)然后嘗試合并入那個(gè)遠(yuǎn)程分支。

刪除遠(yuǎn)程分支

git push origin --delete serverBranchName

rebase

在 Git 中整合來(lái)自不同分支的修改主要有兩種方法：merge 和 rebase。

如果使用 merge 進(jìn)行整合分支

如果使用rebase 則是提取C4中引入的補(bǔ)丁和修改、然后在 C3 的基礎(chǔ)上應(yīng)用一次。你可以使用rebase 命令將某個(gè)分支的所有修改都遷移到另一分支上。

在這個(gè)例子中、可以將 experiment分支 rebase 到 master 分支上

git checkout experiment
git rebase master

它的原理是首先找到這兩個(gè)分支的最近共同祖先C2、然后對(duì)比當(dāng)前分支相對(duì)于祖先的歷次提交、提取相應(yīng)的修改保存為臨時(shí)文件、然后將當(dāng)前分支指向目標(biāo)基底C3、最后將之前的臨時(shí)文件的修改依次應(yīng)用。

最后將 master merge 到 experiment

要用 rebase 需要遵循這么一條準(zhǔn)則

如果提交存在于你的倉(cāng)庫(kù)之外、而別人可能基于這些提交進(jìn)行開(kāi)發(fā)、那么不要進(jìn)行rebase

rebase 操作的實(shí)際是丟棄一些現(xiàn)有的提交、然后相應(yīng)地新建一些內(nèi)容一樣但實(shí)際上不同的提交。

總的原則就是、只對(duì)尚未推送或分享給別人的本地修改執(zhí)行 rebase 操作清理歷史、從不對(duì)已推送到別處的提交執(zhí)行rebase操作。