比较git分支和重基分支

我将一个相当古老的主题分支重新放到master上。由于在重新设置基址的过程中有很多冲突，我想将旧的主题分支与重新设置基址的分支进行比较，以确保我没有意外地删除或破坏主题上的任何更改。我最接近这一点的是对

git-diff-master…topic

和

git-diff-master…topic-rebase

的结果进行差异化。这种方法是可行的，但在最终的差异中，由于上下文代码、行号、提交散列等的更改，还有很多噪音，而且它不是一个非常健壮的解决方案。有更简单的方法吗？

您可能会希望区分每种方法产生的有效更改（补丁）：

diff <(git log master..topic -p) <(git log master..old-place-of-topic -p)

---

diff如果您不关心主题分支中的提交历史记录，那么可以重做基准并添加--squash标志。这将在主分支上为您提供一个提交，您可以在其中逐个文件地查看更改的文件。我还将添加标志--no commit to the rebase，以便在提交git rebase之前查看更改

git checkout master
git rebase --squash --no-commit topic
//review changes with your favourite git tool
git commit

如果你不想重做重定基础，外部差异工具（如）可能会对你有所帮助。
我也在努力解决这个问题，并提出了与Ryan和Adam Dymitruk类似的想法，但发现它们并不十分令人满意：比较最终的差异很棘手，如果你发现“错误”，也不会告诉你“错误”是在哪里引入的

我当前的重基工作流包括将每个重基提交与原始提交进行比较，这样我就可以在潜在错误出现时发现并更正它们，而不必重做重基。我使用以下一对git别名来实现这一点：

rc = !git diff -w $(cat .git/rebase-merge/stopped-sha) > .git/rebase-merge/current-diff
rd = !git diff -w $(cat .git/rebase-merge/stopped-sha) | diff --suppress-common-lines .git/rebase-merge/current-diff - | cut -b 1-2 --complement | less

git-rc
存储正在重定基础的分支的
HEAD
最新版本之间的差异。在重播以下提交后，
git rd
将此存储的差异与新的
HEAD
和正在重定基础的分支上的下一次提交之间的差异进行比较。因此，这只显示了通过重播最后一次提交而引入的差异（“错误”）

检查差异后，调用
git rc
更新存储的差异并继续重新设置基础

您甚至可以将它们添加到您的
git-rebase-todo
中，而不是手动调用
git-rc
和
git-rd
，以便在每次提交重播后自动调用它们。
如果我错了，请纠正我，但这也将显示从
git merge base master topic
到
git merge base master topic-rebased
的所有更改，这是我不希望看到的。我只想查看特定于主题分支的更改。另外，不需要reflog，我仍然可以使用topic和topic-rebase。我很感谢您的回复，但这与我当前所做的（问题中提到的）完全相同的结果和问题（假设您指的是
master…topic的旧位置）。它不应该。“…”把所有的差异都带到了共同的祖先身上。这将包括最初创建主题分支后提交的主控上的任何内容。要查看排除的内容：
diff$（git merge base master old topic）…$（git merge base master topic）
对于您的答案，
git diff master..主题的旧位置将如您所说，关于主人的一切，因为话题的老地方是分支的<代码>git diff master..topic
不会（topic上已经有了master的最新版本），因此所有这些更改都将污染最终的差异。根据复杂性与重要性的不同，您可以尝试再次对其重定基址，并将结果与重定基址的主题进行比较。。。（这是在假设你第二次在不同的地方会更加小心的基础上进行的。）否则，
git diff
上的-U选项可以减少上下文，你可以尝试将包含行号和blob散列的大块头变灰。一个有趣的替代方法是重新设置它的基础（例如，
master..topic-rebased
）返回到合并库（或
topic
的来源）并进行比较（差异）这就像一个数学证明，你在这里看到的任何增量都应该是有意义的。这里的重定基址可以通过
cherry pick
或
rebase upper topic~0-到新的基础上来完成。我不知道你的知识水平，但“重定基址”在这种情况下，不应涉及对当前分支进行冲洗，因为我希望它将在分离状态或废弃分支中完成。重新设置回帧不会像其他冲突那样起作用。其他冲突？它是否对您有效不是存储库的一项功能，以及您愿意花费多少时间？我可以得到ting至少在相反的方向上指出了同样的冲突，但你的评论似乎表明了OP没有与我们分享的对回购协议的洞察。即使如此，整个想法都是为了解决你的“其他冲突”，因为对于这个纯粹的验证练习，每一个都会提示您的系列有多么不同。请使用git 2.19（2018年第3季度）查看
git range diff
。请参阅“”，并“。您不想将主控形状重新设置为主题。这是真的。我必须重新阅读我的答案，但我看不出我在哪里写的主控形状应该重新设置为主题？我不想查看主题所做的更改，我想查看我在重新设置主控形状时所做的更改（由于冲突）。