git rebase after a big refactor

I have 2 branches, master and featureA. In the featureA branch I have written a bunch of new code in CoolFile.m . The feature isn't done so this code is not yet ready to be merged into master. CoolFile was really poorly written in the past so in the develop branch I commited a开发者_运维百科 bunch of changes to it (mostly reordering methods, adding comments, and deleting whitespace).

Now I want rebase featureA off of master so that I can benefit from the cleaned up code. The problem is that since all the methods have moved around, the rebase is trying to put all the new code in the wrong places. What's the best way to fix this? Should I have just waited until the feature was done to refactor?

You could merge the changes from the master branch into your featureA branch,

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

Lets assume you created featureA from commit B on master, and that C, D and E are commits made on featureA and F and G are the commits that reordered the methods etc. What you want to do now, is to merge F and G into the featureA branch.

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

Or, you could cherry pick the commits F and G into featureA. Remember that you will still get conflicts and that these are just alternatives to your rebase option.

In the future I'd recommend that you do the refactoring either directly on featureA, or from another branch, branching off from featureA:

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

Then it's a piece of cake to merge in the refactoring branch into featureA, since the merge would be trivial.

I could be wrong, being somewhat of a git newb, but the way rebase works is it finds the most recent common ancestor of the child branch from the origin branch (master in this case), and then applies the new commits of the origin and then the new commits of the child branch, onto the child branch (in other words, its as if you got the most recent master and then recreated your branch, commit by commit). So waiting will do you no good, since its gonna apply all the commits from both branches.

I find the best way is to this is to just bite the bullet and do the merge. Get the other developers with you so you can choose which code you want to resolve the merge conflicts.

I also find that making commits small makes rebasing/merging easier. So dont refactor x functions then commit, commit after each refactor. Its really about finding a balance -- dont commit every line change, but make commits as small as possible when it makes sense.