We have the below branching model in GitHub for our applications to release them in multiple environments.
Overall Branching Strategy
Points to be considered - In our organization multiple teams work on single repository with different release timelines. Generally, we follow the weekly releases like in a month there will be 4 releases (R1, R2, R3 and R4), multiple projects (Project-X and Project-Y) can be part of one release.
Branch Details
- master => Stable / Production Copy, merge access is restricted with CI Team members
- release-month-R1 => weekly release branch (Staging Deployment as it’s a merge build for multiple projects), merge access is restricted with CI Team members
- project-A => Project Branch per Team, Protected and Pull Request & CI Server Check (Build+UT+Code Quality Metrics) is Mandatory for Code push. (Dev and QA Deployment)
- ft-Project-A-CSS_fix => feature branch for Project A, Open for development no restrictions.
Below are regular scenarios we have been through
Use Case 1
Project branches that are part of current week release only exists. Each project is a branch and one team contribute to this branch with multiple feature branches, let’s say Project-X and Project-Y are part of release-mar-R1. Team A, B works on Project-X, Y respectively. On a certain agreed merge date, the teams will merge the project branches to release-mar-R1 and resolves the conflicts if any through respective Project’s feature branch by rebasing code. We haven’t seen any issues in this use case. Also, we create Tags for DEV and STG builds.
Queries
• How to revert ft-Project-X-1 changes after merging into Project-X?
Use Case 2
Project branches that are part of different weekly releases.
Project-A will be part of release-mar-R1
Project-B will be part of release-mar-R2
After Project-A moved to Production, the developers will do a Pull Request to any existing/new feature branch of project B and merges the R1 changes. Also, if there is any emergency bug fix/hot fix for R1 before R2, the same will be merged back to Project-B branch with a PR.
Queries
- Any option to rebase automatically the other Project branches belongs to R2 release, when R1/hotfix merged to master.
Use Case 3
Project branches that are part of different weekly releases and some future development or POC.
- Project-A will be part of release-mar-R1
- Project-B will be part of release-mar-R2
- Project-C not identified the release week, when the release date is identified need to be aligned for the upcoming release week.
The below model is working fine if Project-C is rebased/merged for every release and hotfix.
Queries
- When developers miss a release/ebf merge the changes which involves same set of files, we see the Project-C changes are missing when the next release changes are re-based. Any suggestions to avoid this problem?
