Best Practices for Managing Git Repositories
As developers, we interact with version control systems (VCS) daily. The most preferred VCS nowadays and the one used by most developers is Git. Git adds immense value, especially in big teams where multiple developers work together, as it becomes essential to have a reliable code integration system for everyone.
Contributors find Git fairly easy to use, given that the operations are usually the same and easy to do. 99% of the commands executed being only git add, git commit, git push, git pull, and git branch, if any.
However, owning and managing a Git repo where multiple developers are contributing involves more knowledge as things can easily go south.
Here are some of the best practices you can follow while managing a Git repository. Even if some of them are addressed to the repo administrator, these practices are helpful for all contributors because some involve them directly.
1. Protect Main Branches
Although this is not a feature of Git but rather a feature of the code hosting platforms, protecting the main branch(es) is something you should consider.
Usually, in our repos, we have one main branch for each deployment server. We have a **master **branch for the production server and, depending on the project architecture, a **QA **branch for the quality assurance server. We also have a **dev **branch for the development server.
This differs from project to project, but the main idea is that you want these main branches to be protected with some specific rules.
The point of protected branches is to ensure that your code is deployable all the time and to prevent unchecked code changes.
2. Formalize Git Conventions for the Team
While working in a team, a good practice is to have everyone follow the same conventions. The same applies to contributing to git repositories. Therefore, as the owner or as a team, you should pick or define a suitable convention early on and follow it.
Some of these conventions should include things like commit message style, branch naming, tagging, and even coding.
You can help your team with this by creating a CONTRIBUTING.md file that acts as a guideline for anyone involved in the project. You can be inspired by the contribution guide of other similar projects, or you can choose from the most popular open-source projects.
Also, different team members will have different levels of expertise with Git. You can also decide to use a GUI Client for Git, which can make the job easier by removing the need for manually typing the commands in a terminal.
This can be very useful for developers who lack experience with Git and don't feel so comfortable with the terminal to get over common Git errors, like fatal: Not a git repository (or any of the parent directories).
3. Make Use of Tags
One useful feature of Git is tagging. Tagging is used to preserve the current state of a branch as a significant milestone. It works like a snapshot of the branch's state at that moment.
Tags are usually created once the code is tested and deployed to mark release points: v1.0.0, v2.0.0, and so on.
The benefit of this feature is that you can go back in time to a certain point and rebuild the application from the point at which it was saved. This is useful, for example, in a situation where a bug goes undetected through testing and is caught only upon reaching the live application. In such a situation, you want to quickly revert to the previous version until the bug is resolved.
4. Prevent Sensitive Data from Being Leaked
Projects often contain certain sensitive information. They often contain database credentials, private keys for the API, and so on.
This data, along with other configuration data, is typically stored as environmental variables.
A best practice here is not to commit this data to the remote repository and risk exposure.
For this, you can create a meaningful git ignore file in which you add all the files that you want to be ignored by Git. You can easily do this by creating a .gitignore file in the root of your project and type the file or directory paths that you want to ignore. You can also choose a relevant template from Gitignore.io to get started quickly.
5. Remove Inactive Contributors
Repositories can be public or private. If you work inside an organization, they are all going to be private. Therefore, it is good practice always to revoke the access of contributors who no longer contribute to the code base and are no longer involved in the project.
This helps ensure the integrity of the repository and prevents a former contributor from performing any action (in error or otherwise) or malicious individuals from using leaked or hacked credentials to meddle with the project.
6. Enable Security Alerts
Finally, security alerts are useful. You can consider enabling them if your code hosting platform provides the feature.
Dependencies are constantly updating to fix issues and vulnerabilities. If you have several projects, each having dozens of dependencies, it can become quite hard to keep everything up to date.
Therefore, a good option is to use tools that perform security audits that continuously scan the repositories for known vulnerabilities and provide alerts in case of any.
Conclusion
Developers are working extensively with code version systems, especially Git. Having a guideline defined per project by the code owner or by the team itself will always be beneficial as pursuing best practices helps the team improve productivity and reduce security risks.