4

我有 2 个分支，master 和 featureA。在 featureA 分支中，我在 CoolFile.m 中编写了一堆新代码。该功能尚未完成，因此此代码尚未准备好合并到 master 中。CoolFile 过去写得非常糟糕，所以在开发分支中我对其进行了一系列更改（主要是重新排序方法、添加注释和删除空格）。

现在我想从 master 中 rebase featureA，这样我就可以从清理过的代码中受益。问题在于，由于所有方法都已移动，rebase 正试图将所有新代码放在错误的位置。解决此问题的最佳方法是什么？我应该等到功能完成后再重构吗？

4

2 回答 2

1

我可能是错的，有点像 git newb，但是 rebase 的工作方式是它从源分支（在本例中为 master）找到子分支的最新共同祖先，然后应用源的新提交和然后子分支的新提交到子分支上（换句话说，就好像您获得了最新的主分支，然后重新创建了您的分支，逐个提交）。所以等待对你没有好处，因为它会应用来自两个分支的所有提交。

我发现最好的方法就是硬着头皮进行合并。让其他开发人员与您一起，以便您可以选择要解决合并冲突的代码。

我还发现使提交变小可以更容易地重新定位/合并。所以不要重构 x 函数然后提交，在每次重构后提交。它实际上是为了找到一个平衡——不要提交每一行更改，而是在有意义的时候尽可能少地提交。

于 2011-05-30T22:29:46.370 回答
1

您可以将主分支中的更改合并到您的 featureA 分支中，

A--B--F--G--H master
   \
    \-C--D--E featureA

假设您从 master 上的提交 B 创建了 featureA，并且 C、D 和 E 是在 featureA 上进行的提交，而 F 和 G 是重新排序方法等的提交。您现在要做的是将 F 和 G 合并到featureA 分支。

$ git checkout featureA
$ git merge G (G is the sha1)

或者，您可以将提交 F 和 G 挑选到 featureA 中。请记住，您仍然会遇到冲突，并且这些只是您的 rebase 选项的替代方案。

将来，我建议您直接在 featureA 上进行重构，或者从另一个分支（从 featureA 分支）进行重构：

A--B--F--G--H master
   \
    \-C--D--E featureA
         \
          \-I--J--K refactorFeatureA

然后将重构分支合并到 featureA 中是小菜一碟，因为合并将是微不足道的。

于 2011-05-30T22:38:20.943 回答