重新调整基准后，我是否丢失了修改内容？

我最近重新定位了一个我正在研究的树枝，这个树的历史看起来是这样的:

1 = 2 = 3 = 4
\
5 = 6 = 7
\
8

我想将我的更改(图表中的数字8)重新基于主分支(现在最多可以在图表中提交4)。所以我做了以下几件事:

git checkout my_branch
git rebase master

< 大量 git mergetool/git rebase ——跳过以解决冲突 >

只有现在当我跑的时候:

git checkout my_branch
git diff master

我没有任何不同。我还没有丢失分支(我仍然可以从保存的补丁中重新创建更改) ，但是我找不到已经找到的 merge/rebase。我做错了什么？当我的更改与主服务器合并时，rebase 是否仍然存在，还是必须重新执行？

77115 次浏览
小开
最佳答案

If you're not seeing any difference, I suspect you lost your changes. You can likely use git reflog to 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. :-(

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:

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.

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 rebase man page. Search for "rebase --onto". The first hit should land you in a section talking about transplanting changes to another branch.


提交答案