5

我正在使用集成器工作流程管理一个 git 存储库。换句话说，我从我的同事那里提取提交，并将它们推送到受祝福的仓库中。

在大多数情况下，我想保持提交历史是线性的，那么当我集成更改时可以做 arebase而不是 a吗？merge这是一个例子：

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

我担心远程仓库在执行 next 时会发生什么git pull。git 是否能够处理这个问题，或者coworkerrepo 在 期间会失败pull，因为提交在origin?

更新：我最初的示例是从“master”重新定义“coworker”分支。我的意图恰恰相反，将“同事”提交放在主人之上。所以我更新了这个例子。

4

5 回答 5

3

你绝对不想按照你的建议去做，它会将master分支重新定位到你同事的master. 根据你同事的master基础，你最终可能会经常倒带 central 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 并重新获取。然后至少他们知道你正在合并什么，并且他们解决了他们代码中的任何冲突。

另外，我会告诫不要瞄准不必要的线性历史。合并并行开发的开发人员分支可为您提供更真实的历史表示。如果您在合并之前 rebase 开发人员的提交，那么您将不再拥有准确表示该开发人员修复和提交的代码状态的提交记录。这可能并不经常发生，但可能会发生两个提交交互产生错误，而不是合并冲突。如果你不 rebase，你会得到一个更准确（更公平！）的“责备”。

于 2009-08-13T22:05:50.330 回答
1

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

于 2009-08-13T22:26:37.363 回答
0

对于琐碎的情况，这将是可接受的工作流程。当您的同事执行 agit pull时，实际上是 agit fetch后跟 a git merge。Git 非常擅长进行合并，并且能够毫无问题地解决简单的案例。

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

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

于 2009-08-13T21:59:47.583 回答
0

正如“合并与变基战争中的休战？ ”文章中所述，（强调我的）

传统的 rebase 最糟糕的问题可能是它阻碍了协作。
在变基之前和之后从存储库中提取的人会遇到冲突，因为这两个历史相互矛盾。因此，标准警告“不要在已发布的存储库中变基”，可以将其改写为“不要在以后可能想要变基的工作上进行协作”。

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

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

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

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

于 2009-08-13T22:01:18.407 回答
0

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

优点

  • 该工作流程不会破坏从您的公共回购中提取的用户。
  • 它使您可以更好地控制被拉入主线的提交。
  • 更容易跟踪主线分支的功能历史。如果您必须执行合并提交（标准工作流程）来拉入多个更改，那么合并提交会将所有新提交的修改分组到单个提交中。这打破了“一个提交一个功能”的习语。

缺点

  • 在您从中提取更改的存储库中，“原始”提交仍将显示。这可能会增加贡献者的困惑，除非他们知道你在做什么。我想解决这个问题的一种方法是让贡献者在你拉动和变基后扔掉他们的开发分支。
  • 如果远程仓库在你变基后没有丢弃他们的开发分支，那么它会使主分支历史难以跟随远程分支。
  • 在 rebase 之后，您在提交上失去了原始作者的姓名。（也许有一个手动的方法来解决这个问题。）这使得跟踪谁提交了每个更改变得更加困难。
于 2009-08-25T23:29:25.903 回答