Let's say I have a feature (topic) branch that I keep rebased on top of my development branch. During the course of the project (before merging in my feature branch), I decide that I need to make a large refactor to my project (for example, after updating a 3rd part module).
So I do this large refactoring on my development branch. Now I want to rebase my feature branch so I can take advantages of my refactoring.
There are still things in my feature branch that need refactored to match the changes I made in my development branch.
Go back through my feature branch's history trying to edit commits (with
rebase -i) to make the branch look as though all of the work had been done after the refactoring.
- The advantage to this is that it keeps the history clean.
- The disadvantage is that this can take a whole lot of time if the changes made in the development branch cause a lot of changes to need to be made in the feature branch.
Fix the things that need to be refactored in my feature branch and make a commit for this.
- The advantage here is that it will be much easier to identify and fix things that need to be fixed
- The disadvantage is that now the tree will have two commits in it for the refactor. One for the refactor done for the entire development branch, and a smaller commit done for the feature branch, once merged in it will look a little funny.
Which strategy should I go with?
Lets say on the development branch I rename
Now In my feature branch I've never modified the file containing
functionB in development). So when I run
rebase development while on my feature branch it rebases cleanly.
The problem is if I've ever made a call to
functionA in my feature branch, it's going to fail now since it was renamed
Now, should I just do a find and replace for
functionB and make one commit on the feature branch (option 2). Or should I go back through my history, finding where I introduced the call to
functionA and rewrite the commit so it is introduced as calling
functionB (option 1)?