How to Really Use Git: 10 Rules to Make Git More Useful

Version control can be an incredibly helpful tool: it provides a safety net for mistakes, lets you understand how your project evolved - and, ultimately, it gives you the power to take the quality of your software development process to a whole new level.

But only if you know how to use version control and Git effectively. Here are 10 rules that can help you!

1. Commit Related Changes

A commit should be a container for related changes. "Related", in this context, means that only changes that belong to the exact same topic should be bundled in the same commit. Why? Because it's much easier to understand a commit if it's only about a single topic - and not a multitude of different things.

As a nice side-effect, this also produces smaller commits. This makes it easier for other developers to understand the changes (and roll them back if something went wrong). To make a simple, practical example: fixing two different bugs should happen in two separate commits!

Luckily, Git offers helpful tools that allow us to work in such a granular way:

1. The Staging Area, which allows you to decide which parts or even lines exactly you want in your next commit.
2. The Stash, which helps you save changes you don't need at the moment on a temporary clipboard.

2. Commit Often

Why should you commit often? Mainly for two reasons:

1. Smaller commits: You will end up with smaller commits, compared to committing only rarely, when lots and lots of changes have accumulated. Again: smaller commits are easier to understand for your teammates (and yourself, after some time).
2. Frequent sharing: You will be able to share your code more frequently with others on your team. This makes it easier for everyone to integrate your changes regularly and avoid merge conflicts. If, in contrast, you commit only rarely, you will share your code less often - which will make merge conflicts not only more frequent but also harder to solve.

3. Never Commit Half-Done Work

Code should only be committed once it's really completed. This does NOT mean that you have to complete a whole, large feature before you commit. Quite the contrary, actually: you should split the implementation into logical chunks and commit early and often. But you shouldn't commit just so you have something in the Git repository before leaving the office at the end of a long day.

Another situation that tempts us to commit half-done work is when we need a clean working copy (e.g. when we have to check out a different branch, pull, or merge...). But instead of committing, such a situation can be easily solved by storing your local changes on Git's “Stash”.

4. Test Before You Commit

Closely connected to rule #3 is this one: we should resist the temptation to commit something that we “think” is completed. Many teams publicly define their "definition of done" to include tests. But even if it's not taped to your office walls, it's still a good idea to test your code thoroughly before committing it. This will help you make sure it's really complete and has no side effects.

Your teammates will appreciate every minute you invested in testing your code. Because it reduces those highly frustrating situations where you pull in changes from your colleagues - only to find that the code is not working anymore ☹️🤯

5. Write Descriptive Commit Messages

Apart from the actual code, a commit's message is the only piece of information that helps people understand what happened. This makes commit messages a very important topic!

You should begin your message with a short summary of your changes (up to 50 characters, as a rough guideline). It helps to separate this little summary from the following text by including a blank line: if you do so, most tools will understand that this first line is the "subject", while the rest is the "body" of the message (similar to an email).

The message's body should provide detailed answers to the following questions:

• What was the motivation for this change?
• What aspects of the previous implementation does it change? To be consistent with automatically generated messages from commands like "git merge", you can use the imperative, present tense („change“, not „changed“ or „changes“).

6. Don't Mistake Version Control for a Backup System

Sometimes, it's tempting to use Git as a backup system. And while this is certainly one of the benefits of using a version control system, it's definitely NOT its main job!

If Git was mainly a backup system, you could just cram in your files and changes whenever and however they emerge.

But version control, by contrast, is all about giving your commits semantic value! It's about creating granular, precise commits that belong to just a single topic per commit.

7. Use Branches Extensively

When Git was designed, it was a core requirement to make its concept of "branches" quick, easy, and robust. If you're coming from other version control systems, you know that most other systems' understanding of branches doesn't match this description! In most other VCS, branching is either slow, complicated, or it doesn't exist at all!

In Git, however, branching is one of the most important features - and this is not an exaggeration! Branches in Git are the perfect tool to help you avoid mixing up different lines of development. Anytime you need it, they provide you with a separate container for your new work. This makes it incredibly easy and safe to experiment with new code and features - without running the risk of blocking the team with bugs that new code inevitably contains.

Use branches extensively in your development workflows: for new features, bug fixes, ideas…

8. Agree on a Workflow in Your Team

Git doesn't force you into any particular workflow. You can use one or multiple long-running branches, topic branches for your feature work, merge instead of rebase, use git-flow… but you don't have to! Which ingredients you choose depends on many factors: your project, your overall development and deployment workflows, and (most importantly) your team's personal preferences.

But however, you decide to work in the end: make sure to document this workflow somewhere and hold every one on the team accountable to follow it!

9. Learn More Than the Basics

You can surely "survive" by knowing just a handful of Git commands. But you'll be missing out on so much of Git's power if you don't learn about the advanced features! To make only three examples:

• The Reflog can help you find seemingly lost commits. This can be tremendously helpful when you just "deleted" some commits that you shouldn't have!
• Interactive Rebase can help you clean up your commit history before you share it with your team. This makes for a much cleaner and easier-to-understand codebase in the long run!
• Undoing mistakes is a core skill for every software developer. Git allows you to undo almost anything, but you have to learn the tools and commands to do this.

If you invest some time to go beyond the basics, you'll be rewarded with better productivity - and ultimately a better software development process.

10. Choose Tools that Make You More Productive

Today, the ecosystem around Git is full of powerful tools and services: from code hosting services like GitHub, Gitlab, and Bitbucket all the way to Git desktop GUIs like Tower.

Choose your tools carefully, because they can help you become more productive with Git and access its advanced features more easily.

About the Author

Bruno Brito is the Content Marketing Developer of Tower, the popular Git desktop client that helps more than 100,000 developers around the world to be more productive with Git.