Is it good idea to Manage Azure DEVOPS Git DEV and Release Branches in 2 Different Repositories?

Question

We are moving from TFVC to GIT, in TFVC we used to manage DEV branch for development and Master branch for release.

TFVC Branches Management

1. Every Developer will work on DEV Branch and they will commit their changes on DEV Branch.
2. Build will be deployed from DEV Branch on Staging ENV ( staging is our internal environment. )
3. Once we are done with PCR / New Integrations ( DEV Branch) for on going Sprint and we are ready for live we used to merge changes from DEV TO Master Branch.
4. Build will be deployed from Master on UAT / BETA ( Clients testing environment).
5. Once they verify and give go signal, same build will be deployed on Live.

Using this way use to manage only DEV and Master branches in TFVC.

Now in GIT every developer is creating his own branch when they start working on any PCR/ New Integrations. Once they are done with changes these will be merged in Master using Pull Request ( I know we can delete the branch after changes are merged, but i have seen people are not following this flow) .

Only 2 months back we started using GIT and right now I can see more than 10-15 branches, we don't have any dedicated resource who will take care of managing branches and this workflow.

After development is done for current Sprit / PCR / Hotfix we will deploy build on Staging / UAT / LIVE. New branch will be maintained with each live deployment / release.

So is it good idea to Maintain Development Branches in DEV Repository and For Live / Release branches create ( Master / Release ) repository to maintain release branches.

This way I just want to keep things separate, do you think its good idea? Will there be any issues in future we will face or is their any better way of doing it?

Answer 1

Is it good idea to Maintain Development Branches in DEV Repository and For Live / Release branches create ( Master / Release ) repository to maintain release branches.

It is one solution for your situation. Even though you manage key branches in different repositories, the developers still will create much more sub-branches and leave them here if they don't check "Delete after merging" when they complete this pull request or they manually delete them. And it disobeys the Git workflow in some degree.

Thus, Azure DevOps provides repository permissions manage, as below. See: Set repository permissions for Git or TFVC for details. You could set different permissions to allow specific members can create branch. And in the Branches page, you could view who is the author of branch.

In addition, you could set branch policies by following this doc: Improve code quality with branch policies, add code reviewers to approve the code before completing the pull request.