Answers: <p>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.</p>
  <p>As this <a href="https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow" rel="nofollow noreferrer">Atlassian tutorial</a> states, &quot;The Forking Workflow is most often seen in open source projects&quot;. The reason for this is that the fork mechanism was created for a very specific problem, &quot;How do you give complete strangers the ability to contribute to a project without giving the world write permissions to your repository?&quot;.  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 <a href="https://rads.stackoverflow.com/amzn/click/com/1491911182" rel="nofollow noreferrer" rel="nofollow noreferrer">Git for Teams</a> that describes git workflows and their intents very nicely.</p>
  <p>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.</p>
  <p>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, <a href="https://docs.microsoft.com/en-us/azure/devops/repos/git/pull-requests?view=azure-devops" rel="nofollow noreferrer">&quot;Pull requests can come from either <strong>topic branches</strong> or from a branch in a fork of the original repository&quot;</a>.  A <a href="https://stackoverflow.com/a/284817/574588">topic branch</a> is just a fancy term for a <code>bug</code>/<code>feature</code>/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 <a href="https://docs.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops" rel="nofollow noreferrer">branching policy</a> of a minimum number of reviewers for a pull-request to the master branch.</p>
  <p>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:</p>
  <ol>
  <li><a href="https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow" rel="nofollow noreferrer">gitflow</a> which is great for teams that are new to git and has some awesome <a href="https://danielkummer.github.io/git-flow-cheatsheet/" rel="nofollow noreferrer">tools</a> and many tools incorporate the gitflow pattern, like <a href="https://blog.sourcetreeapp.com/2012/08/01/smart-branching-with-sourcetree-and-git-flow/" rel="nofollow noreferrer">sourcetree</a>.</li>
  <li><a href="https://www.toptal.com/software/trunk-based-development-git-flow" rel="nofollow noreferrer">trunk-based development</a> a very lean development process.</li>
  </ol>
  <p>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.</p>
  <p>Please let me know if this did not answer your question or if you have any further questions.</p>
  
Answers: CC BY-SA 4.0
Answers: 2020-11-09T17:18:45.110Z
Answers: 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.
Answers: Marko A.
Answers: CC BY-SA 4.0
Answers: 2020-11-10T02:12:27.153Z
Answers: @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.
Answers: Michael Erpenbeck
Answers: CC BY-SA 4.0
Answers: 2020-11-07T04:56:44.947Z
Answers: 2020-11-07T05:10:55.570Z
Answers: 2020-11-07T05:10:55.570Z
Answers: Michael Erpenbeck
Body: <p>We have an on-premises Azure DevOps Server and like to use the Git workflow &quot;Fork-Clone-Push-PR&quot;.</p>
  <p>In the moment of forking the system let allow us decide into which project and under which name the repository should get forked.<br />
  Forking it in the same project would mean tons of such forks after a while, which looks ugly.</p>
  <p>So a dedicated project &quot;Forks&quot; might be the solution to host all these forks. But is this a nice option?</p>
  <p>Are there any best practices or tips &amp; tricks on how we should proceed?</p>
  
Tags: <git><azure-devops>
Title: Best practices to maintain forks of Git repository in an on-prem Azure DevOps Server
UserDisplayName: Marko A.
ThreadText: # Best practices to maintain forks of Git repository in an on-prem Azure DevOps Server
  
  (Asked by: username_0 on 2020-11-04)
  
  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?
  
  **Tags:** git, azure-devops
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2020-11-07. Score: 1
  
  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](https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow) 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](https://rads.stackoverflow.com/amzn/click/com/1491911182) 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"](https://docs.microsoft.com/en-us/azure/devops/repos/git/pull-requests?view=azure-devops). A [topic branch](https://stackoverflow.com/a/284817/574588) 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](https://docs.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops) 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](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) which is great for teams that are new to git and has some awesome [tools](https://danielkummer.github.io/git-flow-cheatsheet/) and many tools incorporate the gitflow pattern, like [sourcetree](https://blog.sourcetreeapp.com/2012/08/01/smart-branching-with-sourcetree-and-git-flow/).
  2. [trunk-based development](https://www.toptal.com/software/trunk-based-development-git-flow) 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.
  
  > **Comments:**
  > **username_0**: 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.  
  > **username_1**: @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.  
  
  ---
  
  