Git提交
- 1.識別不同的提交
- 1.1絕對提交名-ID
- 1.2 引用和符號引用--HEAD
- 2.查看提交的歷史記錄-git log
- 3.提交圖-gitk
- 4.提交的范圍
- 4.1 X..Y
- 4.1 X...Y
- 5.查找bad 提交--git bisect
- 6.查看代碼修改者-git blame
命令概覽
git commit -a # 直接提交修改和刪除文件有效
加了-a,在 commit 的時候,能幫你省一步 git add ,但也只是對修改和刪除文件有效, 新文件還是要 git add,不然就是 untracked 狀態。
1.識別不同的提交
在開發的過程中,能正確的區分不同的提交是十分必要的。例如,在新建分支時,必須要選擇某個提交來作為分支點;當比較代碼差異時,必須指明兩個提交。在git中可以通過顯示引用或者隱式引用來指代每一個提交。
當你要與同事討論相同數據的提交時,最好使用兩個版本中的相同提交名。
1.1絕對提交名-ID
40位的十六進制數字
git log -l --pretty=oneline 1fbb58
1.2 引用和符號引用–HEAD
引用(ref)指向Git對象庫中的對象。一般用引用指向提交對象。分支名稱,標簽名都是引用。
.git 目錄中有三種的命名空間表示不同的引用
chenyingying01@cyy hello % ls -hl .git/refs
total 0
drwxr-xr-x 2 chenyingying01 staff 64B 8 28 11:28 heads # 本地分支
drwxr-xr-x 3 chenyingying01 staff 96B 8 29 12:48 tags # 標簽
drwxr-xr-x 3 chenyingying01 staff 96B 8 29 12:48 remotes # 遠程跟蹤分支
例如本地一個叫dev的分支是ref/heads/dev的縮寫。
Git 自動維護幾個用于特定目的的特殊符號引用:
- HEAD–始終指向當前分支的最近提交
- ORIG_HEAD–合并,復位操作會記錄一下原來的HEAD,用于恢復或者回滾到之前的狀態
- FETCH_HEAD–git fetch 命令將所有抓取分支的頭記錄到.git/FETCH_HEAD中,僅在剛剛抓去操作之后才有效。
- MERGE_HEAD–當一個合并操作正在進行時,其他分支的頭暫時記錄在MERGE_HEAD中。
符號引用–用一些特殊的符號集合來指代引用
^ 某一提交的上一個提交
~2 某提交的上兩個提交
當一個提交具有多個父提交時,^表示不同的父提交
2.查看提交的歷史記錄-git log
git log HEAD # 輸出每個可從HEAD找到歷史提交日志消息
git log commit # 輸出從該提交開始回溯的歷史提交日志消息
git log commit1 commmit2 # 顯示commmit1-commit2之間提交
git log -n -p commitID # -n限制回溯的條數,-p顯示該文件修改的地方(打的布丁或者變更)
git log 提供的的可選擇參數
git log --pretty=short # 限制顯示信息的數量, oneline, short, full
git log --abbrev-commit # 顯示散列值的縮寫
git log -Sstring # 根據給定的string,沿著文件的差異歷史搜索。(找出與string相關的歷史變化?太強大了。)
3.提交圖-gitk
提交的時間戳是不可信的。
使用gitk 來查看提交圖–需要配置一下gitk工具
4.提交的范圍
4.1 X…Y
許多git命令 都允許 指定提交范圍,例如 git log
git log X..Y # 列出Y提交所有可達的提交,排除掉其中可達X的提交。
git log ^X Y # 等價命令
難點:辨別X和Y的可達提交,或者從顯示結果中推出提交之間的邏輯關系
用處:如果你某個分支來自另一個版本庫,那么^可以用來定位那些在你版本庫而不在別人版庫里的提交。
4.1 X…Y
對稱差-求 XY各自擁有的提交的并集。
5.查找bad 提交–git bisect
有一天早上,你突然發現版本庫出問題了,但是前天明明還是好的。這就需要定位到那個罪魁禍首(bad)提交。
git bisect : 指定提交范圍,在該范圍內進行二分查找,直至你定位到導致版本庫出問題的提交。
啟動二分搜索后,Git使用一個分離(detached) HEAD 來管理版本庫的當前檢出版本,支持定位操作。定位完成后需要將分支切換為原來的分支。
**關鍵點:**每次以reset工作區為搜索范圍的中點提交,確定該提交是的好壞屬性(在另一個終端中確定提交的好壞)
在二分搜索的過程中,Git維護一個日志,來記錄搜索的過程。(如果找不到自己的方向了)可以使用git bisect replay 命令使用日志文件作為輸入。
git bisect strat # 啟動二分搜索
git bisect bad # 指定壞提交,省略就是HEAD
git bisect good commitID/v2.6.27 # 指定好提交
# 輸出中點版本,你確定改版本是好壞
git bisect good # HEAD應該是移動到了中點提交,省略了HEAD(個人猜想)假定這個中點是好的
git bisect bad # 假定這個中點是壞的的
....
git bisect reset # 完成搜索后,換回原來的分支
6.查看代碼修改者-git blame
查看文件的每一行 最后是xxx(誰) 在哪次提交中 修改的。
git blame -L 35, init/xxx.c # -L 是個什么作用。