Git Yourself Out of Trouble with These Handy Commands

One of the most crucial skills to have when working on software projects is navigating Git, the seemingly-ubiquitous revision control system. Unfortunately, it’s not something most developers get to practice much in school. Instead, we’re often forced to learn on the job with a large codebase. Merge conflicts, divergent branches, and complicated rebases can cause any inexperienced dev to sweat, and the plethora of commands and options can be overwhelming.

Accidentally committing code you didn’t mean to, pushing to the wrong branch, and incorrectly resolving merge conflicts are mistakes almost every developer has made. But that’s the beauty of version control! There is (almost) always a way out. Once you understand the basics of adding, committing, and merging code, you might feel like you know just enough to get yourself into trouble… but not enough to get yourself out.

Below are some handy Git commands that have helped me out of sticky situations that I hope will help you too!

Git commands to prevent yourself from committing bad code:

git diff

To keep your pull requests free of console logs and commented-out solutions that didn’t work, it is good practice to look over all your changes before you commit (and definitely before you push!). Running git diff will show you all of the changes in your local version, so you can decide which changes to stage and which files might need some more editing first. A useful option for this command -—cached which will show only changes that have been staged rather than all local changes.

git add --patch

This is a great Git command for new developers because it forces you to view your changes before staging them. It’s easy to get in the habit of staging all modified files with git add .. However, it is also easy to make mistakes that way. With the --patch option, Git will divide your local changes into small “hunks” of code and allow you to interactively choose which hunks you would like to stage and which you would like to skip. It supports a wide range of other options as well — including editing a hunk manually and splitting the current hunk into smaller hunks.

Git command to to fix a commit when you included code you didn’t mean to anyway (or left something out):

git commit --amend

Even using the commands described above, sometimes a small change gets left out of a commit or we accidentally commit something we didn’t mean to. Never fear! If you have not pushed the commit, changing it is as simple as staging your changes and running git commit --amend. This will also allow you to amend your commit message. Alternatively, you can use the --no-edit option to amend a commit and keep the same message. Note: if you have already pushed the commit you would like to amend, you still can, but you will have to force push the branch to “rewrite history.”

Git command to to remove a commit you didn’t mean to make:

git reset <commit>

If you find that you’ve gone down a path that leads you to compiler errors and despair, you may reach a point where you want to just start over. If you feel this way, but you have already committed changes, a reset can help. With this command, you can reset a branch to a previous commit by replacing <commit> with a specific commit hash (which you can find by running git log) or go back by a single commit by replacing <commit> with HEAD~1. In addition, you can use the --soft and --hard options to specify whether you’d like to keep your changes as local (uncommitted) work on reset (soft reset) or discard them altogether (hard reset).

Git command to to apply your commit to a different branch:

git cherry-pick <commit>

Sometimes despite our best intentions, we lose track of what we’re doing and commit to the wrong branch. Amending this situation can seem daunting, but it is actually quite easy to resolve with cherry-picking. Using `git log` you can find the commit hash for the commit(s) you want to apply to the correct branch. Then switch to that branch and run the above command, replacing <commit> with the hash(es) of the commit(s) you’d like to apply. Running git log again will show you that the commit(s) were applied. Then you can switch back to the other branch and remove the incorrect commit(s) using git reset.

Git command to rewrite history:

git push --force-with-lease

When you make local changes that will change the commit history of the remote branch to which you are pushing, your push will be rejected unless you use the --force option. Force pushing is dangerous because it replaces the remote branch with your local changes. Using the --force-with-lease option provides at least some amount of safety against pushing to a remote branch that has changes you haven’t pulled in to your local copy (see this post for more info).

I hope these commands are helpful to any other Git newbies out there. Good luck and happy coding!