Git(7)-Git commit

命令概览

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 自动维护几个用于特定目的的特殊符号引用：

1. HEAD–始终指向当前分支的最近提交
2. ORIG_HEAD–合并，复位操作会记录一下原来的HEAD，用于恢复或者回滚到之前的状态
3. FETCH_HEAD–git fetch 命令将所有抓取分支的头记录到.git/FETCH_HEAD中，仅在刚刚抓去操作之后才有效。
4. 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 是个什么作用。