我正在使用集成商工作流程管理一个 git 存储库。换句话说，我从我的同事那里 pull 提交，并将它们推送到 blessed 仓库。
在大多数情况下，我希望保持提交历史是线性的，所以当我集成更改时，可以执行 rebase 而不是 merge 吗？这是一个例子:
git fetch coworker
git checkout coworker/master
git rebase master
git checkout master
git merge HEAD@{1}
git push
我担心当他们执行下一次 git pull 时远程仓库会发生什么。 git 是否能够处理这个问题，或者 coworker repo 在 pull 期间会失败，因为提交在 origin 上的顺序不同>?
更新:我最初让示例从“master” rebase “coworker”分支。我的意图恰恰相反，将“同事”提交放在主人之上。所以我更新了示例。
最佳答案
你肯定不想按照你的建议去做，它会将 master 分支重新设置到你同事的 master 上。根据您同事的 master 所基于的内容，您可能最终会经常倒带中央 master。
您可能想要做的恰恰相反，在将您同事的 master merge 到 master 之前对其进行 rebase 。
git fetch coworker
git checkout coworker/master
git rebase master
git checkout master
git merge HEAD@{1}
git push
不过，我仍然不推荐这样做。您的同事将不得不解决您如何重新调整他们的更改。大多数时候，这可能是微不足道的，他们可以放弃他们的提交以支持您的提交，但这仍然是他们可能需要手动检查的事情。
就我个人而言，我建议直接 merge 他们的提交。如果您觉得它们基于太旧的 master 版本并且 merge 将不必要地复杂或基于不合理的旧提交，那么让他们 rebase 他们的 master 并重新获取。然后至少他们知道您正在 merge 什么，并且他们解决了他们代码中的任何冲突。
另外，我要告诫不要以不必要的线性历史为目标。 merge 并行开发的开发人员分支可以让您更真实地呈现历史。如果您在 merge 之前对开发人员的提交进行 rebase ，那么您将不再拥有能够准确表示该开发人员修复和提交的代码状态的提交记录。这可能并不经常发生，但可能会发生两个提交交互产生错误，但不会发生 merge 冲突。如果你不 rebase ，你会得到更准确(也更公平!)的“blame ”。
关于git - Integrator 工作流程，fetch-rebase-push 对于远程 repo 是否安全？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1274755/