Git Work Flow Architecture
2 min readSep 18, 2022
Git Branching/Git Work Flow to manage proper Branching
Git Work Flow Architecture is ideally suited for projects that have a scheduled release cycle. Actually, Git workflows are nothing special. They are just a documented branching and integration strategy teams can adhere to in order to allow lots of people to work on a project together seamlessly.
Here I have shared the process and branching structure that I maintain for my projects.
Structure of Branch Name :
- Feature (Create a branch for each feature like User Management, Project management)
- Dev (Serves as an integration branch for features)
- Release (Create a branch for each release, it can be multiple features or per Sprint wise delivery feature)
- Master (Master branch stores the official release history. Only the Latest version code will be there)
- Hotfix (Create a branch, if any minor change like field name, label name, or any bug arises from the production server)
Process/Flow :
- Developer pull the latest code from the Dev branch
- Create a New Feature Branch (ex: user management)
- Developers work locally and Push/Pull and commit to featuring branches based on each feature
- Completed task/feature, tested and resolved all issues for this feature.
- Merge the feature branch into the dev branch.
- Delete feature branch.
3. Create a New release branch by forking the Dev branch ( Ex: release 2.1 — created by any senior developer)
- Deployed to a staging server for QA testing
- Bug resolved changes or commits to releasing branch.
- Deployed the latest code in the staging server.
- Merged into dev branch and as well as the master branch
- Delete release branch
4. Master branch :
- The Master branch has the latest code. Now need to tag with a version number in the master branch (ex: 2.1) git tag -a v2.1 -m “my release 2.1”
- Deployed to production server
5. Create a new Hotfix branch by forking the master branch:
- Changes, resolve, tested, and commit to the hotfix branch
- Once tested, must be merged into the master and dev branch
- Tagged again with a version number (ex: 2.2) git tag -a v2.2 -m “release 2.2 bugs resolved”
- Deployed to production server
- Delete Hotfix branch
Summary:
- The Master branch is the rolled-out production code with tagged versions. It means it’s a final version of your Production Deployment.
- Only hotfix and release branches get merged into master (Also dev branch if needed).
- Feature branches are merged into the dev branch.
- Only bug fixes, not new features, are merged into release branches. If the development of a new feature needs to continue, it is merged into the dev branch, not the release branch.
