Git tip of the day: merge-base

Git tip of the day: merge-base

A coworker and myself were tasked to spearhead a large, extensive refactor for a well-established project.  The team was medium-sized (10ish people) and we followed a pretty tight Gitflow process, which overall, worked well.  The refactor was done out-of-band from our normal sprint cadence and like any new feature or defect, we created a branch off of develop and off we went.

After a few weeks of work – and hundreds of commits later – the refactor efforts were finished.  Once validated, we were ready to rejoin our comrades and merge our changes back into develop.  Per our usual process, we rebased our working branch with develop on a regular basis and proactively dealt with any conflicts.  Typically, once a feature or defect was complete, all commits were squashed into a single commit, via:

git rebase -i HEAD~<# of commits>

 In most circumstances, this is easy to do and allows us to map individual features/bugs to a single change, which can easily be rolled back, if necessary.

But for several weeks of effort, this would’ve been a more painful effort.  To package this up for review, rather than trying to figure out how many commits we were behind HEAD (to rebase and squash), we ended up resetting the index of our working branch to the upstream branch with git merge-base.  The actual command used was:

git reset $(git merge-base develop our-refactor-branch)

This effectively un-commits the differences between our working branch and develop, leaving it ready to be staged into a single commit (or more, if you desire).  Much better than counting and fixing up commits! 🙂

Leave Reply