在项目中打开合并请求一段时间后，由于其他人将自己的更改合并到该分支中，因此您尝试合并到的分支版本变得过时是正常的。
Gitlab通过显示您更新的分支版本落后于远程分支的程度来帮助您。
在后面不会对合并行为设置任何障碍，但是在合并到的分支之上rebase你的提交是一种常见的做法。这将使你的合并请求更新，将你的提交按时间顺序放在已经在该分支中的提交之后。这种方法使负责合并的人的工作更容易，因为提交者自己已经解决了可能发生的任何冲突。
按照您提出的场景执行rebase将是这样的：

# Add a remote named `upstream` pointing to the original repository
git remote add upstream https://gitlab.example.com/example/your_project.git

# Fetch the latest commmits from `upstream`
git fetch upstream

# Checkout our branch-A
git checkout branch-A

# Rebase our branch on top of the `upstream/develop` branch
git rebase upstream/develop

# If needed fix any conflicts that may have appeared and then `git rebase --continue`  

# Push the changes to the branch of your merge request
git push --force origin branch-A

***注意：***当你推送时，--force标志是必需的，因为你正在重写origin/branch-A的提交历史。来自git的文档：

[--force]会导致远程仓库丢失提交;小心使用

如果你看到一条“behind by X commits”的消息，gitlab表示你要合并的分支已经从你分支的地方移动了。
当你查看gitlab中的差异时，它们可能看起来令人困惑，可能暗示你即将撤销在目标分支上的后续提交中实现的更改。
如果你想确保你看到的是合并将要执行的更改，最安全的做法是更新你想要合并的分支，首先在目标分支中合并。

# fetch the latest code on all branches
git fetch

# checkout your working branch (if you're not already on it)
git checkout branch-A

# merge in the target branch
git merge origin/develop

修复可能出现的任何冲突，然后提交它们：

# stage changes & commit
git add .
git commit

# push changes to origin
git push

如果你现在刷新gitlab上的合并请求页面，“behind”消息将消失，差异将只反映你所做的更改。
这比重定基分支安全得多，因为它不需要--force推送。这也意味着git时间轴的年表与实际发生的事情相匹配，所以如果你试图在未来追踪一个问题，你不会被重写历史所误导。
缺点是提交历史可能看起来有点混乱。

另外@alejdg的回答，为了防止这个
[--force]会导致远程仓库丢失提交;小心使用。
你也可以使用--force-with-lease，它比--force更安全，如果其他提交被插入到你的rebase和你的push --forcemore information之间

除了上面的答案，我通常会做下面的事情来重基我的本地分支和推送。如果我是贡献者，通常我会将远程源添加到本地git仓库。

git pull
git checkout <your-branch>
git rebase origin/<remote-branch>
git push --force origin <your-branch>

这是初学者对正在发生的事情的理解。你会在git上找到更高级别的“git措辞”。但这就是我在饭桶丛林中找到我的脚步的方式。;）希望对其他初学者有帮助。
首先检查你的主要分支（这里是development分支）：

git checkout develop
git pull --all

然后切换到你的新分支-A（它已经和其他已经合并到“develop”中的提交并行工作）。
您可以单独选择每个提交以更加谨慎（推荐），或者直接在最后一个MR的所有先前提交之上进行重定基。
另外，一般来说，查找stash和stash apply，那么你不需要任何提交，这要容易得多。

git checkout branch-A
git stash #(if you do not use commit, stash is recommended)
git rebase -i develop

-i意味着交互式，这意味着您需要在弹出的编辑器中更改内容。

• （如果你不使用-i，你不会得到编辑器，这也应该是好的，从那时起，相同的设置将自动使用，但这只是在这种情况下，在其他情况下，你可能真的需要它，因此似乎很好习惯该编辑器）。

这个“todo-editor”打开的提交导致了“develop”的最后一个MR（就像你的例子中的main）。
在“todo-editor”中，把pick保留在所有提交的前面，这是默认的，只把最后一个修改为edit而不是pick，因为你的新提交将被你在下面所做的所有提交编辑，而不是其他提交。你的新提交应该在“develop”分支的MR的顶部，所有其他选择的提交应该是在最后一个带有“develop”的MR之前的提交。
它看起来像：

然后写-关闭编辑器，你现在会看到所有的冲突的第一个“挑”，当你看

git diff

或者更好的方法是进入codium/vscode，在每个冲突处只接受当前或传入的代码（有冲突的文件和文件夹被标记为红色，在文件中，使用向上/向下箭头来查找冲突）。
然后：

git rebase --abort

在执行rebase时，不要执行git commit或git push，而是使用--abort并再次启动rebase，或者如果您确定正在执行的操作并且不需要检查中间结果，则使用git rebase --continue。push会损害你的提交树，commit --amend会改变以前的提交，而commit会从旧的提交创建新的提交。
Rebase不适合这个。当你使用rebase时，你想在结束时回到起点，只有 * 然后 * 你才能在需要时使用git commit --amend和git push -f。
不管怎样。继续工作：
对每个提交重复上述步骤，下一个将是第二次选择。第三次提交已经是“编辑”提交。如果你达到了，重复上面的步骤，当没有冲突了：

git add .
git stash apply #(or if you use commit: git commit --amend)
git push -f

您已经将新分支设置在最新“开发”MR中的工作之上。

• 在我的例子中，对“develop”的重定基也让我看到了前面的“develop”MR本身的MR提交。我最终添加了一个重复的提交，这是错误的。如果你在一个已经合并的MR提交上错误地使用了commit --amend，就会发生这种情况。因此，在我最近的一次提交之前，我多了一次提交，所以我有两次提交，而不是在“开发”之上的一次。

因此，最好不要使用commit，而是在每个picked commit上使用stash/stash apply。*