Git tricks

During my journey as a developer, I've come across a couple of git tricks that I found helpful in making my life as a developer slightly easier and so, I wanted to share them with everyone:

1. Forgot to commit and now have a long commit message?

Getting into the flow of things, sometimes I race down the path of adding change after change after change forgetting to commit. To resolve this I used to create long commit messages with a bunch of + signs to split different messages up.

So, my commit would look something like this:

git commit -m "first change + second change + third change"

This was fine, but then as my messages got longer it got annoying for me to read things that way (And I imagine it was annoying for code reviewers as well).

I found a simple hack to split one commit message onto different lines to allow for a slightly better reading experience:

git commit -m "first change" -m "second change" -m "third change"

This splits one commit message onto seperate lines, and when you expand the message of your commit in your PR it's much cleaner to read.

2. Pushing with long branch names

Sometimes at work I have to create long branches to track ticket ids, etc. So my branches can look something like:

1234567849383475-adding-prettier-and-formatting-code

Now, you can imagine how annoying this got when finally pushing my changes and having to re-type the whole ticket id, or copy/paste it.

My hack around this was to just push to the HEAD.

So instead of:

git push origin 1234567849383475-adding-prettier-and-formatting-code

I can go:

git push origin HEAD

Where HEAD points to the top of the current branch you're on.

3. Switching to your previous branch

Very rarely (but still occassionally) I switch between branches when I have to put stuff on hold and work on another issue.

In those scenarios, I found it useful to use:

git checkout -

which essentially goes to the last branch you were on.

4. Undoing all changes on a commit

Sometimes when I work on a commit, I want to completely delete all changes and start from my last commit. In that scenario I find it super easy to just go:

git checkout .

Which clears all uncommitted changes and just lets me start over from my previous commit.

5. Git tags

Which scheduling deployments, I would go through the following steps:

1. Dig through slack messages to find the last deployment ID
2. Digging into the continous integration pipeline to find the same deployment ID so that I can find out the last PR that made it into production.
3. Go back to github, and find the delta between what's on production and what I plan to deploy.

This way I know what manual tests to run after making a deployment and can share them with my team to do the same.

However, as you can imagine this was annoying.

So, instead of chasing down all these numbers, I learned about creating git tags.

Git tags are an easy way to create a release package that is marked with a commit that you choose. By using them it's super easy to track the last PR/commit that made it into production, relieving me of having to dig through slack and the CI pipeline just to find the last PR.

To use them, run the following command before you plan to make a deployment:

git tag "name-of-your-release-tag"

This will then create a tag under the release tab on your github repo that's easy to access whenever you need that information.

You can do a lot of other cool things with git tags like back-track and create tags on specific commits, or add annotations to add more information to your tags.

But more on that later.