git 变基后我是否丢失了更改？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/13154562/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Have I lost my changes after rebasing?
提问by dave
I recently rebased a branch that I was working on. The history of the tree looked something like this:
我最近重新建立了一个我正在处理的分支。这棵树的历史看起来像这样：
1 = 2 = 3 = 4
\
5 = 6 = 7
\
8
I wanted to rebase my changes (number 8 in the diagram) to be on the master branch (up to commit 4 on the diagram now). So I did the following:
我想将我的更改（图中的第 8 个）重新设置为在 master 分支上（现在在图中最多提交 4 个）。所以我做了以下事情：
git checkout my_branch
git rebase master
< lots of git mergetool/git rebase --skip to resolve conflicts >
<大量的 git mergetool/git rebase --skip 来解决冲突 >
Only now when I run:
只有现在当我运行时：
git checkout my_branch
git diff master
I get zero differences. I haven't lost my branch (I can still recreate my changes from a patch that I saved) but I can't find the merge/rebase that I did. What did I do wrong? Is the rebase still there somewhere with my changes merged with the master or do I have to do it again?
我得到零差异。我没有丢失我的分支（我仍然可以从我保存的补丁中重新创建我的更改）但是我找不到我所做的合并/rebase。我做错了什么？我的更改与 master 合并后，rebase 是否还在某处，还是我必须再做一次？
回答by John Szakmeister
If you're not seeing any difference, I suspect you lost your changes. You can likely use git reflogto identify the branch that existed before the rebase, and use git reset --hard <my-branch-tip-before-rebase>to get back the original branch. And yes, you'll have to run through the process again. :-(
如果您没有看到任何差异，我怀疑您丢失了更改。您可能会使用git reflog来识别在变基之前存在的分支，并使用git reset --hard <my-branch-tip-before-rebase>来取回原始分支。是的，您必须再次执行该过程。:-(
I'm not quite sure how you ended up with them looking the same though. I would have expected to see the following with the command you gave:
我不太确定你是如何让它们看起来一样的。我本希望通过您提供的命令看到以下内容：
1 = 2 = 3 = 4 (master)
\ \
\ 5' = 6' = 8' (my_branch)
\
5 = 6 = 7
In this case, you probably should've used rebase --onto:
在这种情况下，您可能应该使用rebase --onto：
git rebase --onto master <commit id for 6> my_branch
That would have left you with a graph that looked like this:
这会给你留下一个看起来像这样的图表：
1 = 2 = 3 = 4 (master)
\ \
\ 8' (my_branch)
\
5 = 6 = 7
As far as losing your changes, it does take a bit of practice dealing with merge conflicts, especially when you have a couple of big blocks that look nearly identical. I always resort to looking at the actual diff introduced by a commit, and the attempting to tease out that change and merge it with what is already on the branch in an appropriate way. I can easily see how your change may have gotten lost in there.
至于丢失更改，处理合并冲突确实需要一些练习，尤其是当您有几个看起来几乎相同的大块时。我总是求助于查看由提交引入的实际差异，并尝试梳理该更改并以适当的方式将其与分支上已有的内容合并。我可以很容易地看到你的零钱是如何丢失在那里的。
One thing to remember. If you don't expect a bunch of merge conflicts--because you don't feel the sources diverged enough, the seeing one is a warning flag of doing something wrong. It's good to back up, by doing a git rebase --abort, investigating the branches and checking again if you expect a conflict. Make sure to take note of where the conflict happened (there's usually a "Applying ..." just before rebase kicks you to the command line). That's usually a great place to start.
要记住的一件事。如果您不希望出现一堆合并冲突——因为您觉得来源分歧不够，那么看到一个是做错事的警告标志。最好通过执行 a 进行备份git rebase --abort，调查分支并再次检查是否会发生冲突。确保记下冲突发生的位置（通常在 rebase 将您踢到命令行之前会出现“正在应用...”）。这通常是一个很好的起点。
At times, conflicts are unavoidable, and are tedious to work through. But I suspect with practice, you'll run into this problem less.
有时，冲突是不可避免的，而且处理起来很乏味。但我怀疑通过练习，你会更少地遇到这个问题。
For more information on transplanting changes between branches, look at the git rebaseman page. Search for "rebase --onto". The first hit should land you in a section talking about transplanting changes to another branch.
有关在分支之间移植更改的更多信息，请查看git rebase手册页。搜索“rebase --onto”。第一次点击应该让您进入讨论将更改移植到另一个分支的部分。
