Git Best Practices — AFTER Technique

DZone 's Guide to

Git Best Practices — AFTER Technique

There are over thirty git best practices to commit to memory, whch can be a little difficult. Luckily, using the AFTER technique makes it easier.

· DevOps Zone ·
Free Resource

Git is an essential and popular version control system.

It has many powerful features like distributed version control system and easy to use. Also, it offers a powerful branching strategy and much more. Also, many git best practices help to use Git more effectively and productively.

In simple words, best practices help you decide strategies that are right for you. Also, help you to maximize your productivity and focus on what’s most important.

The idea is you should follow the best practices for many good reasons. But the truth is many times these practices don’t work. Why?

There are too many to follow. For example, there are more than 35 Git best practices that are there, and as a newbie, it's hard to remember every single practice. 

Solution? The AFTER technique.

AFTER Technique 

AFTER technique is based on git best practices. This technique is not new, and this simple technique helps you to stay productive and organized.

I will share the AFTER technique which helped me to boost my productivity and overall quality of your code within seven days up to 80%

A — Atomic Commits

One of the important and without a doubt, best practices in any version control is to keep your commits atomic.

Atomic commit = one commit for one change.

Here are a few examples of atomic commits:



git commit -m "Add JS validation to the user signup form"

So anyone looks at this commit can tell its purpose. To add the JavaScript validation on a user signup form.

Let us take an example of another atomic commit. 



git commit -m "Style sheet added for the user signup form"

It is indicating commit for the style sheet.

Atomic commits are adding value to the quality of your product. Also if you work on an atomic task, it helps you to stay focused. 

With atomic commits — code reviews are more straightforward. Also, it makes rollback easy to manage (if required). 

F — Frequent Commits

The second rule of AFTER technique is F — Frequent commits. Anytime I complete a part of code that compiles and runs, I prefer to commit.  

I wouldn't worry about making "too many" commits. There is no such rule that says you can not commit more than 10 times in a day or so. Early commit helps to minimize the risk of conflicts between two concurrent changes. Additionally, having periodic checkpoints means that you can understand how you broke something.

T — Test Before You Commit/Push Your Changes

I have never met any programmer who can write perfect code. To err is human.

It's important to test code before you commit and especially push to the remote repository. I notice many developers say, "My code runs perfectly, why do I need to test?"

But the truth?

Code can break, and probably a perfect programmer does not exist. We all are human and can mistake. So testing is a must. 

E — Enforce standards

Adopting standards are essential. They accelerate overall quality, and there is no doubt that full compliance always minimizes errors and delays. These standards depending on the team and other factors. 

There are two basic standards that you can always enforce in your team.
Use of git Ignore file

  • It helps to ignore predefined files and directories like config files, user settings, and other unwanted files.
  • The repository stays in a healthy condition. 

There must be a message with every commit and pull request.

  • Commit message helps to review the code.
  • Useful message acts as documentation for developers.

You can enforce these standards by server-side or client-side hooks.

R — Refactoring Is Not a Feature

Code refactoring is a normal thing in developers.

And it's good for many reasons like: 

  • It makes code readable for your team. 
  • Reduce complexity.
  • Make code more maintainable etc.

But the worse thing is refactoring and adding a new feature in the same commit. 

You should not treat refactoring as a new feature and never mix these two things.  Code refactoring is not adding any value to the business. 


This simple technique helped me to boost my productivity by 80% in 7 days.


Before using this, I was very easily lost my focus. But with an atomic commit, I was staying focused as I was only doing one small thing at a time. ( I test it with Pomodoro technique and realize I become more productive and focussed)

Also, I adopt a habit of frequent commit and start testing my code before pushing to remote branches. I realize this small change helped my other developer in many ways and fewer conflicts. 

Hence boost in productivity. 

To know more about such techniques please visit and subscribe to acompiler.com 

Now it's your time to use and share your results.

acronyms, after technique, devops, git, git best practices

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}