The following is the Git guidelines upheld and enforced in Gavdi. It is based on our years of experience within the field, and our focus on project sustainability.
DISCLAIMER: We do acknowledge that it is not always possible to 100% use our preferred approach in all projects, however the goal is to use this approach as much as possible.
For readability the guidelines have been separated up into areas of focus, which can be found here:
- Goal of Guidelines
- General Best Practice
- Git Workflow
- Branching Strategy
- Commit Messages
- Pull-Request Procedure
- CI/CD Pipelines
The goal of these guidelines is not to conform every project into a cookie-cutter format, but to provide a safeguarding for a sustainable project.
Should one only implement 70% of these best practices, it should still provide the project with a better foundation than including none of them. Primary objective is just to show a way to improve one's existing/new project and prepare for a readable and sustainable future.
Before entering into the details of a proper Git flow, there are some general best practices that should be adopted up front, both for the sake of the developer but also for the sake of the project as a whole.
These general best practices can even be adopted to be used in a local non-remote git repository for your own home project. You never know, someday you might want to take it to a remote host somwhere and publish it!
Whether we're talking contributions, pull requests, or commit messages, it is generally ideal to keep everything small and simple. This will help making your repository more traceable in where changes where applied, long with making it easier to rollback individual changes.
Maintanance is key with Git, and making bite-sized chunks instead of entire landscapes help support this!
Make sure all changes that are made in your repository is traceable and links back to decisions that were taken.
If you make use of a project management solution in relation to the repository, then add the IDs of the related tasks to the work being done. This will allow you to backtrace any related information. This might seem as a chore up front, but when something breaks this will help save you time in the long run!
When starting up a new repository, agree with all participants and/or stakeholders on what the standards should be.
What scopes should you have? Where should the documentation go? What are your naming conventions for branches? What branch is going to be the live branch?
Once you've agreed on all of this, remember to document it in the README, so it is always readily available for any new participants!
Your README file is the entry point for any new contributer (or returning contributer). It is therefore crucial that you keep this file updated with any changes that might affect contributions.
A README must always be concise, descriptive and link to information that is deemed vital for your project. So keep it up to date!
Next: Git Flow
Author: Simon Vestergaard Laursen
(c) Copyright by Gavdi Labs 2025 - All Rights Reserved