<blockquote>
<p>Is there a standard way of supporting the forking workflow, or is it just not realistic for a team to develop this way?</p>
</blockquote>
<p>That's the only question I see in your text, so I'll try and address that with my knowledge.</p>
<h1>'forking' around</h1>
<p><code>git</code> was designed to solve the problem of a single monolythic repository everyone are tied to by 'forking'. Compared to Subversion or CVS (or even Visual SourceSafe) a local repo cloned from a remote <code>origin</code> is in all practicallity a fork of the one-true-source (<code>origin</code>) repo.</p>
<p>This has evolved in centrally-hosted Git SaaS providers to also fork projects to either:</p>
<ul>
<li>Fork into a new project - pick up where another project stopped.</li>
<li>Temporary forking - For easier Pull Request management. (Easier only if it's within the same provider)</li>
</ul>
<h2>back to the question</h2>
<ul>
<li>Is there a standard way of supporting the forking workflow</li>
</ul>
<p>No, as there is no inherent benefit to manage complete ecosystems in separation.</p>
<ul>
<li>Is it realistic for a team to develop this way ?</li>
</ul>
<p>It depends. For developing code and software, there is no benefit, so I would personally answer - no. For developing DevOps solutions - that's another case, as you need a complete envrionment separated from the others to test your devops code.</p>

CC BY-SA 4.0
2023-05-17T21:58:06.467Z
2023-05-17T21:58:06.467Z
Lockszmith
<blockquote>
<p>Is the forking git workflow used outside of open-source projects?</p>
</blockquote>
<p>I have run across it a few times but every time I have seen it, it was being used in a situation where it shouldn't have been used.</p>
<blockquote>
<p>The company I work for is mostly comprised of historically open source developers.</p>
</blockquote>
<p>I doubt this. When I have run into teams that used forking it was because they were not experienced open-source developers. Experienced open-source developers would understand the security and isolation that forking provides and why outsiders of a project have to fork in order to contribute. They would also understand that team members of the same team working on the same codebase would be much better off working on the same repository.</p>
<p>When I typically see forking its either because someone set it up that way and then all the people who came afterward thought that was the correct way. I have seen this more than once working with ML teams where the ML researchers are not real developers and thought everyone needed to fork all the repos.</p>
<p>The other reason I have seen forking is because the company did not have any kinda CICD and they had issues with people pushing bad code to the main branch, skipping the PR process, the review process or overwriting each others code.</p>
<blockquote>
<p>Is there a standard way of supporting the forking workflow, or is it just not realistic for a team to develop this way?</p>
</blockquote>
<p>I had Jenkins working fine with forks? I don't remember having issues with developers creating PR's on the &quot;main&quot; repo and then running automation on that one repo. Maybe its the SCM you are using. I was using a private GitHub enterprise server and the Github pipeline plugin to run multibranch jobs on new PR's.</p>
<blockquote>
<p>Separating into isolated forks doesn't seem to be as productive and working on a single repo together.</p>
</blockquote>
<p>You have nailed it. It's not as good for collaboration as just working on a single repo.</p>

CC BY-SA 4.0
2023-04-17T00:15:55.047Z
2023-04-17T00:15:55.047Z
Levi
<p>Maybe you can use a Webhook to read information from the repository. So that way you can access dynamic information such as the repository URL where to look the code, and even create or loaunch specifics Jobs for each Repo.</p>
<p><a href="https://plugins.jenkins.io/generic-webhook-trigger/" rel="nofollow noreferrer">https://plugins.jenkins.io/generic-webhook-trigger/</a> Support passing parameters.</p>
<p>I guess it's not the best solution, because it involves configuring each Git repository, but it's quite powerful and dynamic.</p>
<p>I hope you can find a good solution &lt;3</p>

CC BY-SA 4.0
2022-07-19T18:31:54.660Z
2022-07-19T18:31:54.660Z
navebinario
<p>Here is the <a href="https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow" rel="nofollow noreferrer">Forking workflow</a> if you're not familiar with it.</p>
<p>The company I work for is mostly comprised of historically open source developers. This has caused them to be stuck on the forking workflow and they're not extremely willing to move to the github flow. Since there's no support for Jenkins to pick up forks of a repo on stash, build and test automation is very awkward and doesn't really work. My question is: Is there a standard way of supporting the forking workflow, or is it just not realistic for a team to develop this way?</p>
<p>I would really like to move away from the forking workflow, but I have yet to see other companies utilize it. If there's a good way to support it then that would be fine. I just don't know what that would look like from a DevOps perspective. Separating into isolated forks doesn't seem to be as productive and working on a single repo together.</p>

CC BY-SA 4.0
2022-05-28T17:09:50.660Z
#1 Are you using a private git server or just a github/gitlab/bitbucket private repositories? #2 Why Jenkins don't support that? What plugins do you use? #3 Is your development team an internal staff or consulting like external freelancers?
JRichardsz
CC BY-SA 4.0
2022-05-30T16:31:35.510Z
1. private git server, Atlassian Stash.
2. There are many plugins that we use. I'm not sure why jenkins doesn't support it.
3. Internal staff team.
collin_tgz
<jenkins><git><build-pipeline>
Is the forking git workflow used outside of open source projects?
collin_tgz
# Is the forking git workflow used outside of open source projects?

(Asked by: username_0 on 2022-05-26)

Here is the [Forking workflow](https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow) if you're not familiar with it.

The company I work for is mostly comprised of historically open source developers. This has caused them to be stuck on the forking workflow and they're not extremely willing to move to the github flow. Since there's no support for Jenkins to pick up forks of a repo on stash, build and test automation is very awkward and doesn't really work. My question is: Is there a standard way of supporting the forking workflow, or is it just not realistic for a team to develop this way?

I would really like to move away from the forking workflow, but I have yet to see other companies utilize it. If there's a good way to support it then that would be fine. I just don't know what that would look like from a DevOps perspective. Separating into isolated forks doesn't seem to be as productive and working on a single repo together.

**Tags:** jenkins, git, build-pipeline

> **Comments:**
> **username_1**: #1 Are you using a private git server or just a github/gitlab/bitbucket private repositories? #2 Why Jenkins don't support that? What plugins do you use? #3 Is your development team an internal staff or consulting like external freelancers?  
> **username_0**: 1. private git server, Atlassian Stash. 2. There are many plugins that we use. I'm not sure why jenkins doesn't support it. 3. Internal staff team.  

---

## 3 answers

### Answer by username_2 on 2023-05-17. Score: 0 | Accepted answer

> Is there a standard way of supporting the forking workflow, or is it just not realistic for a team to develop this way?

That's the only question I see in your text, so I'll try and address that with my knowledge.

# 'forking' around

`git` was designed to solve the problem of a single monolythic repository everyone are tied to by 'forking'. Compared to Subversion or CVS (or even Visual SourceSafe) a local repo cloned from a remote `origin` is in all practicallity a fork of the one-true-source (`origin`) repo.

This has evolved in centrally-hosted Git SaaS providers to also fork projects to either:

* Fork into a new project - pick up where another project stopped.
* Temporary forking - For easier Pull Request management. (Easier only if it's within the same provider)

## back to the question

* Is there a standard way of supporting the forking workflow

No, as there is no inherent benefit to manage complete ecosystems in separation.

* Is it realistic for a team to develop this way ?

It depends. For developing code and software, there is no benefit, so I would personally answer - no. For developing DevOps solutions - that's another case, as you need a complete envrionment separated from the others to test your devops code.


---

### Answer by username_3 on 2023-04-17. Score: 0

> Is the forking git workflow used outside of open-source projects?

I have run across it a few times but every time I have seen it, it was being used in a situation where it shouldn't have been used.

> The company I work for is mostly comprised of historically open source developers.

I doubt this. When I have run into teams that used forking it was because they were not experienced open-source developers. Experienced open-source developers would understand the security and isolation that forking provides and why outsiders of a project have to fork in order to contribute. They would also understand that team members of the same team working on the same codebase would be much better off working on the same repository.

When I typically see forking its either because someone set it up that way and then all the people who came afterward thought that was the correct way. I have seen this more than once working with ML teams where the ML researchers are not real developers and thought everyone needed to fork all the repos.

The other reason I have seen forking is because the company did not have any kinda CICD and they had issues with people pushing bad code to the main branch, skipping the PR process, the review process or overwriting each others code.

> Is there a standard way of supporting the forking workflow, or is it just not realistic for a team to develop this way?

I had Jenkins working fine with forks? I don't remember having issues with developers creating PR's on the "main" repo and then running automation on that one repo. Maybe its the SCM you are using. I was using a private GitHub enterprise server and the Github pipeline plugin to run multibranch jobs on new PR's.

> Separating into isolated forks doesn't seem to be as productive and working on a single repo together.

You have nailed it. It's not as good for collaboration as just working on a single repo.


---

### Answer by username_4 on 2022-07-19. Score: 0

Maybe you can use a Webhook to read information from the repository. So that way you can access dynamic information such as the repository URL where to look the code, and even create or loaunch specifics Jobs for each Repo.

<https://plugins.jenkins.io/generic-webhook-trigger/> Support passing parameters.

I guess it's not the best solution, because it involves configuring each Git repository, but it's quite powerful and dynamic.

I hope you can find a good solution <3


---

