Version control is a critical part of the software development lifecycle. It allows you to track changes to your code, collaborate with other developers, and manage your codebase. There are multiple different ways you can use version control and this could be different project by project. This guide will help you understand the best practices for version control.
Why Do You Need A Branching Strategy?
A branching strategy is a way to manage your codebase and collaborate with other developers. It allows you to work on different features or bug fixes without affecting the main codebase. It also allows you to collaborate with other developers and merge your changes back into the main codebase. A good branching strategy can help you to avoid conflicts and merge issues, and it can help you to manage your codebase more effectively.
If you need to make urgent hotfixes to production you need to have a strategy in place to do this. You need to be able to isolate the hotfix from the new development and ensure that it is deployed to production as quickly as possible, while also ensuring that you're not introducing new development to the fixes.
Team size is an important factor in choosing a branching strategy. If you have a small team, you can use a simpler strategy like Trunk Based Development. If you have a larger team, you may need to use a more complex strategy like Gitflow.
Git Branching Strategies
Trunk Based Development
Trunk Based Development is a version control strategy where all developers work on a single branch. This is the simplest strategy and is best suited for small teams working on small projects. It is also best suited for projects that require continuous deployment. The main advantage of this strategy is that it is simple and easy to understand. The main disadvantage is that it can lead to conflicts and merge issues if multiple developers are working on the same codebase.
Common practice is to use feature toggles to hide new features until they are ready to be released. This way, you can deploy new features to production without affecting all users. If the new feature has any issues, you can easily disable it for all users.
Pair programming is also a common practice with this strategy. This way, you can ensure that all developers are working on the same codebase and are aware of any changes that are being made. This can help with code sharing and knowledge sharing of the different features.
Gitflow
The idea around Gitflow is to try to isolate new development from finished work. This is done by using two main branches:
master and develop. The master branch is used to store the finished work and the develop branch is used to store
the new development. When a new feature is ready to be released, a new branch is created from the develop branch and
merged back into the develop branch when it is finished. When the develop branch is ready to be released, it is merged
into the master branch.
When working off the develop branch, it is common to use feature branches. This is where a new branch is created from the
develop branch and merged back into the develop branch when it is finished. This way, you can isolate new development
from finished work.
When working off the master branch, it is common to use release branches. This is where a new branch is created from the
master branch and merged back into the master branch when it is finished. This way, you can isolate new releases from
finished work.
If you need to use a hotfix you will do this off the master branch and then merged back into the master branch when it
is finished. You can also merge the hotfix into the develop branch to ensure that the new development is not affected.
The main advantage of this strategy is that it isolates new development from finished work. This can help to reduce the risk of conflicts and merge issues. The main disadvantage is that it can be complex and difficult to understand. It also requires a lot of discipline to follow the process correctly.
Any code in the master branch is always deployable. This is a key part of the Gitflow strategy.
GitLab Flow
This strategy is similar to Gitflow but it uses environment branches such as master, pre production, production.
Deployment can be done from the master branch to the pre production branch and then to the production branch.
This makes it more simple to understand and follow than Gitflow. It also makes it easier to understand the different environments that are being used. But it isn't very structured and can lead to some messy branches where you need to keep track of the where to base the pull request from.
GitHub Flow
The Github flow method is a simplified version of Gitflow. It is a lightweight, branch-based workflow that supports teams and projects where deployments are made regularly. It is a great strategy for small teams working on small projects.
It has a main branch, usually master, and feature branches. When a new feature is ready to be released, a new branch is
created from the master branch and merged back into the master branch when it is finished. You can then deploy off
master when you are ready. This is why it suits projects where deployments are made regularly and the team is small.
In projects that have larger development teams there can be conflicts with working in this method.
Version Numbers
When working on a project it's important to define how you are going to version your project.
SemVer is a versioning system that is used to communicate upgrades with your applications.
It works with 3 categories
- Major - v1.0.0
- Minor - v1.1.0
- Patches - v1.1.1
Major versions will contain breaking changes that requires the users upgrade their code. You could also use this for a major change, so that you can communicate to the users that this is a big change.
Minor versions will contain new features that are backwards compatible with the previous version. This is a good way to communicate to the users that there are new features available.
Patch versions will contain bug fixes that are backwards compatible with the previous version.