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

Question

Here is the 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.

Answer 1

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 2

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

Answer 3

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.