GitLab 合并请求显示 Master 中已有的旧更改

Question

我正在将我的 fork 中的更改合并到我们团队在 GitLab 上的主存储库中。

奇怪的是，随着我的提交，合并显示其他文件已更改，我尚未处理的文件。并且它显示的更改已经存在在我要合并的上游主服务器中。什么？

这是我的工作流程：（第 9 步是我遇到问题的地方。）

1. 来自上游主节点的本地主节点变基
2. 从本地主创建功能分支
3. 结帐功能分支。
4. 在我的功能分支上做大量工作，经常提交并推送到我的 fork 的功能分支。
5. 创建合并请求并将 fork 的功能分支合并到上游 master。
6. 从上游 master 签出本地 master 和 rebase
7. 从本地 master 签出本地功能分支和 rebase（如果需要）（以引入我的队友可能在其他文件中所做的任何更改）。
8. 在本地做更多的工作，经常提交并推送到我的 fork 的功能分支。
9. 创建从 fork 功能分支到上游 master 的合并请求，显示对其他文件的更改，上游 master 中已经存在的更改。

逐行比较这些其他文件的“更改”与上游主文件中的内容，我可以看到这些更改已经存在于上游主文件中。

git到底为什么要这样做？这真的很令人不安，就像我做错了什么一样，而且每次遇到这种奇怪情况时我都会很紧张地默认合并这些更改，因为这些其他文件是我的队友工作的——我不能 100% 确定我的 fork 的功能真的有最新最好的代码。

我做错了什么？

谢谢！

Answer 1

就我所见，造成混乱的是你的 fork 分支中 master 的变基（也就是第 7 步）。
通过变基，你可以放下所有的合并，它会改变提交哈希，创建新的提交。

你可以：

• git merge 而不是第 7 步中的变基

• git rebase --preserve-merges

为了完全理解其中的含义，我建议阅读对该问题的详细记录的答案：What exactly does git's "rebase --preserve-merges" do (and why?)