我一直在阅读关于 git rebase 的文章以及使用 rebase 工作流而不是 merge 工作流的优势。 (由于我是 git 新手，我实际上没有遇到过以下情况)
我读过，对于具有多个贡献者的项目，标准工作流程之一是贡献者定期 rebase 他们的主题分支与“主要(中央/真相/规范)”的主分支库”。在发出 pull 请求之前进行 rebase 会导致 merge 变得快进。
虽然这部分对我来说很有意义，但我看到很多情况下 merge 不会快进。我想知道在这些情况下会发生什么。项目负责人(规范分支的所有者)是否将主题分支 pull 到本地分支、rebase 和 merge(以确保它保持快进)或者项目经理只是做了一个非快进的merge？
一旦贡献者 rebase 并将他/她的主题分支推送到公共(public)存储库，就不可能再推送第二个rebase。如果审查贡献的人希望在 merge 之前看到一些代码经过改进/调整，会发生什么情况？ master 分支可能在贡献者进行修复时已经更改，并且贡献者不能 rebase 因为这意味着重写公共(public)存储库的历史。
另一种不可能快进的情况是在项目经理可以将任何一个 merge 到主分支之前进行多次提交。虽然第一次 merge 会快进，但其余的不会。
总结一下我的问题:如果需要 pull 入的分支不是基于 master 并且不能由贡献者重新设置基线，会发生什么情况？项目经理是在 merge 之前自己进行 rebase 还是他/她只是进行非快进 merge ？
最佳答案
GitHub 解决这个问题的方法是允许贡献者:
- 在服务器端拥有自己的仓库(“fork”)，在那里他们可以
git push --force他们的核心内容) - 向主仓库(不是分支，仅提交是否应用)提出补丁(pull requests)，并且维护者可以轻松查看这些补丁是否可以快进应用方式与否。
如果不可能进行 fork ，您会提到:
Once a contributor rebases and pushes his/her topic branch to a public repository, pushing a second rebase is not possible.
推送应该是可能的，也许首先删除你发布的分支，然后通过再次推送重新创建它。
只要所述分支已在规范分支之上重新建立基础，新分支就能够“快进” merge 。
更一般地说，维护者很少是解决重要 merge 工作的人:如果看不到快进步骤，他/她将简单地拒绝该分支并向贡献者请求一个新分支.
关于git - 你如何处理 git rebase 工作流程中的不可快速转发的情况？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6755958/