If you're going to use a poor commit message, just git rebase -i instead

#git #beginners #programming #productivity

We've all been there.

Panic commits. You've spent HOURS on a problem only to solve it at the end of your day. The end of your sanity.

You know you want to save your work and commit it, but you've done so much brain-mashing that the eloquent commit message you had hours ago is lost to a sea of fog and quick-hacks.

it works.

Before you push, let's take a beat here.

Maybe you are trying some things and a rapid commit-cycle is more your style. You are a git-slinger. Pew pew pew!

You arrive at the same destination as above. Before you push, let's take a moment to reflect on your last N commits.

git commit rebase -i HEAD~{{number of commits you've done}}

As you know, I'm vehemently against rebasing public commits, but if it hasn't been pushed yet, the world is your oyster.

So, a rebase stacks the group of commits on top of your new "base" point, in which case, it's the commit you chose above.

HEAD is the latest commit and the number of commits before that selects the right ancestor. I know, it's some Marty McFly shit.

An interactive rebase gives you the ability to squash commits into each other (basically summating the changes into a single commit), reorder them, change their commit messages, and many more options.

In short, you can clean up that disaster you committed trying to solve that one thing by that one date.

Let me close by saying this one important thing:

Be careful.

Rebasing rewrites your git history. You can lose work if you aren't careful. When in doubt, just squash all of your commits instead of removing or reordering them until you get more comfortable with the operation.

For more about rebasing, check out: