Git Pull Request没有更改，但git diff显示有更改

Question

我的分支出了问题

介绍

我的项目有3个分支：Dev、Main和Staging。

在Dev分支上，我们添加新功能；在Main分支上，我们修复错误；在Staging上，我们进行测试部署。

当在Main分支完成Bug PullRequest时，我们会创建一个PullRequest Main -> Dev** 来更新Dev分支的内容。 当开发新功能时，在Dev分支上完成PullRequest。

当我们想要部署所有新功能时，我们创建一个PullRequest Dev -> Main，然后再创建一个PullRequest Main -> Staging。最后，我们部署Staging分支的内容。

问题

当我手动比较我的Dev和Main分支时，我发现它们之间有区别：在Dev分支中，某些文件出现在一个文件夹中，但是在先前的提交中它们被移动到另一个文件夹中。

当我运行git diff Main..Dev命令时，我看到与上述相同的差异。

通常情况下，此时这两个分支应处于相同状态。因此，我创建了一个PullRequest Main -> Dev，以将正确的状态（Main状态）提供给Dev分支：但是它显示我的PullRequest上没有任何更改。

问题

如何给Dev分支正确地提供当前的Main分支状态？

谢谢

- Nathan Bruet

---

“我看到有些不同之处”，你能告诉我们你看到了哪些类型的不同吗？ - Lasse V. Karlsen

我更新问题，以更加精确地添加句子“我看到有差异”。 - Nathan Bruet

一个拉取请求怎么结束呢？合并（Merge）、变基（Rebase）或压缩并合并（Squash and Merge）？ - matt

你所描述的情况，是我预期会发生的情况，如果你尝试连续两次将Main合并到Dev中。它们不同，但却无需进行任何操作。 - matt

如何强制使分支相同？这与合并完全不同。合并不会导致两个分支代表项目的相同状态。如果您想让Dev与Main完全相同，您应该从Main分支出Dev！ - matt

Answer 1

可能发生了什么

正如@matt在评论中所说，这可能是之前合并的结果，其中冲突可能已经被解决，但未移动文件。现在，当您再次合并时，Git认为它已经处理过该重命名，因此不必处理它。您可以通过查看自上次合并点以来的提交历史记录来确认此理论：重命名是在其之前还是之后？

如何合并Main并强制Dev采用Main的状态

如果此时您想丢弃Dev的当前状态，并使其完全成为Main的状态，并且您想使用合并操作进行操作，则我会使用ours策略。我不确定您是否可以通过PR来完成此操作，您可能需要在PC上执行此操作并推送，希望您的工作流程允许这样做！

不幸的是，您无法直接从Dev执行git merge -s theirs Main，那将太简单了。您必须从Main执行git merge -s ours Dev来创建您想要的合并提交到Dev：

git checkout Main
git merge -s ours Dev  # this "merges" Dev in but ignores all its changes
# don't push this!
git checkout Dev
git merge Main  # this should be a fast-forward merge
# now you can push Dev

当你完成后，你可以通过将 Main 恢复到原来的位置来清理你的沙箱，因为该合并是针对 Dev 的：

git checkout Main
git reset --hard origin/Main

如果我想要从Main中重命名，但不想丢失Dev中的其他更改怎么办？

在这种情况下，我认为您需要手动完成一些工作。如果这些重命名确实在之前的合并之前，并且将这些提交带入Dev历史记录的合并没有应用这些重命名，则需要在Dev分支上重新创建这些重命名，可能需要手动完成。

我不认为您有回到早期合并并正确重做它的选项，但如果可以，那可能是最清洁的选项。

- joanis

---

谢谢你的解决方案，它有效！我不知道合并命令的参数“-s ours”，感谢你的发现！ - Nathan Bruet