Git-Flow vs GitHub-Flow
Git-Flow
Git-Flow provides a way of addressing the need for parallel development between different features. When you start developing a feature, create a feature branch from the master branch. Then, all the development work on the feature is done on this feature branch. After you complete the work on the feature, merge the feature branch back to the main code path for release.
Git-Flow has the following branches:
- Feature branch: is a branch for developers to develop features.
- Develop branch: is a branch that collects the developed features.
- Release branch: is a branch that is responsible for version release.
- Hotfix branch: is a branch that corrects online defects.
- Master branch: is a branch that stores the baseline of the latest released version.
Each feature has its own develop branch, that is, the feature branch. When a developer needs to work on two features, the developer only needs to switch between the branches by running the “check out” command. This is to prevent the mutual interference between the development of the two features during the development process.
When you develop a feature, you need to verify it separately. After the feature is verified, merge it to an integration branch called develop branch to verify the entire software program. In this process, the develop branch is similar to the master branch most of the time. The develop branch always stores the most recent unreleased version. After the code on the develop branch is verified and can be released, you can create a release branch from the develop branch for release.
If a defect is found on the release branch during the release process, correct the defect on the release branch and synchronize the correction to the develop branch. After the version on the release branch is released, the finalized code is synchronized to the develop and master branches again. In this way, the master branch always keeps the baseline of the working version. Meanwhile, the develop branch keeps the latest version for development integration.
Git-Flow introduces a branch called hotfix, which is dedicated to correcting online defects. After the defects are corrected, they are collected to the develop branch and then synchronized to the master branch. In fact, we can consider hotfix as a special feature branch, but code changes submitted by it need to be synchronized to the master branch while being integrated into the develop branch.
- Developers receive a development request and create a feature branch from the develop branch.
- The developers complete local development and local verification and then submit their code to the feature branch.
- The code is verified on the feature branch, which continuously merges newly created code.
- The developers complete feature development and the feature branch detects no errors during the verification. Then, the code on the feature branch is merged to the develop branch.
- The develop branch performs integration verification, which may involve the code from other feature branches. After the integration verification is completed, the feature branch will be deleted.
- When the develop branch keeps a mature release version, for example, the develop branch has performed full testing and corrected all defects, you can create a release branch for release.
- After the release is completed, the code on the release branch is merged to the develop and master branches, and then the release branch is deleted. Here, note that the master branch always keeps the most recently released code.
The hotfix process is as follows:
- If a defect is found after a release, a hotfix branch is created from the master branch.
- The defect is corrected and then verified on the hotfix branch.
- The correction is merged to the develop and master branches.
- The hotfix branch is deleted.
Pros
- Complete rules with definite responsibilities of branches.
- Conducive to the distribution of traditional software.
- Provides very thorough and detailed version control as merges are bundled, clearly labeled, and able to be traced cleanly.
- Easy to scale our development. It simplifies parallel processing and continuous development by isolating features and ensuring that you never have to freeze either your development or master branch for release preparation.
- Flexible branching strategy. Easier to jump between parts of the development pipeline (say, between a feature for a later release and the urgent priorities of the current release).
- The code in the master branch remains very clean and organized, updated only with code that has been thoroughly tested and refined.
Cons
- Many branches with complicated rules
- Heavy maintenance workload for released versions
- The rigid structure and specific development path of Git-Flow conflicts with the iterative approach of the Agile methodology.
GitHub-Flow
Unlike Git-Flow, GitHub-Flow involves no release branches. In the ideas of GitHub-Flow, once a version is ready to go, it can be deployed. Similarly, GitHub-Flow believes that hotfixes are identical to minor feature changes, and their processing methods should be similar.
- All code on the master branch is the latest working version that can be deployed.
- To perform a new task, a new branch is created from the master branch and is explicitly named to reveal its purpose, for example, a new scheduling strategy.
- Code changes must be committed to the local branch as frequently as possible. Meanwhile, the changes must be synchronized to the branch with the same branch name on the server as frequently as possible.
- If you want to merge new code to the master branch, you must initiate a pull request to request code review.
- After the code review is passed or when the code review is ongoing, the branch must be deployed to the test environment for verification.
- If the review and verification are passed, the code must be merged to the master branch. So, the master branch is always be deployable.
- The latest release package is created from the latest code in the master branch.
The hotfix process is as follows:
- If a defect is found after a release, a hotfix branch is created from the master branch (at a special commit version — which is deployed to prod environment).
- The defect is corrected and then verified on the hotfix branch.
- The hotfix branch is merged to the master branch.
- The hotfix branch is deleted.
Pros
- Clear and simple collaboration rules.
- Continuous integration and deployment.
- Encourages fast feedback loops, making it possible for teams to quickly identify issues and make changes.
- Continuous deployment is pretty much a must with GitHub Flow. You have no development branch where finished features sit and wait for release. → created quickly becomes value delivered.
- There’s less risk of technical debt with this branching strategy. Within Git-Flow, one shortcut or sub-optimal piece of code can quickly get buried and become a refactoring nightmare. The emphasis GitHub-Flow places on the shallow structures and small changes make it easier in the long run to identify and manage technical debt.
Cons
- GitHub Flow is not as well-organized as Git-Flow. Its speed comes at the cost of comprehensiveness and may make it harder to manage the overall development process.
- This branching strategy emphasizes constant deployment. While this can work well for some software teams, others will find it limiting as they seek to make larger releases or if they want to test multiple features together before deployment.
- The master branch can become cluttered more easily since it functions as both the production and development branch. Release preparation and bug fixes both happen in this branch — and require extra attentiveness.
Which Git workflow is appropriate for you?
Let’s assume that our development teams are a small Agile team, and we have a single release version for our product for each repository. GitHub-Flow is the winner.
GitHub-Flow is pretty simple and effective way to support continuous deployment and release. It gives us a way to align the team around a clearly defined process for new features and fixing bugs, while also keeping our pipeline as streamlined and delivery-focused as possible. Just make sure our team adheres to the branching strategy.
