Hack Git: Boost your Productivity (Guest Post)

Git is a powerful tool. Git can be more effective if you will use its best practices, and with a few advanced git tips and tricks, you can save your valuable time. The productivity boost technique is known as the AFTER technique.

Hack Git: Boost your Productivity (Guest Post)

A Guest post by: Rajeev Bera


Git is a powerful tool. Git can be more effective if you will use its best practices, and with a few advanced git tips and tricks, you can save your valuable time.

In this post, I will share a few productivity hacks which you can use from day one and save your time. The best part - You will notice the productivity increase within five days.

This productivity boost technique is known as the AFTER technique.

So let's dive in.

#1. A - Atomic Commits

Atomic commits are an essential and powerful practice. So here, as a developer, you try to break the task into subtasks so you can check-in with atomic commits.

The key is this - break the big tasks into smaller pieces of work. And then you can work on those small tasks. Once you manage to complete the tasks, it's time to make an atomic commit.

To add more clarity, here are a few examples about when you should do atomic commit.

  • You update a function in your javascript file - It’s time to atomic commit.  git commit -m "Updated JS <function name> in <form name>"
  • New site logo added - It's time to atomic commit git commit -m "New website loo added"
  • Background color changed of your website - It's time to atomic commit git commit -m "Site background color changed to white from red".

#2. F - Frequent Commits

Now you have small tasks so you can complete them in a short time. Hence, you will find opportunities to check-in frequently.  

Do you know how many times you should check your code into the Git repository?

The good news is there is no such rule which defines the number of commits per day. It is one of the Git best practices to do frequent commits.

If you do atomic and frequent commits, there will be fewer chances of any conflicts.

#3. T - Test Before You Commit/Push Your Changes

Testing is important. Developers should test their changes before they commit.  We all are human, and we can make mistakes.

It's essential to test your code before you commit or push your changes to the remote repository.

Let's take a scenario - You are working with five other developers in your team on a substantial project. In a hurry, you pushed broken code in the remote repo.

And then ...

Your team will be lose steam once they got the latest code from the remote repo. And overall productivity will be drop.

That's the importance of testing code before pushing in the remote repo.

#4. E - Enforce standards

In a team, standards are essential. You can use different standards based on your team and project requirements.

And there are some core standards which you can enforce as best practices in your team to boost productivity. The core three standards are:

  1. Use of the .gitignore file: Never ignore gitignore file, it helps to keep your repository clean and stable. With this special file, you can avoid unwanted files in your code repository.
  2. Commit messages must be with every single check-in: For developers, precise commit messages act as project documentation. Any new developer can join the team and understand the code. But if good check-in history and commit messages are there it will be super easy for an average developer to come to speed quickly.
  3. Unit test must be there: You cannot ignore the importance of unit tests. So it is not a best practice to ignore the importance of unit tests.

#5. R - Refactoring Is Not a Feature

Code refactoring is essential. And developers do code refactoring for many good reasons. One of the main advantages is - It helps to improve the design of your software.

But you should not mix code refactoring with adding new features at the same time. The best way is - Do one thing at a time.

Remember, Code refactoring is not equal to adding a new feature. If you mix them, it will be hard to do code review, and complexity will be high. Hence, overall productivity will have dropped.

So, it's better to do one thing at a time.

Conclusion

I have used these exact same steps to boost my productivity. With the use of the AFTER technique, you will notice a difference in you and your teams' productivity.

It's time to implement these techniques and boost your productivity.

Let me know your thoughts!