Nowadays, there are many git workflows for development teams. The suitable git workflow for a specific team and projects depends on some elements like: scale of the project, size of the teams, the complexity of the business…
Git supports many ways and commands for us to manage git progress. But when the project becomes bigger and complicated in the life time, the number of developers join to the project can increase over time, then the git management become more complicate and hard to control. At this time, one of the most important things to keep the project runs smoothly is that we have to keep every developer does follow the workflow. So, how can we keep everything goes follow the correct workflow, simplify the workflow management ?
In Ecommage, most of our projects are quite complicated in business and scale of the project increases over time. This will make the project development management becomes complicated in the life time of the project. To solve this problem, we build and apply an Git Flow Workflow into projects.
With Git Flow Workflow, it requires the developers work on the correct workflow, let the developers know how to do for the next steps on each situation with a very simple action.
Here are some benefit of the Git Workflow:
- The workflow become very simple to follow and track.
- The developers do not need to remember so many git command. He just need to remember several commands with the same format.
- The developers do not worry about whenever he does wrong or correct. Ecommage Git Workflowflow ensure the action the developers do always correct
The next sections aim to guide the developer how to install and use the Ecommage Git Workflow.
So, while reading all the documentation online with regards to this workflow I went down quite a few rabbit holes trying to understand it and trying to work with it. Once I got the hang of it, I tried to think of a different way of doing branching and development better and for some reason kept coming back to this simple workflow. It seems to work quite well and once you get the hang of the concepts they discuss, you’ll probably try to use your old methods and find they’re lacking a bit in certain scenarios. One thing I can say about Git-Flow is that it’s not easy and it adds some complexities that you’ll find frustrating when you start, but once you start getting us to it, it will work for you, your team as well as your Organization.
To give you an overview you can have a look at the following flow diagram:
If you look at the above image it might come across as being overwhelming at first glance. I’ll break it down in the coming sections so as to make the overall flow of what actually happens in the image above a bit easier to understand.
Branching – Explanation
In Git-Flow everything is broken down into branches. When you do new feature development, you create a new branch off the develop branch. If you’re working on a hotfix, then you branch off master and if you’re busy with release hardening then you branch of the develop branch. So, let me explain the various branches before continuing. In Git-Flow there are two main branches that you should try and keeps as clean as possible and always in a releasable state. The one is master which can be seen as your released code base i.e. what you currently have running in Production. On the other hand you have the develop branch which can be seen as the integration branch of code that consists of completed features and hotfixes that are stable and that should consist of complete unit test suites. Your inter-team as well as support developers will integrate in this branch and you Continuous Integration server will also run against this branch to do your daily builds, run your complete test suites as well as generate test reports such as code coverage and release notes from. To break this down even more I’ll go into how development should be done when following the Git-Flow workflow while doing development.
Feature branches are branches created to do new feature development and should be branched off the develop branch. A feature in this case being a small set of code that completes a sub-section of a business case or in SCRUM terminology it could be a scenario where a group of scenarios complete a story. I always try to make the lifetime of a feature branch as small as possible and if at all possible, something that can be completed by an individual or team of developers in a single day. This makes the merging of various features back into the develop branch much simpler and allows for better Continuous Integration. Once the feature has been completed and merged back into the develop branch it should be deleted so as to ensure that no new code can be added to that specific feature branch.
At some point when you’ve done enough feature development you’ll reach a stage where business is happy with what you have and will want to do a release. At this stage you’ll start a release branch by branching from the develop branch where all the relevant teams and developers will be doing development that ads no new features, but rather stabilizes the features that was developed in the feature branches. This process is called “Release Hardening”. The only thing the developers will be allowed to do on this branch is fix the issues that were picked up by the Quality Assurance team while doing User Acceptance Testing. Release notes and Release packages will be generated from this branch and these will be pushed into your User Acceptance environment for stakeholders, selected users and QA Testers to test to ensure the quality is according to company standard.
The process of generating Release notes and Release packages as well as deployment to the UAT environment should be automated as far as possible, but that’s another article altogether. As the team doing UAT comes across inconsistencies or “unintended features” J they can then raise these things to the team of developers assigned to the hardening process that will be able to do the fixes, run the tests and push their changes to this branch. The team(s) assigned to this hardening process should preferably be the same team(s) that was involved in the feature development or selected members from each of the relevant teams. Once the code has been updated to fix said inconsistencies the UAT team should be notified that they can do a Release on these changes who will then go through the process of ensuring that the changes and fixes does in fact fix the inconsistencies.
After the UAT process has been completed and the Release has been signed off by relevant parties, the same package that was last released to the UAT environment should be pushed to Production and the Release branch should be merged into both the master branch as well as the develop branch to ensure that any fixes that were applied is merged into the develop branch as well as to ensure that the version of the code that is released into production is also the version of the code on which hotfixes are applied. Once merged into the master and develop branches you should delete the Release branch.
Of course there will be the few and odd inconsistency or “unintended feature” that slips through the cracks. In these cases you should create a hotfix branch of the master branch. This is different from the previous sections where the branches were created of the develop branch seeing that you’re now trying to fix something that is currently running in Production and you would like to push it to Production once it’s been fixed and the QA department is happy to do so. On completion of the fix this hotfix branch should be merged into the master as well as the develop branch to ensure that the fix is applied for future releases of bother hotfixes as well as new releases. In the figure above you’ll see that a Tag is assigned to the fix in the form of [version].[hotfix].
Once you’ve been through a specific Release process and the hardening is complete you’ll want to change the version of your product. You’ll want to do the same if you have a hotfix of a support item that needs to go out. In these scenarios you’ll also want to use different ways to show in your version which was a Release and which was a Hotfix of Support Release. I know that every company has a different strategy for this, but in my case I like to keep things simple, so I simply version my stuff as [version].[hotfix] where version would be a major release and hotfix would be an item that was fixed under the hotfix branch. By Tagging your source code you ensure that you’ll be able to go back to a specific version as it was at that stage of your product and you should also feel assured that you can release a specific version of your code after applying a hotfix.