Question

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

我希望在大多数情况下保持提交历史呈线性，因此在集成更改时，可以执行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'转移'coworker'分支。我的意图恰恰相反，将“同事”提交放在主人之上。所以我更新了这个例子。

Answer 1

你绝对不想按照你的建议行事，它会将master分支重新绑定到同事master上。根据您的同事master所基于的内容，您最终可能会倒退中央master。

你可能想要做的事情恰恰相反，在将你的同事合并到主人面前之前，要重新定位你的同事。

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

但是，我仍然不会推荐这个。你的同事必须解决你如何重新定义他们的变化。大多数情况下，它可能是微不足道的，他们可以抛弃他们的提交而支持你的，但它仍然可能需要手动检查。

就个人而言，我建议直接合并他们的提交。如果你觉得它们是基于太老版本的master而且合并会不必要地复杂或基于一个不合理的旧提交，那么让他们重新定义他们的master并重新获取。然后至少他们知道你在合并什么，他们解决了他们代码中的任何冲突。

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

Answer 2

关于git的绝大多数文档和教程都清楚地表明，rebase只应该在私有分支上使用，而不是别人可以看到的东西。在你的模型下，我会非常害怕莫名其妙的失败或不得不在其他复制品上重复工作。避免！

Answer 3

对于琐碎的案例，这将是一个可接受的工作流程。当你的同事做git pull时，它实际上是git fetch后跟git merge。 Git非常擅长合并，并且能够毫无问题地解决简单案例。

但是，如果你必须做任何工作来解决git rebase步骤中的冲突，那么你的同事可能必须在他们拉动时再次做。之所以会发生这种情况，是因为你的提交序列在变基之后与他们的提交有很大的不同。

如果您对非线性历史感到满意，Git可能会更好地管理这个工作流程（因为这是它的设计目的）。

Answer 4

如“A truce in the merge vs. rebase war?”文章所述，（强调我的）

传统变基的最大问题可能是阻止协作 在重新定位之前和之后从存储库中提取的人将会遇到冲突，因为这两个历史相互矛盾。因此标准警告“不要在已发布的存储库中进行重新定义”，这可以改写为“不要在以后可能需要重新设计的工作上进行协作”。

即使它由于没有冲突而“有效”，如果你必须在你的rebase期间解决任何非平凡的合并，它可能会导致一些麻烦：

M0----M1----M2
\
 \
  \
   B1----B2

M0----M1----M2
            \
             \
              \
               B1'---B2'

您（之前发布的）分支的SHA-1被重写，您的同事将很难在其环境中合并该分支。

Answer 5

我对这个工作流做了一些简单的测试。我同意Charles的帖子，但想添加一些其他信息。

<强>赞成

工作流程不会破坏用户从公共仓库中撤出。
它可以让您更好地控制提取到主线的提交。
更容易遵循主线分支的功能历史记录。如果必须执行合并提交（标准工作流）以提取多个更改，则合并提交会将所有新提交的修改分组到单个提交中。这打破了“一提一个功能”的习惯用法。

<强>缺点

在您要撤消更改的仓库中，“原始”提交仍会显示。除非他们知道你在做什么，否则这可能会给贡献者增加混乱。我想有一种解决方法就是让你的贡献者在你拉动并重新装上它之后扔掉他们的dev分支。
如果远程仓库在重新绑定后没有丢弃他们的dev分支，那么它会使主分支历史难以跟随远程分支。
在rebase之后，您在提交时松开了原始作者姓名。（也许有一种手动方式可以解决这个问题。）这使得追踪每个变更的人更加困难。

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

5 个答案: