commit节点号 git_git中各个commit节点的查询 回溯 与 合并:git rebase与git reset | 学步园...

概述：在利用git进行管理的时候，除了对不同的分支进行merge以外，往往需要对同一个一个分支上的不同commit进行合并或者撤销；或者对不同分支上的多次提交进行合并，形成一个线性的提交历史，等等：这些都要用到git rebase，git reset和git log这三个命令。

1.commit的信息查询——git log

如果我们在同一个分支上进行了多次commit，要想查找每次commit的信息，需要使用git log命令

$git log

commit daffbd39053d4f2e78f88955c2158de6092258a2

Author: hyk

Date:   Wed May 29 22:45:23 2013 +0800

this is a test

commit 38d58591fc0607bfd262fc8d363e52047fcf0e9c

Author: Eryu Guan

Date:   Wed May 29 08:12:44 2013 -0500

xfstests: fix typo in check

There is no $testname, should be $test_name

Signed-off-by: Eryu Guan

Reviewed-by: Rich Johnston

Signed-off-by: Rich Johnston

如上，commit按照时间的远近排列，最新的修改在最前面

使用以下两个命令，可以查看commit的详细信息

$git log --graph

$git log -p

2.commit点的撤销与分解——git reset

2.1命令概述：

1)命令解释：

git reset:Reset current HEAD to the specified state

2)命令模式：

git reset [-q] [] [--] ...

git reset (--patch | -p) [] [--] [...]

git reset (--soft | --mixed | --hard | --merge | --keep) [-q] []

3)模式详解:

上面的第一种和第二种形式中，直接从commit中copy条目到index，从而实现index的回滾。第三种形式中，将当前分支的HEAD设置到commit，同时可以选择是否对working tree和stage作相应匹配的更改。其中，在所有的命令形式中，默认是HEAD。

git reset -- []

This form resets the current branch head to and possibly updates the index (resetting it to the tree

of ) and the working tree depending on , which must be one of the following:

--soft：仅仅更改本地仓库中的提交历史，修改HEAD所指向的commit

--hard：重置index和working tree。任何在当前目录下的tracked文件，如果在commit之后，都会被废弃。

注明：如果不指定mode的话，那么index也将会同步进行更新。这个操作用于实现对index中文件的撤销和更改。

2.2命令使用情景：

1)commit 节点的移动

现在有如图所示的版本情况：

---------(1.1)-----------(1.2)--------(1.3)------------(1.4)

其中HEAD指向1.4。此时想要生成patch，如果直接运行git format-patch的话，将生成1.3～1.4的patch，如果不想要1.2和1.3的提交记录，直接从实现1.1到1.4的修改，此时需要运行以下命令：

$git reset 1.1

此时，当前工作目录下位1.4版本的文件，1.2 ，1.3这两个版本的修改历史被丢弃。然后可以继续 add然后commit

注意，git reset的意义是： git-reset - Reset current HEAD to the specified state,它改变的本地仓库中的文件和index中的记录，并没有改变当前工作目录之下的文件。运行这个命令以后，你可能得到如下的结果：

[email protected]:/home/hyk/software/ltp# git reset  4bdda040bc045dd8d921d54d3b54db5dabeb9958

Unstaged changes after reset:

Mtestcases/kernel/mem/tunable/max_map_count.c

$git add file1

$git commit

$git add file2

$git commit

2)撤销add到staged中的文件

情景：add了两个文件到index，但是觉得没有修改好，现在需要撤销add这个操作。

$ edit                                     (1)

$ git add frotz.c filfre.c

$ mailx                                    (2)

$ git reset                                (3)

$ git pull git://info.example.com/ nitfol  (4)

3)撤销一次提交，修改之后重做

相对于上个例子，更进一层，add完毕，而且已经commit，然后想要撤销这次提交，重做以后再进行提交。

Undo a commit and redo

$ git commit ...

$ git reset --soft HEAD^      (1)

$ edit                        (2)

$ git commit -a -c ORIG_HEAD  (3)

3.git rebase：合并不同分支上的提交，形成线性提交历史

git rebase的说明：git-rebase - Forward-port local commits to the updated upstream head

rebase,顾名思义，rebase的意思就是改变某一个分支的base。本例中，就是将mywork这个分支的base从C2改动到C4

假设你现在基于远程仓库"origin"，创建一个叫"mywork"的分支。

$ git checkout -b mywork origin

现在我们在这个分支做一些修改，然后生成两个提交(commit).

$ vi file.txt

$ git commit

$ vi otherfile.txt

$ git commit

...

但是与此同时，有些人也在"origin"分支上做了一些修改并且做了提交了. 这就意味着"origin"和"mywork"这两个分支各自"前进"了，它们之间"分叉"了。

在这里，你可以用"pull"命令把"origin"分支上的修改拉下来并且和你的修改合并； 结果看起来就像一个新的"合并的提交"(merge commit):

但是，如果你想让"mywork"分支历史看起来像没有经过任何合并一样，你也许可以用 git

rebase:

$ git checkout mywork

$ git rebase origin

这些命令会把你的"mywork"分支里的每个提交(commit)取消掉，并且把它们临时 保存为补丁(patch)(这些补丁放到".git/rebase"目录中),然后把"mywork"分支更新 到最新的"origin"分支，最后把保存的这些补丁应用到"mywork"分支上。

当'mywork'分支更新之后，它会指向这些新创建的提交(commit),而那些老的提交会被丢弃。 如果运行垃圾收集命令(pruning garbage collection), 这些被丢弃的提交就会删除. (请查看 git

gc)

现在我们可以看一下用合并(merge)和用rebase所产生的历史的区别：

在rebase的过程中，也许会出现冲突(conflict). 在这种情况，Git会停止rebase并会让你去解决 冲突；在解决完冲突后，用"git-add"命令去更新这些内容的索引(index), 然后，你无需执行 git-commit,只要执行:

$ git rebase --continue

这样git会继续应用(apply)余下的补丁。

在任何时候，你可以用--abort参数来终止rebase的行动，并且"mywork" 分支会回到rebase开始前的状态。

$ git rebase --abort

注意：如果C3 C5里面改动的内容有冲突，那么这个时候先要解决冲突，然后才能提交。