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 didnt know about and wasnt using.

Nowadays I feel much more confident and Ive learned a bunch of helpful new things! While I wont go into the basics of Git, because there are many great resources out there to help you with that, Id 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.

Lets dive in!

Amend: changing the commit after committing

You commit something and you immediately realize your commit message isnt clear enough or doesnt 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. Lets start with changing the commit message.

Changing the commit message

In its 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

Lets say you notice a rogue console.log() after youve 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 doesnt change the commit. Instead, it replaces the commit with a brand new one. As such it is incredibly important you dont 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 thats how Ive 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 wasnt 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

Im going to outline this part with a hypothetical situation based on real events.

Imagine you are currently working on a new feature and youve got a co-worker, lets call her Kate, whos 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 Kates 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.

Lets look at how to add Kates repository to your list of remote connections, well go into fetching her changes in the next section. Heres how to add her repository:

git remote add <name> <url>

The name can be anything you want. I usually stick to using my co-workers names or Github usernames. The url is the URL to her repository, for example: [email protected]:Kate/acme-fork.git. Putting that together:

git remote add kate [email protected]:Kate/acme-fork.git

If you run git remote, which will list all of the remote connections, youll see Kates 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 Kates 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 Kates branch and save them locally in kate/new-feature. Whats going on here is that remote branches you fetch are available using <remote-name>/<branch-name>.

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

git merge kate/new-feature

Kates 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 didnt 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 youd do that:

git checkout -b feature-rewrite

The -b flag tells Git to run git branch feature-rewrite if the branch doesnt 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. Heres 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 its been helpful!

This post was originally published on my own blog: https://www.mikedecodes.com/blog/five-git-commands-i-started-using-that-might-be-helpful-to-you