Five Git commands I started using that might be helpful to you

Git is a powerful tool I use every single day. Up until a few months ago I only used the bare minimum to get my job done. When I moved to a different company, with a much larger team, I quickly figured out there was so much of Git I didn’t know about and wasn’t using.

Nowadays I feel much more confident and I’ve learned a bunch of helpful new things! While I won’t go into the basics of Git, because there are many great resources out there to help you with that, I’d like to show you five commands that I think are very useful and may save you a few headaches. They certainly saved some for me.

Let’s dive in!

Amend: changing the commit after committing

You commit something and you immediately realize your commit message isn’t clear enough or doesn’t adhere to the commit message formatting rules of the project. Maybe you realized you needed to add one small change, like removing that silly little console.log(), or maybe you forgot to add a new file.

Does any of the above sound familiar? It definitely sounds familiar to me and has happened a few times! Luckily, there is a way for you to change, or rather update, your latest commit before you push it using --amend.

There are two parts to a commit that you may want to change, the first one is the commit message and the second one is a file. Let’s start with changing the commit message.

Changing the commit message

In it’s most basic form, the command to change your commit message looks like this:

git commit --amend

This will open your configured code editor for Git and allow you to change the commit message. You can, however, change the commit message without opening the editor:

git commit --amend -m "Your updated commit message"

Adding the -m flag, followed by the updated message in quotes, allows you to change the message without opening the editor.

Amending a change or file

Let’s say you notice a rogue console.log() after you’ve committed and you want to remove it. Edit the file and stage it like you normally would for a commit. Then run the following command:

git commit --amend --no-edit

This will amend the file to the commit. The —no-edit flag allows you to do this without changing the commit message.

⚠️ Caveat

Using —amend doesn’t change the commit. Instead, it replaces the commit with a brand new one. As such it is incredibly important you don’t amend public commits. Your local commits are perfectly fine.

Checkout: reverting a single file

Recently I did a pull request for a new feature I was working on. Part of my work was to remove some old styling in a legacy file. When I deleted the 8 lines of styling and hit save, I automatically ran prettier because that’s how I’ve set up my IDE.

The result was a little over a thousand changes making it impossible to figure out what it was that I actually changed myself. I completely missed this had happened and joyfully opened a pull request ready for review. Oops 😅.

I had to revert that file, make sure prettier wasn’t running, make my changes, save it, and commit it to the branch so it could be reviewed properly. Luckily git checkout comes to the rescue!

To revert a single file back to a previous commit, you run the following command:

git checkout <commit_hash> -- <path/to/file>

First find the commit that holds the changes you need to revert to, this is most likely 1 commit before the commit you need reverting, then figure out what the path to that file is (easiest way is to copy the relative path in your code editor).

Your file is now reverted to what it was on the commit you picked out. In my case: before I removed the styling and ran prettier. Phew, crisis solved 🥳.

Remote: add another remote repo

I’m going to outline this part with a hypothetical situation based on real events.

Imagine you are currently working on a new feature and you’ve got a co-worker, let’s call her Kate, who’s working on something that you need to integrate into your feature. You are both working in a fork of the central repository of your team and you need to pull in the latest changes Kate has made on her fork.

When you cloned your forked repository to your system, Git automatically created a remote connection named: origin. You may already know this, but did you know you can add Kate’s repository as a remote connection as well? This is great for when you want to pull in changes Kate made without her having to push to the central repository.

Let’s look at how to add Kate’s repository to your list of remote connections, we’ll go into fetching her changes in the next section. Here’s how to add her repository:

git remote add <name> <url>

The name can be anything you want. I usually stick to using my co-worker’s names or Github usernames. The url is the URL to her repository, for example: git@github.com:Kate/acme-fork.git. Putting that together:

git remote add kate git@github.com:Kate/acme-fork.git

If you run git remote, which will list all of the remote connections, you’ll see Kate’s remote repository.

Remote: fetching a branch from the remote branch

To fetch a specific branch from a specific remote, you run the following command:

git fetch <remote> <branch>

In the previous section we talked about adding Kate’s repository to your remote connections. Kate was working on something in a branch called new-feature. Using the above command, that would look like this:

git fetch kate new-feature

Running the command will fetch Kate’s branch and save them locally in kate/new-feature. What’s going on here is that remote branches you fetch are available using <remote-name>/<branch-name>.

To merge Kate’s changes into your branch, you have to git checkout your branch and then merge the branch you just fetched:

git merge kate/new-feature

Kate’s branch is now merged into your branch 👍.

Checkout: creating a branch based on another branch

I was recently working on rewriting a feature using a different library than the one in use on production. Aside from rewriting the code, new functionality needed to be added as well. I tackled this in two steps:

1. Rewrite the feature as it currently works in production and have my code reviewed to make sure I didn’t miss anything.
2. Add new functionality.

For step one I created a branch for the rewrite called feature-rewrite. Well it was a little more elaborate than that, but you get the point! You may be familiar with doing this from the CLI, but if not this is how you’d do that:

git checkout -b feature-rewrite

The -b flag tells Git to run git branch feature-rewrite if the branch doesn’t exist yet before checking out that branch, pretty neat 😄.

While I was waiting for the code to be reviewed, I continued with adding new functionality. This had to be done based on the rewrite I just did. In other words: I had to create a new branch based off of the feature-rewrite branch. Here’s how to do that:

git checkout -b new-functionality feature-rewrite

The checkout command takes a second parameter to let Git know what branch to base the new branch off of. To give you a clearer picture of this:

git checkout -b <new-branch> <existing-branch>

Final words

Over the past few months I have learned a lot of new things about Git and how you can use it to your advantage. The commands outlined in this post are by far the most useful and have been a real lifesaver for me.

Thank you for reading this post and I hope it’s been helpful!