我最近重新调整了我正在研究的一个分支。这棵树的历史是这样的：
1 = 2 = 3 = 4
\
5 = 6 = 7
\
8
我想将我的更改（图中的第 8 号）重新设置在主分支上（现在在图中最多提交 4）。所以我做了以下事情：
git checkout my_branch
git rebase master
<很多 git mergetool/git rebase --skip 解决冲突>
只有现在当我运行时：
git checkout my_branch
git diff master
我得到零差异。我没有丢失我的分支（我仍然可以从我保存的补丁中重新创建我的更改）但我找不到我所做的合并/变基。我做错什么了？我的更改与主服务器合并后，rebase 是否仍然存在于某个地方，还是我必须再做一次？
如果您没有看到任何差异，我怀疑您丢失了更改。您可能会使用git reflog来识别在变基之前存在的分支，并使用git reset --hard <my-branch-tip-before-rebase>来取回原始分支。是的，您将不得不再次运行该过程。:-(
不过，我不太确定您最终是如何使它们看起来相同的。我本来希望通过您给出的命令看到以下内容：
1 = 2 = 3 = 4 (master)
\ \
\ 5' = 6' = 8' (my_branch)
\
5 = 6 = 7
在这种情况下，您可能应该使用rebase --onto：
git rebase --onto master <commit id for 6> my_branch
那会给你留下一个看起来像这样的图表：
1 = 2 = 3 = 4 (master)
\ \
\ 8' (my_branch)
\
5 = 6 = 7
至于丢失您的更改，确实需要一些练习来处理合并冲突，尤其是当您有几个看起来几乎相同的大块时。我总是求助于查看提交引入的实际差异，并尝试梳理出该更改并以适当的方式将其与分支上已有的内容合并。我可以很容易地看到您的更改是如何丢失在那里的。
要记住的一件事。如果您没有预料到会出现一堆合并冲突——因为您觉得来源的分歧不够大，那么看到的就是做错事的警告标志。git rebase --abort最好通过执行、调查分支并再次检查您是否预计会发生冲突来备份。确保记下冲突发生的位置（在 rebase 将您踢到命令行之前通常有一个“正在应用...”）。这通常是一个很好的起点。
有时，冲突是不可避免的，而且处理起来很乏味。但我怀疑通过练习，你会更少遇到这个问题。
有关在分支之间移植更改的更多信息，请查看git rebase手册页。搜索“rebase --onto”。第一次点击应该让您进入讨论将更改移植到另一个分支的部分。