Git is the most commonly used version control system in the programming world. Every programmer wants to deploy their changes smoothly to production without any hustle but sometimes we choose the wrong git branching strategy and stuck with production deployment or maybe get delayed because of some conflicts. It is important to choose the correct workflow for your team and also it helps to enhance the productivity of your team. While choosing a git branching strategy make sure it is scalable with your team, easy to undo mistakes and errors, and not a burden that limits the productivity of your team.
1. Centralized Workflow:
In this strategy, all team members share a single central repository. The central repository acts as the “single source of truth” for the project. Each team member clones the central repository to their local machine and makes changes locally. Once they are ready to share their changes with the team, they push their commits to the central repository. Other team members can then pull the changes from the central repository to stay up to date. This workflow is simple and easy to understand, but it can become difficult to manage when multiple team members are making changes at the same time.
Example: A team of web developers working on a single website, all committing changes to a central repository hosted on GitHub. Each developer clones the central repository to their local machine makes changes to the code and then pushes the changes to the central repository. Other developers can then pull the changes to stay up to date.
2. Feature Branch Workflow or GitHub flow:
This strategy involves creating a new branch for each new feature. The main branch is typically called “master” and is considered to be the “production-ready” version of the code. When a developer wants to work on a new feature, they create a new branch off of the master branch. They make their changes and commit them to the new branch. Once the feature is complete, they can then merge the new branch back into the master branch. This workflow allows multiple features to be developed in parallel and can help to keep the master branch stable.
Example: A team of developers working on a project, each creating their own branch to work on specific features. Developer A creates a branch called “feature-login” to work on the login feature. Developer B creates a branch called “feature-signup” to work on the signup feature. Once the features are complete, they are merged back into the master branch on GitHub.
3. Gitflow Workflow:
This strategy is based on the feature branch workflow, but it also includes additional branches for development, release, and hotfix. The main branches are ‘develop’ and ‘master’. The ‘develop’ branch is used for ongoing development and it’s where the new feature branches are created and merged back. The ‘master’ branch is considered to be the production-ready version of the code. Gitflow also includes release branches, which are created from the ‘develop’ branch. These branches are used to prepare for a new release, and once the release is ready, the release branch is merged into ‘master’ and ‘develop’. Hotfix branches are used for urgent bug fixes and are created from the ‘master’ branch.
Example: A team of developers working on a software project, using the Gitflow Workflow to manage their branches for development, release, and hotfixes. They use ‘develop’ and ‘master’ branches and each feature is developed in a separate branch, which is then merged into ‘develop’ and later into ‘master’. When they are ready to release a new version of the software, they create a release branch from ‘develop’, and once it’s ready, they merge it into ‘master’ and ‘develop’. If there’s an urgent bug fix, they create a hotfix branch from ‘master’ and merge it back into ‘master’ and ‘develop’ after the fix is done.
4. Forking Workflow:
This strategy is used when multiple developers want to contribute to the same project, but they don’t have write access to the main repository. They create their own fork of the repository, make their changes and then create a pull request to the main repository. The maintainers of the main repository can review the changes and merge them if they are acceptable. This workflow is commonly used in open-source projects, where anyone can contribute but changes need to be reviewed by the maintainers before they are merged into the main codebase.
5. Gitlab Flow:
This strategy is similar to gitflow but is used when working with GitLab. The difference is that it doesn’t have release branches and it uses merge requests to review and merge changes.
Example: A software development team using GitLab to manage their codebase and using GitLab Flow to manage the branches and merge requests. They create a new branch for each feature, and once they are complete they create a merge request to be reviewed and merged into the main branch. After code verification, they create a merge request, and the main branch is merged into pre-production, and after pre-production code verification and testing pre-production branch gets merged into production.
Summary
Please note that these are just examples and different teams may use variations of these workflows depending on their needs and preferences. There is no such thing as the perfect strategy. The strategy you choose should be simple and enhance the productivity of your team and also suit the nature and complexity of your project.