# Best practices to maintain forks of Git repository in an on-prem Azure DevOps Server

We have an on-premises Azure DevOps Server and like to use the Git workflow "Fork-Clone-Push-PR".

In the moment of forking the system let allow us decide into which project and under which name the repository should get forked.
Forking it in the same project would mean tons of such forks after a while, which looks ugly.

So a dedicated project "Forks" might be the solution to host all these forks. But is this a nice option?

Are there any best practices or tips & tricks on how we should proceed?

I think that the best way to answer your question is to take a step back to focus on your goal. Based on the fact that you're using an on-premise Azure DevOps Server, I am assuming that you're working on a closed-source project (I apologize if this assumption is incorrect). I believe that your goal is to control quality via PRs in this environment.

As this Atlassian tutorial states, "The Forking Workflow is most often seen in open source projects". The reason for this is that the fork mechanism was created for a very specific problem, "How do you give complete strangers the ability to contribute to a project without giving the world write permissions to your repository?". Note, I occasionally use the forking mechanism for other fairly advanced purposes as well, but this is its primary use. There is a fantastic book called Git for Teams that describes git workflows and their intents very nicely.

My first experience with git was working in GitLab on a closed-source project. We were a team of ten employees working on an enterprise software application. We were required by the process to fork the repo and create a PR to get our changes back. The result was a big learning curve for the engineers who were new to git and a lot of confusion around setting up remotes and getting the latest code.

Many people erroneously think that the only way to have a pull-request mechanism is to fork the code, probably because their only exposure is through PRs in the open-source community. To quote Microsoft, "Pull requests can come from either topic branches or from a branch in a fork of the original repository". A topic branch is just a fancy term for a bug/feature/etc branch. When I am working with a closed-source group that is new to git, I will often disallow forks in the Project/Repository settings and I will enforce a branching policy of a minimum number of reviewers for a pull-request to the master branch.

Regarding best practices for branching strategies in git, the book I mentioned above is a great first step. There are many standard branching strategies, a couple examples are:

1. gitflow which is great for teams that are new to git and has some awesome tools and many tools incorporate the gitflow pattern, like sourcetree.
2. trunk-based development a very lean development process.

Regarding your original question, I suspect that creating a new Azure DevOps project to store all of those unsightly extra fork repos would just add another level of complexity to your work. You would need to enforce security for both projects, manage users and permissions for the new project, etc. In this case subtraction is likely better than addition, I suggest removing forking and using a good branching strategy for your project (if possible). It would simplify your life significantly.

Please let me know if this did not answer your question or if you have any further questions.

• you brought me on the right track. I was not aware that access permissions can be defined on the branch level. I thought we need all the forks to keep the "main" repo write-protected for its own. – Marko A. Nov 9 '20 at 17:18
• @MarkoA., I am glad it helped. Yes, it is a best practice to lock down the master branch with branch policies. You will find git is much simpler to use once you move from forking to the master branch. Let me know if you have any further questions. – Michael Erpenbeck Nov 10 '20 at 2:12