集成商工作流程,fetch-rebase-push对远程回购是否安全？

Question

我正在使用集成商工作流程管理git repo.换句话说,我从我的同事那里得到了承诺,然后将它们推向了受祝福的回购.

在大多数情况下,我想保持提交历史的线性,所以在我整合更改时可以做一个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回购失败期间pull,现在提交的顺序是不同的origin？

更新:我原来有一个例子来自'master'的'同事'分支.我的意图恰恰相反,将"同事"提交放在主人之上.所以我更新了这个例子.

Answer 1

您绝对不想按照您的建议进行操作，它会将master分支重新设置为您同事的master. 根据您同事的master基础，您最终可能会经常倒带中心master.

您可能想做的恰恰相反，在将同事的 master 合并到 master 之前对其进行 rebase。

git fetch coworker
git checkout coworker/master
git rebase master
git checkout master
git merge HEAD@{1}
git push

但我仍然不推荐这个。您的同事将必须解决您如何重新调整他们的更改的问题。大多数时候，这可能是微不足道的，他们可以放弃自己的提交来支持你的提交，但这仍然是他们可能需要手动检查的事情。

就我个人而言，我建议直接合并他们的提交。如果您觉得它们基于太旧的 master 版本，并且合并将变得不必要的复杂或基于不合理的旧提交，那么让他们重新调整其 master 并重新获取。然后至少他们知道您要合并什么，并且解决代码中的任何冲突。

另外，我要警告不要追求不必要的线性历史。合并并行开发的开发人员分支可以让您更真实地再现历史。如果您在合并之前对开发人员的提交进行变基，那么您将不再拥有准确表示该开发人员修复和提交的代码状态的提交记录。这可能并不常见，但可能会发生两个提交交互产生错误，但不是合并冲突。如果你不重新设定基准，你就会得到更准确（也更公平！）的“指责”。