我一直在阅读git rebase以及使用rebase工作流程而不是合并工作流程的优势。 （由于我是git的新手，我实际上并没有遇到过这种情况）
我已经读过，有多个贡献者的项目的标准工作流之一是让贡献者定期rebase他们的主题分支与“主（中心/真实/规范）存储库”的主分支。在提出拉取请求之前进行重新定位会导致合并变得快速前进。
虽然这部分内容对我有意义，但我发现很多情况下合并不会快速前进。我想知道在这些情况下会发生什么。项目主人（规范分支的所有者）是否将主题分支拉到本地分支rebase和merge（以确保它仍然是快进）或者项目经理是否为非-fast-forward merge？
一旦贡献者重新定义并将他/她的主题分支推送到公共存储库，则无法推送第二个rebase。如果那些审阅贡献的人希望在合并之前看到一些代码被改进/调整，会发生什么？在贡献者进行修复时，主分支可能已经改变，而贡献者不能rebase，因为这意味着重写公共存储库的历史记录。
如果在项目经理可以将任何合并到主分支之前进行多次提交，则无法进行快进的另一种情况。虽然第一次合并将是快进，但剩下的不会。
总结一下我的问题：在需要提取的分支机构不是基于master并且无法由贡献者重新分配的情况下会发生什么？项目经理是否在合并之前自己进行变形，或者他/她是否只进行非快进合并？
答案 0 :(得分：2)
GitHub解决这个问题的方法是允许贡献者：
git push --force进行备份。如果无法使用前叉，请提及：
一旦贡献者重新定义并将他/她的主题分支推送到公共存储库，就无法推送第二个rebase。
推送应该是可能的，可能首先删除您发布的分支，然后再次推送它重新创建它 只要所述分支已经在规范分支的基础上重新定位，新分支就能够“快进”合并。
更一般地说，维护者很少是从事解决非平凡合并的人：如果看不到快进步骤，他/她就会拒绝该分支并要求贡献者提供新的合并。
答案 1 :(得分：0)
那里有很多问题。我会在我的两分钱中说，我不能想到单一的情况，即变基不能转换为直线，快速前进的图形。它可能需要更多或更少的工作，具体取决于提交的方式，但它应该始终是可能的。如果你能给出你认为不可重复的特定场景，也许我或其他人可以知道你将如何做到这一点。
答案 2 :(得分：0)
我认为如果贡献者获得 new master并将其修复程序放在新分支中，那么对每个人来说都会更简单。这将允许经理快速完成FF合并并完成它。如果管理者像我的一样，那么他们就是最接近实际来源的人：）