Git best practices

Git is, in general, the most used version control system on the planet. With this tool, developers can collaborate and work much more easily. Git simplifies tracking code changes and implements speed, data integrity, and support for distributed, non-linear workflows.

In short, git takes what might otherwise be chaos in a developer's life and structures it in such a way that a project can be managed more easily and delivered more effectively.

If you and your team are just starting to use git, you're in for a surprise. And if you've been using git for a while, you may have worked with a team that doesn't take full advantage of this tool. No matter where you are on your Git journey, there are best practices you should apply every step of the way. By following this advice, your Git experience will not only be greatly improved, but collaboration will be smoother and more efficient.

Let's take a look at some of these best practices. They will apply regardless of the language you use with Git. So whether you're a Java, JavaScript, .NET, C++, Ruby, Python, or PHP developer, or you're working alone or in an enterprise-level team, these best practices apply.

Single-purpose commits

A commit is an operation that commits the latest code changes made to the source repository. A commit can be anything. Let's say you found a typo in your code. You fix the typo and create a commit. Commits make it easier for your team to know what you've done with the latest version of code.

One of the pitfalls of using them is holding them back until you've made a series of changes and then pushing a commit that covers all of those changes. When you do this, code review becomes less efficient. Instead, generate a commit for a single purpose, which:

• Makes code review more efficient.
• Makes it easier to revert code to a previous state.
• Tracks changes to a ticket system.
• Makes git log easier to view.

Write informative commit messages

A very important feature of commits is adding messages to them. These messages are informational, so your team has a clear idea of ​​what you did in the commit. If you just add a generic or meaningless commit message, you won't do the team any favors.

When creating a commit, be sure to add an informative message that clearly indicates the work you've done. Be concise, but also provide enough information that makes what you did obvious to everyone involved.

A useful commit might look like this:

 feature: added feature X

 ^--^ ^---------------^

 +-> Summary of a newly added feature.

 +-------> Type of feature added with the commit.

You must also be consistent with your commits. Your team should develop a style that makes it very easy to write these comments, as well as simple to quickly understand what was included in the commit.

Commit early and commit often

This goes along with single-purpose commits. You need to start adding your commits from the beginning and at regular intervals (probably whenever you make a change to the repository's code). Don't get out of the habit of committing, otherwise you will end up failing to follow single-purpose commit best practices, thus confusing your team or making them work harder than necessary.

Smash multiple commits

At some point, you will find too many single-purpose commits, making it a challenge to dig through the git repository. Think of it this way: if you have 100 commits for every feature branch you create, that can add up to a huge total. So instead of leaving all these unique commits as they are, squish them with the git rebase command. This will open an editor that lists the commits and allows you to act on them.

The goal is to keep your repository as informative and clean as possible.

Never change the story

Once you push a commit, you should never change it in your project history. When you do this, it becomes nearly impossible to maintain consistent control of version control. So even if you're tempted to use git rebase to squish commits, you should only do this on branches you're not using.

The branch you are working with must always remain with its full history (and commits) intact. This is so even if you made a big mistake in a commit. Please fix this error and create another commit to let everyone know the issue is resolved.

Use tags

A tag is a snapshot of the state of a branch at a given point in time. Think of a tag as a named pointer to a specific commit. This is very useful when you want to specify a point in a project's history as being important. For example, you might want to mark release points such as v1.0, v1.2, or v2.0. Tags make this easy.

Git makes it possible to create lightweight or annotated tags. A lightweight tag is like a branch that doesn't change, while annotated tags are stored as full objects in the Git database. Annotated tags can also contain a checksum, the tagger's name, an email address, the date, a tagging message, and can be signed and verified with GNU Privacy Guard (GPG).

The most used tag is the annotated tag.

Conclusion

Git is a tool that every software developer should use for version control. And when you adopt Git, it's important to configure and follow best practices to make sure your experience is simple and efficient.