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函数,然后提交,在每次重构后提交。真正要找到一个平衡点-不要提交每条线的更改,但在有意义的时候使提交尽可能小。     

要回复问题请先登录注册