Following the post on basic Git, today we will continue with another topic related to Git usage in projects: Gitflow Workflow.
Git is one of the most effective and easy to use source code management tools, and building Git for small projects with few people or short ones which last for a couple of months… should not be difficult, as you only need to build a repository, then team members work together on it till the end of the project.
But if you are the one who is responsible to build the workflow of a big project which has dozens of members, which could have multiple releases and needs to store clear project state, however, it is a completely different situation. In this case, we will need a good enough workflow to optimize work efficiency among the team.
This article will introduce a source code management workflow with Git, which the author had experienced via various projects of around 50 to over 100 members. The workflow is also not exclusive to Git, and so you may tinker around to get it applicable for other source code management tools like svn…
Whether the source code management workflow is good depends on how we organize the working branches.
Master or <ABC> (whichever name used in your project): this is the main branch that store all source codes of the project, and is the “cleanest” code branch for products. After the development period, your product will be released to users, and when new versions of the code are released, they will be merged to this master branch, and tagged for easy finding in the future.
Hot fixes branches
Should you detect no major error after product testing, you will move onto the release. However, things don’t always work the way you want them to, and after release, customers may report malfunction in feature <XYZ>, which require quick fixing. Bug fixing at this point in time is called “hot fix”, and a product may have multiple hot fixes branches.
After tiresome working days, the team can finally release their product. Here, the code prepared for a newer version will be separated from the main development branch (often called dev), and brought to another branch to perform tasks like: test, build, and so on. The development process will still continue in the dev branch as well as in other features branches.
Each project needs only one dev branch, which is used throughout the branch, and will be the reference for all members for new codes. When developing a new feature, the project members will take the newest code from here to continue working.
Features branches store feature source codes developed by different teams and team members of a project.
After we release a new version, merge source code into master and tag it with 1.0, we suddenly discover a critical issue, and need to create a new hot fix branch based on the 1.0 source code on master. This process is often done by experienced members of the team, as it is quite rushed and high-risk. After completing the hot fix and finishing necessary product testing tasks, we will immediately release the new 1.1 version and retag it as 1.1 for tracing. Don’t forget to merge the hot fix’s code back to the dev branch for the next releases.
After the feature development process is completed, we will need to prepare a code branch for the new version release. This branch will be taken from the dev branch with the desired commit, and after separating the release branch, product testing for release preparation will continue in the new branch, while the development process stays on the dev branch. If any error occurs during product testing for release preparation, then it will be fix similar to the hot fix process. Commits, meanwhile, will brought to the release branch and dev branch for future releases.
New features development
A project may comprise of many people, with various different features, and thus when the team want to develop a new feature, they will need to take codes from the main dev branch. Then, after the new source code had passed all required test cases, they will merge it back to the main dev branch.
Features branches may include several smaller branches, or stay as single branch based on the main dev branch, depending on the complexity of the features being developed.
In the above picture, the new feature is separated from the 3rd commit, then developed with 3 commits, and finally, merged back to the main dev branch upon completion. Similarly, while new features are being developed, other teams still continue their work, and their codes will still be merged back to the dev branch upon completion.
The article has introduced an organization and source code management workflow utilized in the author’s previous projects. Depending on which project you are working on, other models may be more suitable. However, it is important to remember that when delegating permissions to teams, you should limit access to the main branches to minimum. Particularly, these branches should only allow writing/reading permission for specific people, to avoid losing all source codes without any way to recovery.
We wish you success on your endeavors!
Tran Huu Lap – FPT SoftwareRelated posts: