7 Best Practices in GIT for Your Code Quality

DZone 's Guide to

7 Best Practices in GIT for Your Code Quality

Git plays a significant role in software development. It allows developers to work on the same code base at the same time. Check out 7 best practices for Git.

· Open Source Zone ·
Free Resource

There is no doubt that Git plays a significant role in software development. It allows developers to work on the same code base at the same time. Still, developers struggle for code quality. Why? They fail to follow git best practices. In this post, I will explain seven core best practices of Git and a Bonus Section.

1. Atomic Commit 

Committing something to Git means that you have changed your code and want to save these changes as a new trusted version.

Version control systems will not limit you in how you commit your code. 

  • You can commit 1000 changes in one single commit.
  • Commit all the dll and other dependencies 
  • Or you can check in broken code to your repository.

But is it good? Not quite.

Because you are compromising code quality, and it will take more time to review code. So overall, team productivity will be reduced. The best practice is to make an atomic commit.

When you do an atomic commit, you're committing only one change.  It might be across multiple files, but it's one single change.

2. Clarity About What You Can (& Can’t) Commit 

Many developers make some changes, then commit, then push. And I have seen many repositories with unwanted files like dll, pdf, etc.

You can ask two questions to yourself, before check-in your code into the repository 

  1. Are you suppose to check-in all these files? 
  2. Are they part of your source code? 

You can simply use the .gitignore file to avoid unwanted files in the repository. If you are working on more then one repo, it's easy to use a global .gitignore file (without adding or pushing). And .gitignore file adds clarity and helps you to keep your code clean. What you can commit, and it will automatically ignore the unwanted files like autogenerated files like .dll and .class, etc.

3. Know Git Commands

Git is a powerful tool, and without a doubt, it's a super useful tool. But in the end, it's a computer program. And it's essential to know the basic git commands so you can use this tool effectively. You should know all the basic git commands that will help you in different ways. Git offers friendly help. While using git, you can learn more about individual Git commands from the git bash with "git help command.” And with this simple handy command, you can get an overview of any git command.

4. Do You Have a Workflow?

If you are working with a team on a Git managed project, it's essential to make sure that the entire dev team uses the same workflow.

There are three main advantages of a workflow.

  1. Your development process is more organized.
  2. A good git workflow ensures a clean state of branches at all times.
  3. It makes your life comfortable; in general, workflow improves the overall code quality.

5. Test Before You Push 

You should test your changes before you commit or push.  If you commit broken code in your local repo, then you will be blocked.  But if you push the broken source code, then you will block your team. 

  • It would help if you encouraged your team to run unit tests related to the code they modified even before a commit.
  • In your team, every developer should understand that breaking the build is not good. And if it happens for some reason, their top priority is to fix it.  

6. Protect Your Master 

The default branch in git is master. And the code on the master branch should be stable as it's used for the production environment. You can protect the master branch in many ways, like with pre and post hooks, company policy, or by adding more safeguards.

You can enable the following safeguards on the master branch:

  • The Master branch should not be deleted, either accidentally or intentionally.
  • On the master branch, it’s committed history cannot be overwritten.
  • No direct check-in allowed in the master ( without code review)

7. Branch Management

Git offers a powerful branching model. You should keep your code in a separate branch from the master:

  1. You are about to add a new feature  - Create a new branch. 
  2. You are about to fix some bugs - Create a new branch. 
  3. You want to do refactoring - Create a new branch. 

Once you are done with your changes, pull requests, and after code, review merges with master and stay in Sync.

In short: 

  1. Create a new branch 
  2. Merge it with the master ( after code review) 
  3. Keep in Sync.

These are the 7 best practices that you can follow and boost your code quality.


You can use the AFTER technique to boost your overall productivity. Which is your favorite? Let me know by comment.

git basics, git best practices, git command, git ignore, git tutorial for beginners, git tutorials

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}