As the team grow, code versioning and deployment is getting more complicated. Gitflow workflow is a versioning strategy I learned this year. At the early time, all our engineers in the team is committing features under the same development branch which is centralise workflow… and this happened:
- James is building feature A and is fully tested and ready for deploy.
- Rose building feature B and still doing acceptance test.
In centralise workflow, all features share the same development branch. In this case, feature A will not be deliver because the feature B is not ready yet.
In another side, when using Gitflow strategy, feature A and feature B will be branch out from master then commit to their own branch. In this case, the feature can be deliver without the concern of other feature’s status.
This is what I do when feature is ready to deploy. Isn’t this cool😎? Indeed, I have already branch out from master and commit code in the new branch.
Gitflow workflow help us omitted lots of troubles on managing codes, there is risk it bring along. That is when a stakeholder doesn’t understand git enough. Error might happen and might losing some source code, take it as a lesson. Codes that lost can be found in Git Log in most cases.
Attached video has very good explanation on Git flow strategy. It gave me a very clear idea of how Gitflow workflow works.
