You must have come across a problem where everyone in the team is confused about how to manage code on Git, the bigger the project the more control you need over what and when is released. Your projects require more unit tests, which are now counted in hours. Usually, you don’t run such tests on branches where features are developed.
This can be resolved with Gitflow, invented and described by Vincent Driessen in 2010.
This approach employs maintaining two parallel branches as master and develop and feature
Master: This should always have what is in Live with all that is tested and ready to go live anytime
Develop: This always has code that is in current sprint/todo/doing, this branch is used for testing and merging code from other feature branches
Let me sort this with a simple example assume we have a team with 3 developers/collaborators/people John, Peter, and Ben each of them is assigned different task on the same project/source code
So below rules should be followed to have seamless Gitflow
- Each developer should create a new branch from develop with the name “feature/<topic-name>” for each task
- Every developer should start workday by fetch all and then merge into origin from develop
- At the end of the task raise a PR, and the collaborator can approve the PR to develop
- Repeat this :)
Release branches support the preparation of a new production release they allow for minor bug fixes and preparing meta-data for a release (version number, build dates, etc.) and final test is done