git中各个commit节点的查询 回溯 与 合并:git rebase与git reset

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

本文来源：git中各个commit节点的查询 回溯 与 合并:git rebase与git reset   http://blog.csdn.net/trochiluses/article/details/8996431

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

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

$git log

commit daffbd39053d4f2e78f88955c2158de6092258a2
Author: hyk <hyk@hyk-linux.(none)>
Date:   Wed May 29 22:45:23 2013 +0800


    this is a test


commit 38d58591fc0607bfd262fc8d363e52047fcf0e9c
Author: Eryu Guan <eguan@redhat.com>
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 <eguan@redhat.com>
    Reviewed-by: Rich Johnston <rjohnston@sgi.com>
    Signed-off-by: Rich Johnston <rjohnston@sgi.com>

如上，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] [<commit>] [--] <paths>...
 git reset (--patch | -p) [<commit>] [--] [<paths>...]
git reset (--soft | --mixed | --hard | --merge | --keep) [-q] [<commit>]

3）模式详解:

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

git reset --<mode> [<commit>]

           This form resets the current branch head to <commit> and possibly updates the index (resetting it to the tree
           of <commit>) and the working tree depending on <mode>, 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中的记录，并没有改变当前工作目录之下的文件。运行这个命令以后，你可能得到如下的结果：

root@hyk-linux:/home/hyk/software/ltp# git reset  4bdda040bc045dd8d921d54d3b54db5dabeb9958

Unstaged changes after reset:
M testcases/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里面改动的内容有冲突，那么这个时候先要解决冲突，然后才能提交。