Question

我正试图理解Git中的变基，并且在这种情况下使用变基是否是一种好的做法存在疑问：

我有一个名为'feature'的分支，它从另一个名为'develop'的分支分支出来。我在'feature'中做了几次提交，但还没有与'develop'合并，因为该功能仍在开发中，'feature'中的提交也没有被推送到远程仓库。

如果我现在结帐'开发'以进行一些修正，将它重新设置为'feature'分支是否明智，以便'develop'与'feature'同步？

Answer 1

我会在'develop'上修改'feature'（当然，假设'feature'是一个本地分支）

将'develop'合并为'feature'会创建冗余合并提交。但是，使用rebase集成了master中的所有更改，并允许您在“feature”准备好与“develop”合并之前解决所有冲突，而不会创建任何额外的提交。

肯定有those who disagree。但我喜欢干净，可读的历史。我经常做的是，当我完成该功能后，我rebase，然后我merge --no-ff。这样，历史记录仍然清楚地表明有一个功能分支：

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

问题是我喜欢“不断”解决冲突。每当发生冲突时我都想早点知道它，所以我可以在它变得麻烦之前解决它（类似于持续集成的原因）。如果我遵循使用频繁合并的策略，我会有一个很多的合并提交。频繁的反叛我可以避免它们。

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

git config --global rerere.enabled true

As described in this article，然后您可以进行中间合并，解决冲突，然后重置合并提交。当您完成“功能”分支的最终合并时，rerere功能将使Git记住冲突解决方案。

Answer 2

以下将导致在 develop 分支上进行的所有提交，因为分割应用于功能分支，而不会影响 develop

现状：

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

选项1：将 develop 合并到功能中 git checkout feature; git merge develop

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

选项2（最初由Klas Mellbourn建议）：将功能转换为开发
git checkout feature; git rebase develop

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

rebase创建了更好的历史记录，但如果有其他基于功能的提交，则会出现问题。在你的情况下没有，所以这不是问题。

中添加一些提交

如果您无法执行上述操作（可能提交D1和D2尚未准备好进入功能），您可以使用git cherry-pick将提交复制到功能：

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

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

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

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

使用这样的图表主题可以合并到 develop 和功能中，而不会引入不需要的或重复的提交。