git经过大量重构后重新定位

问题描述

| 我有2个分支，分别是master和featureA。在featureA分支中，我在CoolFile.m中编写了一堆新代码。该功能尚未完成，因此该代码尚未准备好可以合并到master中。 CoolFile过去确实写得很差，所以在develop分支中，我对它做了很多更改（主要是重新排序方法，添加注释和删除空格）。 现在，我希望在不使用基础功能的情况下重新设置featureA，以便可以从清理的代码中受益。问题在于，由于所有方法都已四处移动，因此变基正在尝试将所有新代码放在错误的位置。解决此问题的最佳方法是什么？我应该等到功能完成才能重构吗？     

解决方法

        您可以将更改从master分支合并到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中。请记住，您仍然会遇到冲突，这些冲突只是替代基准选项的替代方法。 将来，我建议您直接在FeatureA上进行重构，或者从FeatureA分支的另一个分支中进行重构：

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

然后，在重构分支中合并为featureA只是小菜一碟，因为合并是微不足道的。     ,        我可能是错的，有点像git newb，但是rebase的工作方式是它从origin分支（在本例中为master）找到child分支的最新共同祖先，然后应用origin和然后将子分支的新提交提交到子分支（换句话说，就像您获得了最新的主分支一样，然后通过提交来重新创建分支）。所以等待对您没有好处，因为它将应用来自两个分支的所有提交。 我发现最好的方法就是硬着头皮做合并。与其他开发人员一起使用，以便您可以选择要解决合并冲突的代码。 我还发现，使commits小会使重新定级/合并变得容易。因此，不要重构x函数，然后提交，在每次重构后提交。真正要找到一个平衡点-不要提交每条线的更改，但在有意义的时候使提交尽可能小。