Refactoring Git Branches - part II
This is a follow-up to Refactoring Git Branches - part I.
While coding on a feature we almost always stumble across areas of the code base that should be improved along the way.
If such an improvement is a larger change, I usually make a note to do it separately right after the feature I am currently working on. This helps me stay efficient by focusing on one task at a time, and prevents me from getting lost in concurrent changes happening at the same time.
Sometimes, however, it is just easier and faster to implement a small improvement like a syntax fix along the way, and so my feature branches can still end up implementing several independent changes. Reviewing such branches with multiple changes is harder than necessary, since it is much easier to talk about different topics separately than all at once.
Before submitting pull requests for such bloated feature branches, I usually do a
git reset master (assuming
master is the branch from which I cut my feature branch).
This undoes all the
git commit commands that I have done in my branch, and I am left with all changes from my feature branch uncommitted and unstaged.
Now it is easy to stage and commit only the lines that are actually related to my feature. I can do this using the git command line directly (through interactive staging of hunks), or through GUI tools like GitX or Tower. Then I commit unrelated changes into their own feature branches, even if they are small.
If my main feature depends on the peripheral changes made, I would first commit the peripheral changes into the current branch, then cut a new branch from the current branch and commit the actual feature into it. This way, the feature can use the peripheral changes, but both can be reviewed separately.
If we have a remote repo set up, since we are changing history here, we need to do a
git push -f on our old branch to overwrite the old commits on the remote repo.
This results in pull requests that are super focused on exactly one thing and nothing else, and are thereby much easier and faster to review.
This technique obviously only works for private feature branches. Never change Git history that other people use!