Did you know multiple Github workflows are available that are powerful enough to work individually or to work together?
Based on my collaboration with different software teams, I understand that CICD process usually follows a predetermined framework that is defined by the team’s rule. However, it also should be kept in mind that there are always best practices that are common among different teams.
Git is one the most used software for version control. It is extremely important to use this tool correctly to maintain productivity and consistency while implementing changes in a code.
One way to maintain the code flow consistency is using Git workflow in combination with Git version control software. It should be mentioned that there is not a comprehensive Git workflow that fits all teams. Consequently, teams should select and cast the one that helps the team for enhancement.
How to select a workflow?
There are several factors that should be considered in Git workflow:
if the selected workflow is scalable?
If it is easy to undo and manage the fixes and bugs?
If it increases the overhead to the team?
What are the different types of workflows?
- Git Feature Branch Workflow
- GitFlow workflow
- Forking workflow
Git feature Branch Workflow:
This is the most similar workflow to the SVN regarding flow management. This workflow mainly focuses on branching patterns meaning developers create separate feature branches from the main (centralized branch) as shown in Figure 1. Feature branches will be used for feature development and eventually will be merged to the main branch after completion.
The Feature branch workflow cannot leverage to GitFlow and Forking workflows.
Figure 1. Feature branch. (https://www.atlassian.com)
Gitflow workflow:
As the abstract of the Git workflow, Gitflow workflow contains two branches (main and develop) to track the code changes in addition to the release branch. The main branch is generally for tracking the code changes and release history meanwhile the develop branch satisfies the feature integration. All the feature branches will be merged to the develop branch eventually. Gitflow workflow is considered one of the best choices for modern CICD development and DevOps teams’ practices due to its popularity. This workflow is stronger in performance than Feature Branch workflow and that shines Gitflow as an alternative for software teams with feature branches and multiple primary branches. Moreover, there is a Gitflow toolset which can be installed on both IOS and Windows to use instead of Git commands.
Using Gitflow workflow, developers can create the feature branch and keep maintaining it until the feature development is fully completed. Then, they can merge it to the develop branch. This potential makes this workflow a good candidate for teams with restrictions or tight schedules, and release deadlines.
Once develop branch has enough features to release then as part of the process a release branch will be created from it. It should be emphasized that there will not be any new feature merging to the release branch after the cut over happens unless it is a bug fix, a documentation, or any task about the release.
Once release branch is ready for production, it will be merged to the main branch with a new assigned tag while the same version is merged to the develop. Consequently, development is resumed in parallel to release process.
The summary of Gitflow workflow release process is depicted in Figure 2.
Figure 2. Release branches. (https://www.atlassian.com)
There is a specific scenario that the release team needs to ship a hot fix to the production without introducing any new feature. In this case release branch will be generated from main instead of develop branch. Once fix is completed then this branch should be merged to both main and develop to synchronize all the central branches. Figure 3 shows the process in hot fix release.
Figure 3. Hotfix branches. (https://www.atlassian.com)
Forking workflow:
The final Git workflow is the Forking workflow. The other two workflows (i.e. Feature branch and Gitflow) provide an access to the server-side main repository. Consequently, developers can directly create pull request against the main branch and after passing the review process they can merge the code to the develop or main branches based on the picked workflow process.
In this workflow there are multiple server-side versions of the code repository. Developers fork the whole project on their system. Hence, they have their own server-side repository. Subsequently, they start creating feature branch from the local version similar to all other workflows. Finally, one project manager will review their commits to confirm they are not breaking the existing code and then approve, and merge developers’ commits personally.
Having the option to isolate the access to the original codebase makes this workflow a good candidate for open-source projects. Developers from different part of the world can fork the project and raise a PR against their own server-side version. Once that PR is approved by the project manager, they can merge their code to the original code and still not breaking someone else’s changes in the code.
To conclude, Git is one of the most popular version control software that provides different teams with the flexibility to choose the structure working better for them. So, enjoy playing around and find the one that suites your team’s purpose well.
Top comments (0)