git基本概念與原理git
-----------------------------------------------------------------------------------------------------------------------------------------------算法
1、git的安裝與簡單配置json
1、安裝app
apt install -y git-coreide
2、配置git名稱與郵箱工具
git config --global user.name "chenux"spa
git config --global user.email "json_chenux@163.com"3d
git config --global --list 指針
mkdir 目錄 && cd 目錄對象
git init git_repo #git_repo就是倉庫,其目錄下有個.git
3、git設置優先級
git config --system:使對應配置針對系統內全部的用戶有效
git config --global:使對應配置針對當前系統用戶的全部倉庫生效
git config --local:使對應配置只針對當前倉庫有效
local選項設置的優先級最高。
四、倉庫中有文件後,保存庫狀態
在倉庫中執行命令git add . && git commit -m "status01"
給倉庫里加了些文件
五、gitk,圖形化git管理工具,apt install -y gitk
六、此圖狀態爲在4中已經執行過的狀態,此時輸入指令更改文件內容
echo 「aa11a1」 >1.txt \
echo 「b2b2b2」 >> 2.txt \
touch project/pro-2.txt
執行後保存狀態git add. && git commit -m 「status02」,此時再啓動gitk
再次稍做修改後保存一次狀態
2、git對象
一、三種不一樣類型的git對象:
(1)blob:一個blob就是由一個文件轉換而來,blob中只會存儲文件的數據,而不會存儲文件的元數據
(2)tree:一個tree就是有一個目錄轉換而來,tree只會存儲一層目錄信息,它只存儲它的直接文件和直接子目錄的信息,但子目錄中的內容它不會保存
(3)commit:一個commit就是咱們的git commit提交,它指向了一個tree,這個tree保存了某一時刻項目根目錄中的直接文件和直接目錄信息
總而言之,commit指向了tree,tree又指向了本身根下直接文件的blob或者子目錄的tree,子目錄的tree對象指向了子目錄的文件blob和子子目錄的tree,以此類推
二、每一個git對象都有一個惟一的哈希碼(SHA1算法),它是一個40位的16進制數
三、在初始提交後再進行二次提交,若存在
文件f1沒有修改,在此過程後,它的blob哈希沒有改變;
文件f2修改內容,在此過程後文件爲f22,它的blob哈希發生改變;
存放f1和f2的目錄ALPHA,在此過程當中它的tree哈希發生改變,但指向文件f1的blob仍爲a之前的blob
3、git過程
1、目錄結構
能夠看到,倉庫內部除了本身建的文件,還有一個.git目錄,該隱藏目錄在git init時候就已經生成了。
.git目錄:能夠稱之爲版本庫
2、在以前提交的命令中,輸入的是
(1)git add -A:選擇將哪些變化的內容加入到下一次提交中,這些變化內容會被索引或者暫存起來,此時生成文件的blob
(2)git commit -m 「STATUSNAME」:建立commit提交對象,執行命令後git會根據索引/暫存中的結構,建立出對應的tree對象,以後git會建立一個commit對象,將新建立的commit對象指向新建立的tree
(3)這個新的提交產生後,記錄了一個狀態,該提交也會指向前一次的提交,每一個提交都會指向本身的父提交
(4)圖片所示,當修改3.txt後,因爲它是位於上一次狀態中,修改它後會變紅,等git add 3.txt後它的狀態變爲綠色,代表已加入暫存區,作好隨時被提交的準備。4.txt因爲沒有提交,一直是紅色,代表還在工做區
4、git使用
1、git log
顯示全部的git提交,git log --oneline,git log的簡單模式
git cat-file -t 哈希值 查看對象的類型
git cat-file -p 哈希值 查看對象的內容
git rev-parse 13614 經過簡短的哈希值獲取到整個哈希值
2、有以下操做:
git init git_test
cd git_test
echo f1>f1 echo f2>f2
git add .
git commit -m "test01"
echo -e "haha \nheihei" >> f1
git add .
git commit -m "test02"
咱們能夠得知f1產生了變化,若是咱們此時後悔了對f1的操做,執行命令
git log --oneline,先找出對應提交的哈希值,以後git reset --hard 82a23e7
不難發現,雖然說文件恢復到test01的狀態了,可是剛纔test02沒了,如今若是想再次回到test02,該如何操做?
(1)git reflog,輸入後能夠查看以前的test02哈希碼,查詢到後 git reset --hard 哈希碼即可回覆
(2)驗證下,恢復成功
5、git分支
1、在實際環境中,文件的修改是縱容交錯的,因此存在一個問題:文件回退時,是否會影響其它文件?這裏就會引入一個概念:分支
git status,顯示位於主分支master
建立新分支時,默認以當前所在分支爲基礎建立,建立後分支的最新提交與master同樣
(1)建立分支,使用命令git branch分支名
建立後工做區仍處在master分支上,未切換到新建的slave分支。分支的建立,並非說明slave複製了master的分支,而是git只是建立了slave分支指針,指向了master分支對應的最新提交。
邏輯圖以下:
(2)查看分支狀況
git branch、git branch -v、git branch -vv
(3)分支切換
git checkout 分支名
切換後工做區也隨之切換,以後的git add與git commit命令影響切換後的分支
現有操做
切換到個人分支slave後,輸入指令後再提交,此時邏輯圖就變爲了
master上有5個提交,而slave上有6個提交。這時在切回master分支,看下f2文件,內容並無改變。
同理,若此時在master分支修改任何文件,切換到slave分支是看不到master修改的文件,所以在項目時能夠利用分支,負責某個項目a模塊開發的修改文件在分支1,負責b模塊開發的修改文件在分支2,後期項目合併時分支合併便可。具體的合併分支在後面。
6、HEAD
(1)HEAD指向分支
咱們從以前圖中能夠看到,一般狀況下,當處於哪一個分支,HEAD就指向了哪一個分支,因此git是經過HEAD找到本身所處的工做區,在git倉庫下的.git裏,能夠查看HEAD的文件內容,其內部顯示就是目前指向的分支。
(2)HEAD指向提交
特殊狀況下,HEAD能夠指向某個提交,這種狀況稱做頭分離,detached HEAD。
如上圖所示,HEAD沒有指向任何一個分支,而是指向了commit2這個提交。怎樣才能出現這種效果呢?git checkout COMMIT_HASH,如圖示
此時輸入指令,git log --oneline --all --graph
再看下此時的git status
分離頭使用場景:
對該提交點的文件能夠隨便看看,或者作一些實驗性的修改,而且能夠將這些修改作成 提交,提交後會組成匿名分支,若是最後實驗結果不滿意能夠丟棄以前實驗行的提交, 若是實驗結果滿意,就能夠建立一個新的分支,來永久保存這些提交。
示例:首先分離頭已經指向了51fe144,此時輸入瞭如下指令:
sed -i "s/\:/\-/g" 1.txt
git add 1.txt && git commit -m "head_modify_1.txt"
echo headtest2 > 1.txt
git add 1.txt && git commit -m "head_modify_1.txt-02"
修改了兩次,提交了兩次,咱們此時經過圖形工具看一下
gitk --all
注:這裏分離頭選的提交恰好選到master分支的最新提交了,這不能說明分離頭是從master分支分出來的
修改完成後,隨便切換一個分支,會出現提示,好比我在git checkout test後,有圖
若是修改項目後實驗結果滿意,就可使用提示的命令
git branch 分支名 哈希值
輸入git branch headfile 65a96e4後
若是不想保存實驗性修改,切換分支後不用去管提示便可