git声明一个分支在重定基址后没有合并-为什么？

我使用git svn来管理我的错误修复分支，但它告诉我我有未合并的更改，即使我直接查看svn回购，我也可以看到它们已经提交。这就好像错误修复的重基并没有将分支设置为合并

我做错了什么，在这里

git checkout -b fix_bug_1234

git add .
git commit -m "first change"
git add .
git commit -m "second change"

git rebase -i HEAD~2 // squash the two changes together

git svn rebase // fetch any changes from svn

git checkout master
git rebase fix_bug_1234
git svn dcommit

git branch -d fix_bug_1234
error: The branch 'fix_bug_1234' is not fully merged.

---

原因是

git-rebase

更改了提交对象。因此，虽然实际内容（或差异）与那些重定基础的提交相同，但它们指的是不同的父级，因此是不同的

这样一来，

git branch-d

就无法验证这些提交的更改是否包含在其他一些提交中。然后需要使用

git branch-D

（大写

D

）强制删除

---

另请注意：

git svn dcommit

与重定基址具有相同的效果。当

dcommit

将提交推送到SVN服务器时，它随后会再次从SVN服务器获取提交。因此，最终得到的对象与推送的对象不同。尽管它们在内容上可能相同（除非有冲突），但它们仍然不同（主要原因是

git svn

在提交消息中添加了一行，说明提交所属的svn版本）。

下面是我如何做这类事情的，它是有效的。用户poke的回答解释了为什么git rebase没有做您希望它做的事情

git rebase -i HEAD~2 // squash the two changes together

git svn rebase // fetch any changes from svn
git svn dcommit  // you can commit to SVN from any branch

git checkout master
git svn rebase
git branch -d fix_bug_1234

---

嗯，再基地本身正在做我想做的事情。看到它告诉我我已经改变了，真有点吓人！感谢您提供的工作流程提示。重基正在做您希望更改文件内容的事情。它没有保留SVN中的确切提交树，因此您确实有未合并的提交。它们恰好产生相同的文件内容。