Best Git Practices to Follow in Teams

We all know that Git is one of the most popular version control systems used by developers all over the world. Developers have been using it for many years but not all developers know the best practices for using it. 

There are several ways to use git to communicate with your team. You can use these git best practices from a small team of two to ten developers. When working with git, you can consider the following best practices:

1. Commits Should Be Small and Frequent

Whenever you make a single logical change, you should commit the code. Frequent commit helps you to write brief commit messages that are short yet informative. This approach provides significant value to those who may be reviewing your code.

Committing small changes also makes bugs or other issues much easier to handle. Below are some signals that typically mean that you don't contribute enough...

• For the first time, a 100+ line file is a single commit.
• You modify more than 50 lines of a file in a single commit.

2. Commit Messages are to Be Semantic

Each commit message should explain why you need to update the code in the first place or what has been altered at the required level of detail.

When anyone asks whether a line of code has been created or updated, the commit message should be transparent. Here are some code signs that you have written a weak commit message:

• The commit message is less than three words.
• Your commit message is too high-level

3. Use of Branches  

When you make several commits that are connected, they belong to a different branch. One of the most striking things about git branches is the Pull Requests, making it easy to address a list of commits before merging back into the main git branch.

Using branches makes merging into the main git branch more organized. It gives you a chance to see all the final improvements while viewing work-in-progress commits. This ensures that the main branch is still ready to launch, with no broken code.

While you're working on a git branch, make sure you run git pull regularly. So your branch isn't left behind. This reduces the probability of merge conflicts.

4. One Branch, One Feature  

The feature Branch concept is that all new functionality should be on a separate dedicated branch instead of the main branch. This practice ensures that the main branch never contains unfinished code, which is a significant benefit for continuous integration environments.

So you can use a new branch for one new feature. Once you complete your work, make a pull request and git merge changes into the main branch. You can create a new feature branch for the next feature and repeat the process.  

With one branch one feature strategy, you will achieve many good things.

• A code review will be easy as you are dealing with one feature only.
• You stay focused and productive as you are doing one thing at a time.
• It helps another developer to understand the code because of small changes.

5. Handle Merge Properly

Each team member is required to work on a different feature branch. But even though other branches are in use, they all inevitably change specific similar files. When combining the modifications back to the main branch, the merge may not always be automatic. Human interaction might be required to resolve conflicts when two writers change the same file.

There are many features and Git commands that support Git merge conflicts in new modern editors. They show the different options for combining each section of the file. If your editor doesn't support those capabilities, it is the time to try a new one.

6. Single Repository  

Large teams may benefit from several project repositories, libraries, etc. For teams under 10, it is usually best to keep all the code needed to execute the whole product in a single repository.

This allows the entire program to be managed and distributed as a single entity. Internal applications that are reused between projects should be made available via a package manager etc.

There are many advantages for a small team using a single repository:

• Your code will stay in sync
• Refactoring becomes cheap

You might need multiple repositories for your product; here are a few reasons.  

• Suppose your product is not entirely open source. You might need to keep some code/libraries in separate repositories.
• Similarly, if your product has some client work, then it should go into a separate repository.

7. Avoid Committing Dependencies in Repo

Your Git repository is where you keep track of your source code. It is not a good practice to store dependencies. Additionally, submitting your dependencies will increase the size of the project repository significantly.

1. Use a suitable build/dependency tool instead of Git.

2. There is a tool for (nearly) every software stack out there. 

• Maven for Java 
• Npm for Node.js applications

8. Don't  Commit Broken Code

Do you know What is the most harmful thing a developer can do? They can block other developers from their work (with their broken code). If you are eager to make a git commit, make sure you test your code before committing. You can use the Git stash command if you need to switch branches to work on something else.  But never check in broken code. 

9. Use Tags

You and your team can use tags when you release the code. Although a branch accumulates a history of changes related to commits, a tag is a snapshot of the branch's state at that specific moment.

A tag is like a stable branch. Unlike branches, tags do not have additional commit history after they are created. There are many advantages to using tags with your release.  

• It allows you to keep track of your project's version number.
• It helps you compare the modifications between the two different releases.
• It allows you to record your project release notes, which are valuable for your team and stakeholders

Hope these Git best practices for small teams help you to use Git effectively in your group. Git is an advanced tool that takes time to learn. Using these practices, you and your teams work effectively using Git.