我正在开发一个使用 Git 管理的项目，大约有 20 人分成几个团队。项目经理要求所有工作分支不只是合并到master上，而是rebase到master上，然后由经理自己合并。
根据我目前发现的信息，您不应该对已经公开可用（即推送到远程）的提交进行变基——我已经不得不处理这个问题，这并不好玩。但是，我真的很想在请求将代码合并到 master 之前与我的团队共享代码（即在 rebase 到 master 并等待项目经理快进 master 以反映我们的分支之前）。
我的团队可以从远程推送和拉取然后重新设置为 master 以进行集成的正确工作流程是什么？仅仅是我一直在做错的事情，还是一个合法的问题？
为什么要在合并前变基？这背后有什么意义？
正确的工作流程是不要变基。如果您的经理想要控制合并到 master，但不想解决任何合并冲突，您应该先将 master 合并到您的主题分支。“合并”到 master 现在将再次成为一个快进操作。
这是一个很好的解释为什么 rebase 不好： http: //geekblog.oneandoneis2.org/index.php/2013/04/30/please-stay-away-from-rebase
如果你的经理很固执，并强迫你重新设置基准，那么就没有真正好的解决方案——这不是重新设置基准的目的。在那种情况下，我会：
git fetch，然后联系git reset --hard origin/branch他们，以便他们获得您的重新定位版本。