【发布时间】：2021-10-11 06:07:29
【问题描述】：
问题：
将origin/branch_y 合并到origin/master 时，在使用git checkout origin/master file_x 覆盖branch_y 上的file_x 并将file_x 推送到origin/branch_y 后，file_x 仍然与origin/master 上的版本不同，并且列在更改下。
问题：
此时 file_x 不应该，至少在内容方面，在两个分支上都完全相同吗？
全文：
比较分支sac_sb3 和master，在发出新的合并请求时，我注意到我无意中将文件env.py 和utils.py 的更改推送到分支sac_sb3 - 这两个文件都应该保持不变.
分支代表了数周的工作，它包含许多提交，并且图表的清洁度在给定的工作环境中并不是最重要的。我推断最快的解决方案是用远程主机的文件状态覆盖文件。因此，按照这个 StackOverflow post，我跑了：
git checkout sac_sb3
git checkout origin/master rlmodel/sb3/utils.py
git checkout origin/master rlmodel/sb3/env.py
git add -u
git commit -m "restore env.py and utils.py with versions from origin/master"
git push
但是，当我现在重新初始化 origin/sac_sb3 和 origin/master 之间的合并请求时，env.py 和 utils.py 仍然列在更改下，甚至在内容方面与 origin/master 上的版本不同。
【问题讨论】：
-
会不会是
autoclrf？只是在黑暗中刺伤。 Relevant question -
我不确定我是否正确理解
autoclrf。但我所有的工作都是在 Linux 上完成的——所以不应该应用任何样式转换。此外，这些文件实际上在上下文方面有所不同，而不仅仅是在格式方面。 -
你有没有在其他六个命令之前运行
git fetch，以便根据origin的master更新你本地的origin/master？如果不是，那可能就是问题所在。您现有的git checkout命令是正确的，但您将从origin/master转换为git checkout命令时的任何提交哈希ID 中获取文件，这不一定是正确的。事实上，即使在git fetch之后，它也可能已经过时，这取决于origin的变化速度，但fetching 是你能做的最好的。 -
好点！但是，我最初运行的是：
git checkout master->git fetch --all->git pull->git checkout sac_sb3->git checkout master rlmodel/sb3/utils.py->git checkout master rlmodel/sb3/env.py->git add -u->git commit -m "restore env.py and utils.py with versions from origin/master"->git push。我在我的问题中只使用了origin/master来缩写这个过程。所以，无论如何，我确实事先运行了git fetch -all。