3

我试图理解 Git 中的变基，并且有一个问题，在这种情况下使用变基是否是一种好习惯：

我有一个名为“feature”的分支，它是从另一个名为“develop”的分支分支出来的。我已经在“功能”中进行了几次提交，但尚未与“开发”合并，因为该功能仍在开发中，“功能”中的提交也没有被推送到远程存储库。

如果我现在检查“开发”以进行一些修改，将其重新定位到“功能”分支以便“开发”与“功能”同步是否明智？

4

2 回答 2

6

我会在“开发”上重新设置“功能”（当然，假设“功能”是本地分支）

将“开发”合并为“功能”会创建冗余的合并提交。但是做 rebase 会集成来自 master 的所有更改，并让您在 'feature' 准备好与 'develop' 合并之前解决所有冲突，而无需创建任何额外的提交。

当然也有人不同意。但我喜欢干净、可读的历史。我经常做的是，当我完成这个功能时，我rebase，然后我merge --no-ff。这样历史仍然清楚地表明存在一个特性分支：

- * - * - - - - - - - * - * -
       \             /
        * - * - * - *

问题是我喜欢“不断地”解决冲突。每当发生冲突时，我都想尽早了解它，以便在它变得麻烦之前解决它（类似于持续集成的原因）。如果我遵循使用频繁合并的策略，我将有很多合并提交。通过频繁的变基，我可以避免它们。

有一种替代策略可以让您使用合并但没有合并提交 - 您可以打开 git rerere：

git config --global rerere.enabled true

如本文所述，然后您可以进行中间合并、解决冲突，然后重置合并提交。rerere 功能将使 Git 在您对“功能”分支进行最终合并时记住冲突解决方案。

于 2013-06-21T10:46:16.683 回答
3

将所有提交添加到功能

以下将导致自拆分应用于功能分支以来在开发分支上所做的所有提交，而不影响开发。

当前状态：

M1---M2---D1--D2--T1--T2  develop
      \
       F1--F2  feature

选项 1：将开发合并为功能
git checkout feature; git merge develop

M1---M2---D1--D2--T1--T2  develop
      \                \
       F1--F2-----------F3  feature

选项 2（最初由 Klas Mellbourn 建议）：rebase feature to develop
git checkout feature; git rebase develop

M1---M2---D1--D2--T1--T2  develop
                       \
                        F1'--F2'  feature

这rebase创建了一个更好的历史记录，但如果有其他基于feature的提交，那就有问题了。在你的情况下没有，所以这不是问题。

添加一些提交到功能

如果您不能执行上述操作（可能是提交D1并且D2还没有准备好进入功能），您可以使用git cherry-pick将提交复制到功能：

M1---M2---D1--D2--T1--T2  develop
      \
       F1--F2--T1'--T2'  feature

Agit rebase会移动提交，而不是复制它们。

单独的主题分支

另一种工作流程是在基于早期共同祖先的新主题分支中进行新提交：

       T1--T2  topic
      /
M1---M2---D1--D2  develop
      \
       F1--F2  feature

有了这样一个图表主题，我可以在不引入不需要或重复的提交的情况下合并到开发和功能中。

于 2013-06-21T10:33:28.873 回答