Mastering Git: Tips, Tricks, and Best Practices for Developers

Git is the industry-leading source control tool for developers. The distributed nature of Git allows every engineer to have a complete copy of the repository and its history locally. This means that common operations like commits, diffs, and logs can be examined on the user’s machine, and it serves as the backbone for many workflow processes—such as branching and merging—all without requiring access to a central server. Multiple developers can work simultaneously, resolve conflicts locally, and experiment without impacting the central source and breaking the build. Don’t break the build unless you want your teammates to be pinging you left and right.

In order to harness the true power of Git, let’s talk about some tips and tricks to take you to the next level. This may not seem like a big deal when you’re working on a project by yourself, but the more developers there are in your repository, the more thanks you will get for your discipline.

Sync your Feature Branch for a Clean Merge

Ever see a source control tree where you have super long-lived branches that hop over each other left and right? It looks like a tangled-up menorah. How about not doing that?

Here’s how you can do that.

1. Checkout your feature branch.

    git checkout FeatureBranch
   

2. Rewrite history so that your branch’s parent is origin/master

    git rebase origin/master
   

3. You’re likely to get some merge conflicts. Resolve the conflicts, stage the changes, then continue.

    git add —a
    git rebase —continue
   

Bam. Now you have a very linear history that makes it easier for your reviewers to see changes. Your pull requests will be simpler because your history is clean. Merge conflicts are resolved proactively, and thus less stressful. Your CI/CD process will be more reliable since you’ve already executed a build on your commit with the latest changes from the origin/master branch (you are running your unit tests locally, right? Right?).

Amend your commit

You’re already committing your changes often. Your parents would be proud. With so many plugins available in your IDE, it is easy to stage your changes, commit, and push. But that’s going to lead to some really long chains of commits in your pull requests. It can be quite difficult to review so many commits on one pull request. And then when you complete the pull request, you squash changes to make it look clean.
But what if you amend your first commit, so that all of your changes are already in one commit when you submit your pull request? Try adding --amend to your commit command to modify the previous commit, so you get one pretty commit and keep your history clean.

git commit --amend -m "amending the previous commit"

Push like normal. It is like merging with your previous commit.

Squash via Interactive Rebase

So you’re practicing the amend tactic I previously mentioned. But you make a mistake and now you’ve got a few commits on your feature branch that need to get squashed before you submit your pull request. You are not out of luck!

Interactive rebasing is powerful and allows you to change history by modifying the order of commits. You can leverage interactive rebasing to modify your commits and squash your changes on your local branch before you commit.

In my example, I created my branch and committed 3 changes with the messages “Change1”, “Change2”, and “Change3”. I then made sure I had no uncommitted changes and was checked out to the branch I wanted to squash. Knowing I had 3 commits to squash, I executed:

git rebase -i HEAD~3

This popped up vim and a list of the changes. Vim is not something I’m particularly strong in, but I know enough to be dangerous. It isn’t something you should be too intimidated by either.

Using your keyboard, move your cursor to each pick after the first one, and modify it to squash (or simply s) for each one. Then tap the escape key, type :wq, and press enter to write and quit Vim.

You’ll be taken back to your command line, and you’ll be all set to push to the origin.

I highly recommend that you practice this on a sandbox repository a few times to get the hang of working with vim and interactive rebase. As I said, interactive rebase is a powerful tool, making it very easy to mess up your repository.

Conventional Commits

I work on my own personal projects a lot, and I’m not immune to being in a rush to push out my commits with a bad commit message like “fixed bug” or “did stuff”. I’m not proud of it, but when you’re working with another developer, bad commit messages are flat-out unacceptable. There’s nothing more frustrating than trying to understand why a change was made, and then you see a commit message like “check in.”

We know we should be writing descriptive commit messages. It helps to have a reference work item associated with the commit. It also helps to know if it is a breaking change, just some refactoring, or even a bug fix.

I give you Conventional Commits. Now, I’m not a fan of reinventing the wheel, and when there’s a good pattern out there, I’m going to take advantage of it. It follows the same idea of “never roll your own auth.” Conventional Commits are a specification for writing your commit messages in a structured way that allows for consistency. Consistency leads to a well-documented history and enables automation in your repository.

You’re likely to get some resistance on this because no one wants to spend time writing commit messages. Set the example. Get to a point where, when it comes time for release note generation, you can tell everyone, “We don’t even have to write it if we can just parse the commits.”

Stash

I sometimes forget about the ability to stash changes. In a professional setting, interruptions happen all the time. To be honest, I can’t remember the last time I had an hour to myself during working hours without a message, phone call, or meeting. I’m context switching regularly.

When you context switch, your focus changes. You may be developing a new feature in your repository, and in that same repository, there’s a bug that needs to be fixed immediately. But you don’t want to commit to your branch because maybe it isn’t done, and you don’t want to break the build.

Stash. Stash is the perfect name for what it does. Your changes are retained, but not committed to history.

git stash push "WIP: Writing new feature"
git stash list
git stash apply stash@{1}
git stash drop stash@{1}

It is almost like having source control for your source control. Clearly, you can see how it’d be easy to build up a catalog of stashes. So make sure you learn all of the basics of the stash command and make it easier on you.

Closing

Git is an amazing tool. However, I feel like 90% of the time, we only use 10% of its features. In doing so, we can get some really messy source control. Now, I know I’m the one who is telling you to rewrite history a lot here, but there’s something so satisfying about a clear, easy-to-understand Git history. Make sure your team has a clear working agreement and understanding of your branching strategy. Push yourself to use Git via the command line so you can truly understand what’s happening under the hood. Plus, most of the time, your IDE assistants are just executing commands anyway.

Having a mastery of source control can help set you apart from other developers.