Branching Strategy
There are many different approaches to managing branches within a Git repository. The branching strategy used by a project should be documented and followed by all contributors. This ensures that all contributors are working in a consistent manner, making it easier to understand the state of the repository and to collaborate effectively.
At Seven20, we believe a simple branching strategy is best, as it enables contributors to focus on the work they are doing rather than the process of managing branches. It also enables non-technical contributors to contribute to projects that can benefit from using Git - for example, this documentation site is managed using Git.
The branching strategy we use is a simplified version of the Gitflow Workflow. The main branches in the repository are:
main: A reflection of the Production environment, this branch should always be in a working state. Changes to this branch should be made via pull requests.noteThis was historically called
masterbut has been renamed tomainto be more inclusive.development: Used to integrate different changes from other branches into a central branch. This branch will usually be a reflection of the current testing environment. Changes to this branch should be made via pull requests.
Feature branch
Feature branches, which are used to develop new features or fix bugs, are created from the development branch and are merged back into the development branch once the work is complete. Feature branches should be named in a way that describes the work being done or any relevant ticket numbers, for example feature/WIP-001. These branches should be deleted once the work is complete.
When examining the Git history, it would look something as follows:
Complex feature development
For complex features which may require multiple pieces of work to be developed before it is viable to be merged into development (e.g. because it depends on other work being completed first), longer lived feature branches can be created. These branches can act in the place of the development branch, allowing a central place for all work to be integrated. Once the work is complete, the feature branch can be merged into the development branch and tested as normal.
When examining the Git history, it would look something as follows:
We do not recommend using long lived feature branches unless absolutely necessary. They can make it difficult to integrate changes from other contributors and can lead to merge conflicts. Ideally work should be broken down into smaller, more manageable pieces that can be developed and tested independently.
Releases
When a release is ready to be made, a release branch should be created from the development branch. By branching from development we can effectively freeze the current state of our development work and allow other development work to continue on the development branch, while still allowing issue fixes and required changes to be merged into the release branch in preparation for the release. Once the release branch is ready, it can then be merged into the main branch. Any changes against the release branch can then be merged back into development once the release is complete, either by merging it directly to development or by merging main back.
When examining the Git history, it would look something as follows:
Hotfixes
Sometimes issues are found in the production environment which were not identified during the testing phase. Depending on the severity of the issue it can be crucial that a fix is developed and deployed as quickly as possible. To facilitate that, hotfix branches can be used.
Unlike feature branches, hotfix branches are created from the main branch, as they are intended to be deployed directly to the production environment. Once the fix is complete, the hotfix branch can be merged back into the main branch and then into the development branch, in the same process as normal releases follow.
When examining the Git history, it would look something as follows:
By ensuring you use a proper Sandboxing strategy (or scratch orgs), you can ensure that the changes made in a hotfix are being tested in isolation and in an environment that is as close to production as possible.