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 是个什么作用。