Table of Contents
Sometimes I end up making a lot of commits while I’m working on a branch in order to get the code right. It mostly happens when I’m going back and forth between my new branch and the old (live) one to double check some code that I think got lost. It happens when changing theme structures.
However. This left me with a conundrum. I had about 100 commits and really it was going to be the messiest pull request ever. Which I didn’t want.
One Branch to Rule Them All One Branch to Rule Them All
In order to fix this, finished up all my errant commits, as messy as they were, and then I went back and checked out the clean development branch (named
development). Since everything was up to date, I went and made a new branch.
That gave me three branches:
development– The actual dev branch
messy-dev– My super messy branch
clean-dev– My clean branch
Of course, nothing of mine was actually in that clean branch.
One Branch to Find Them One Branch to Find Them
Once I switched to my new branch (
git checkout clean-dev ) I imported my old branch with this:
git merge --squash messy-dev
Yep, that was it. I then went though all my regular checks, made sure the code was working, did a few more fiddly changes, and then I ran a
git commit to run the last pull.
This gave me a commit message filled with … well … this:
Merge branch 'development' into messy-dev commit 6c7534b9f7eabb5db59a85880bbf42ff2b982d84 Author: Mika Ipstenu Epstein <firstname.lastname@example.org> Date: Sat Sep 23 19:47:27 2017 -0700 Cards again commit 9fe21f380a1befcbbe34a79937399b679c31c06f Merge: 0362bb5 14b4fab Author: Mika Ipstenu Epstein <email@example.com> Date: Sun Sep 24 18:08:18 2017 -0700 I hate Sara Lance so much! commit 0362bb5a289e2694bd4872137ad470091529021d Author: Mika Ipstenu Epstein <firstname.lastname@example.org> Date: Sun Sep 24 17:57:33 2017 -0700
One Branch to Bring Them All One Branch to Bring Them All
Don’t worry. I didn’t keep that. In fact, I’d been writing a log of the entire work, listing out what was changed, fixed, added, deleted, etc. So I deleted that entire commit message and pasted mine in it’s stead.
Well written inline documentation is one thing, but a good commit message saves lives. Since I planned to submit this as a pull request, I knew I had to have a good, simple, commit that listed things that had changed.
But there also had to be more…
And In The Pull Request Bind Them And In The Pull Request Bind Them
I’m rather pedantic about all that and wrote about 500 words to explain what all the code was in that Pull Request. Since I’m working with other people, and I’m not the lead developer on this project, I know not to commit my changes to the dev server right away.
Instead, I made a pull request with a repeat of data in my commit, but also a different and more detailed explanation. A pull request has to explain why the work was done and why the pull is needed.