Git Branch Strategy that suites for all the dev teams at my company

Question

• We have a mono-repository on Github, multiple teams work off of master by creating new branches based on master and creating pull requests regarding the features/bugfixes, etc.
• For my team, though, the majority of the time (though, not always), the things we work on cannot directly merge onto master, because it goes through the product manager’s approval and client’s approval which may take a while to implement, and the Epics that we work under require a very long time to deliver (usually 4 weeks of development, and 1 week of reviews/adjustments) hence require multiple team members to work on different pieces of it.
• To be able to work in such a branching strategy, we are currently working as follows:
• We create a new branch named as “releases/*” and that becomes our branch to be merged to master (meaning going live to production)
• We create sub-branches based on releases/* branches that get merged to “releases/* branch via pull requests. That way, multiple people can work on the epic tasks at the same time, meaning that there will be several sub-branches branched off of the releases/* branch.
  • This allows us to Review the sides of the epic in much smaller phases that way, not a giant Pull Request is being reviewed at once.
• Once everything is good and merged onto releases/* branch, we merge the releases/* branch to master, which means that the Epic is completed, the changes are live.

Please take a look at the diagram below to get a visual understanding

Problems that we have with this approach:

• When working in sub-branches based on releases/* branches, sometimes we need a change from another sub-branch at the same level, and we are constantly cherry-picking the changes we may need to be able to work with our own task. Is that the only approach, or is there a better approach for these?

• We do not have branch protection on releases/* branches for CI tests.

  • We are able to accidentally merge a Pull Request to releases/* branches from a sub-branch when the tests are failing. We tried adding branch protection to releases/* branches so that they are protected for CI tests being passed, however, once we enable this setting in Github, we are not able to do any “push” required actions to the releases/* branches, (rebasing with the master for pulling in a change we need that other teams implemented or doing a merge commits then pushing, etc.)
    • From the Github’s branch protection setting for enabling status checks: "When enabled, commits must first be pushed to another branch, then merged or pushed directly to a branch that matches this rule after status checks have passed."
    • This ^^ means that we can only create a pull request to retrieve any changes from the master branch to releases/* branches and rebase the sub-branches accordingly.

Any recommendations?

Answer 1

Mono repos come with their own interesting set of problems. You can use a modified adaption of git workflow in your scenario. Please read through the git workflow doc above, before reading further to have a better understanding.

A tentative adaptation could look like this.
Branches:

• master: Eternal stable branch
• next: Integration branch for a particular project / epic
• feature/* : Topic branches for individual changes

Each individual piece of change has it's own topic branch. To test and verify a build, all individual topic branches are merged into next branch on demand. This way, if you need an additional branch or commit to test along with your changes, all you would need to do is just merge it into next.

The next branch gets reset with master at a fixed interval (every day at 3 PM or every Mon at 3 PM) depending upon your overall deploy and release cycle, across all teams and services. Depending upon your needs, there could multiple next branches, co-existing at the same time (one for more frequent day to day changes, and a couple of more for each such long running project or epic). You can also setup some automation to tag a set of topic branches, that have been reviewed and accepted, so that they get merged into next branch of your project or epic automatically.

You can then enable the Github branch protection on all next branches, as changes could only reach them via a PR. As per git workflow, you deploy from the integration branch (next) and merge the topic branches directly to master. This will require some discipline and perhaps some automation in reality for things to work seamlessly. You might also have to change your deployment pipeline to accommodate such a change. Last, but not least, you might also need to change developer mindset from thinking with git flow.