Question

我最近重新安排了一个我正在研究的分支机构。树的历史看起来像这样：

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

我想将我的更改（图中的数字8）重新设置为主分支（现在最多在图上提交4）。所以我做了以下事情：

git checkout my_branch
git rebase master

＆LT;很多git mergetool / git rebase --skip来解决冲突＆gt;

直到我跑：

git checkout my_branch
git diff master

我得到零差异。我没有丢失我的分支（我仍然可以从我保存的补丁中重新创建我的更改）但是我找不到我所做的合并/转换。我做错了什么？如果我的更改与主人合并，或者我必须再次这样做吗？

Answer 1

如果您没有看到任何差异，我怀疑您丢失了更改。您可以使用git reflog来标识rebase之前存在的分支，并使用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”。第一次打击应该让你进入一个关于将更改移植到另一个分支的部分。

在变基之后我是否丢失了我的更改？

1 个答案: