I would like to start writing more here about general Git tips, tricks and upcoming features. There has actually been a lot of cool stuff that has happened since the book was first published, and a number of interesting things that I didn‘t get around to covering in the book. I figure if I start blogging about the more interesting stuff, it should serve as a pretty handy guide should I ever start writing a second edition.
For the first such post, I‘m going to cover a topic that was asked about at a training I did recently. The question was about a workflow where long running branches are merged occasionally, much like the Large Merging workflow that I describe in the book. They asked how to unmerge a branch, either permenantly or allowing you to merge it in later.
You can actually do this a number of ways. Let‘s say you have history that looks something like this:
You have a couple of topic branches that you have developed and then integrated together by a series of merges. Now you want to revert something back in the history, say ‘C10‘ in this case.
The first way to solve the problem could be to rewind ‘master‘ back to C3 and then merge the remaining two lines back in again. This requires that anyone you‘re collaborating with knows how to handle rewound heads, but if that‘s not an issue, this is a perfectly viable solution. This is basically how the ‘pu‘ branch is handled in the Git project itself.
$ git checkout master
$ git reset --hard [sha_of_C3]
$ git merge jk/post-checkout
$ git merge db/push-cleanup
Once you rewind and remerge, you‘ll instead have a history that looks more like this:
Now you can go back and work on that newly unmerged line and merge it again at a later point, or perhaps ignore it entirely.
Reverting a Merge
However, what if you didn‘t find this out until later, or perhaps you or one of your collaborators have done work after this merge series? What if your history looks more like this:
Now you either have to revert one of the merges, or go back, remerge and then cherry-pick the remaining changes again (C10 and C11 in this case), which is confusing and difficult, especially if there are a lot of commits after those merges.
Well, it turns out that Git is actually pretty good at reverting an entire merge. Although you‘ve probably only used the git revert command to revert a single commit (if you‘ve used it at all), you can also use it to revert merge commits.
All you have to do is specify the merge commit you want to revert and the parent line you want to keep. Let‘s say that we want to revert the merge of the jk/post-checkout line. We can do so like this:
$ git revert -m 1 [sha_of_C9]
Finished one revert.
[master 88edd6d] Revert "Merge branch ‘jk/post-checkout‘"
1 files changed, 0 insertions(+), 2 deletions(-)
That will introduce a new commit that undoes the changes introduced by merging in the branch in the first place - sort of like a reverse cherry pick of all of the commits that were unique to that branch. Pretty cool.
However, we‘re not done.
Reverting the Revert
Let‘s say now that you want to re-merge that work again. If you try to merge it again, Git will see that the commits on that branch are in the history and will assume that you are mistakenly trying to merge something you already have.
$ git merge jk/post-checkout
Already up-to-date.
Oops - it did nothing at all. Even more confusing is if you went back and committed on that branch and then tried to merge it in, it would only introduce the changes since you originally merged.
Gah. Now that‘s really a strange state and is likely to cause a bunch of conflicts or confusing errors. What you want to do instead is revert the revert of the merge:
$ git revert 88edd6d
Finished one revert.
[master 268e243] Revert "Revert "Merge branch ‘jk/post-checkout‘""
1 files changed, 2 insertions(+), 0 deletions(-)
Cool, so now we‘ve basically reintroduced everything that was in the branch that we had reverted out before. Now if we have more work on that branch in the meantime, we can just re-merge it.
$ git merge jk/post-checkout
Auto-merging test.txt
Merge made by recursive.
test.txt | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
So, I hope that‘s helpful. This can be particularly useful if you have a merge-heavy development process. In fact, if you work mostly in topic branches before merging for integration purposes, you may want to use the git merge --no-ff option so that the first merge is not a fast forward and can be reverted out in this manner.
Until next time.
https://git-scm.com/blog/2010/03/02/undoing-merges.html
git 撤销 merging，git取消merge
$ git pull origin test
// git pull合并代码的时候，若发生冲突，会处于merging状态，检查代码，发现自己的分支低于主分支，这个时候想撤销merge
// 撤销merge
$ git reset --hard HEAD (or sha_1)
-
用git提交代码时 冲突了
于是分支名变成如下图所示
在命令行输入：
git reset --hard head 就可以了
但是在这个过程中 可能会碰到一个问题，如下图：
这个意思是在C:\Users\Admin\git\phhhh\.git目录下已经有一个index.lock文件夹存在了，只需要去这个目录下删了这个文件夹，然后再输入 git reset --hard head 就ok了
http://blog.csdn.net/Android_Amelia/article/details/49612631?locationNum=11&fps=1