本文主要是介绍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：合并不同分支上的提交，形成线性提交历史
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
这篇关于git中各个commit节点的查询 回溯 与 合并:git rebase与git reset的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
