我做了一个从分支 xyz 到 master 的合并，涉及大约 20 个文件，并且没有冲突。不幸的是，我不记得我使用的选项，但无论我做什么，生成的代码都是所需的代码，但没有从分支 xyz 到 master。我希望从 xyz 到 master 的线，以便人们可以从提交图中清楚地看到合并发生了。而不是从分支 xyz 到 master 的一条线，我在 master 上有一个新节点，就好像我在 master 分支上创建/编辑这些文件而不是它们来自分支 xyz。
我曾尝试使用“正确”选项再次进行合并，这会导致从 xyz 到 master 绘制线，但 Git 现在告诉我一切都是“已经是最新的”，这在技术上是正确的。在其他 SCM 工具中，我已经能够强制合并（即使文件相同）和/或从一个分支到另一个分支画一条线。
当两个分支之间的文件相同时，添加合并行的最佳 Git 技术有哪些？或者第二次尝试的最佳想法？
更新：不幸的是，我已将我的更改推送到我的其他开发人员从中提取的中央存储库，因此执行“tbekolay”的硬重置建议不太可能解决我的问题。
您正在寻找的合并选项是--no-ff（请参阅git merge 手册页）。
您之前所做的合并已解决为快进合并，这意味着它只是将您的分支粘贴到 master 之上，而没有合并提交。由于您希望分支的历史存在，因此您希望明确包含该合并提交。要做到这一点，而不是
git merge xyz
你会做的
git merge xyz --no-ff
这会给你你想要的行为。
如果您没有将更改推送给其他任何人，那么您可以通过将 master 硬重置为合并前的状态，然后使用--no-ff.
为此，假设您尚未删除分支xyz，请先找到合并前的最后一个提交
git log
复制其哈希，然后执行
git reset --hard <commit_hash>
然后最后
git merge xyz --no--ff
如果你已经推动但非常坚决地恢复xyz被合并的历史，你仍然可以做到这一点，但解决方案不是很干净，使用快进合并可能更容易。
但是，如果你想这样做，在合并之前再次罚款最后一次提交
git log
复制它的哈希，然后做
git revert <commit_hash>..master
这将为分支中的每个提交进行提交，该提交只是反转该提交。这有点丑；您可以通过将所有这些提交压缩为单个反向提交来使其不那么难看
git rebase -i origin/master
假设您没有git push在这些步骤之间偷偷摸摸。这将打开一个编辑器，您可以在其中进行pick第一次提交，以及squash所有其他提交到该第一次提交中。您可能想在最后编辑提交消息以说出类似Reverting fast-forward merge of xyz.
您的存储库现在处于快进合并之前的状态。它具有合并的历史记录，您可以还原该合并。此时，您可以
git merge xyz --no-ff
你会得到一个合并提交。具有讽刺意味的是，由于master发生了相当大的变化，即使您不使用--no-ff，您现在也将获得非快进合并，但由于这是您喜欢的工作流程，您不妨养成始终与--no-ff.
从已经推送到服务器的这些更改中恢复将很困难。您可以按照 tbekolay 的步骤进行硬重置，然后push -f对您的中央存储库执行操作。但是，你会改写历史，我不建议这样做。它会搞砸你的其他开发人员。
我建议这次处理快进合并，并确保你--no-ff将来会继续。