Git is, by and large, the most widely used version control system on the planet. With this tool, developers can much more easily collaborate and work efficiently. Git makes it simple to track code changes and implement speed, data integrity, and support for distributed non-linear workflows.
In short, git takes what could otherwise be chaos in a developer’s life and structures it in such a way that a project can be more easily managed and more effectively delivered.
If you and your team are just now starting to use git, you’re in for a treat. And if you’ve been using git for a while, you might have found yourself working with a team that doesn’t quite make the most of this tool. No matter where you stand in your git journey, there are best practices you should be applying at every step along the way. By following such advice, your experience with git will not only be much improved, but collaboration will be smoother and more efficient.
Let’s take a look at some of these best practices. These 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 if you’re working solo or on an enterprise-level team, these best practices will apply.
Single-purpose commits
A commit is an operation that sends the latest code changes you’ve made to the source repository. A commit can be anything. Say you found a typo in your code. You fix the typo and you create a commit. Commits make it easier for your team to know what you’ve done to the latest version of the code.
One of the traps of using these is holding back on them until you’ve made a number of changes and then submitting a commit that covers all of those changes. When you do this, it makes code reviewing less efficient. Instead, generate a commit for a single purpose, which:
- Makes code review more efficient.
- Makes it easier to roll back code to a previous state.
- Tracks changes in a ticketing system.
- Makes git log easier to view.
Write informative commit messages
One very important feature of commits is adding messages to them. These messages are informative, so your team has a clear idea of what you did within the commit. If you just add a generic or nonsensical commit message, you do the team no favors.
When you create a commit, make sure you add an informative message that clearly indicates what work you did. Make it concise, but also give it enough information that makes what you did obvious for 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 should 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 understand, at-a-glance, what went into the commit.
Commit early and commit often
This goes along with the single-purpose commits. You need to start adding your commits from the very beginning and at regular intervals (most likely, every time you make a change to the code in the repository). Don’t get out of the habit of committing, otherwise, you wind up failing to follow the single-purpose commit best practice, thereby confusing your team or making them work harder than necessary.
Squash multiple commits
At some point, you’re going to find too many single-purpose commits makes it a challenge to comb through the git repository. Think about it this way: If you have 100 commits for every feature branch you’ve created, that can amount to a massive total. So, instead of leaving all of those single commits as is, squash those commits with the git rebase command. This will open an editor that lists commits and allows you to act on them.
The goal is to keep your repository as informative and as clean as you can.
Never alter the history
Once you’ve submitted a commit, you should never alter it in the history of your project. When you do this, it becomes next to impossible to keep consistent track of version control. So even if you’re tempted to use git rebase to squash commits, you should only ever do that on branches you aren’t using.
The branch you are working with should always be left with its full history (and commits) intact. This is so, even if you’ve made a big mistake in a commit. Fix that mistake and create another commit so everyone knows the problem has been resolved.
Use tags
A tag is a snapshot of a branch’s state at a given 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 either lightweight or annotated tags. A lightweight tag is like a branch that doesn’t change, while annotated tags are stored as complete 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 widely-used tag is the annotated tag.
Conclusion
Git is a tool every software developer should be using for version control. And when you do adopt Git, it’s important that you set up and follow best practices, so you can be sure your experience is both painless and efficient.
