是的，在等待合并请求（MR）被批准和合并时，您可以使用变基来保持特性分支的最新状态。
我在工作中使用的工作流是为特性分支develop，在创建MR之前，我将特性分支重新设置为develop。这样，当MR被批准时合并到develop中就简单地变成了一个没有合并提交的快进合并。这使提交历史保持干净整洁。
如果你的MR过时了，最好让你的特性分支经常更新develop by rebase。如果你等待的时间太长，那么开发中的大量新代码可能会使你的合并变得很困难，有很多冲突需要解决。它还为您提供了使用develop中的新代码测试特性的机会。

不要换基地，因为它歪曲了你开始努力的地方。“干净的git历史”目标是以牺牲开发工作时实际发生的事情的准确性为代价的。如果您想测试最新的开发技巧是否能够从您的分支接收更改，请在本地进行测试合并。如果它有东西坏了，修复编译错误，损坏的测试和合并冲突时，这样做合并。当你已经修复了它，做一个公关与此合并包括在内。这代表了实际发生的事情。
我相信在我拉下Develop分支的更新后，如果我将Develop分支合并到我的特性分支中，那些提交将成为我的特性分支提交的一部分，我的特性提交将变得混乱并依赖于合并的新提交。我觉得...
这就是所谓的“反向合并”，是一个明确的禁忌。Linus Torvalds过去经常对这样做的人大发雷霆。始终与检出的高阶分支合并。
你的问题实际上是你的工作没有在合理的时间内合并。如果这是无法更改的，只需重复合并到develop中，将特性分支快速转发到包含所有修复的合并，然后更新PR以反映此提交。不要推开发分支，推你的特性分支。