问题描述
想知道在开源项目之外，是否有人使用forking git工作流程。他所在的公司主要由历史悠久的开源开发人员组成，因此他们一直使用forking工作流程，并且不太愿意转向github flow。由于Jenkins不支持在stash上获取repo的fork，构建和测试自动化非常困难且效果不佳。用户想知道是否有一种标准的方法来支持forking工作流程，或者团队以这种方式开发是否现实。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
你可以使用Webhook从存储库中读取信息，这样你就可以访问动态信息，比如存储库的URL以及为每个存储库创建或启动特定的作业。
Generic Webhook Trigger插件支持传递参数。这可能不是最佳解决方案，因为它涉及配置每个Git存储库，但它非常强大和灵活。
希望你能找到一个好的解决方案。
方案2
请注意以下操作注意版本差异及修改前做好备份。
我遇到过一些使用forking工作流程的情况，但每次我看到它时，它都是在不应该使用它的情况下使用的。
我所在的公司主要由历史悠久的开源开发人员组成。我对此表示怀疑。当我遇到使用forking的团队时，是因为他们不是经验丰富的开源开发人员。经验丰富的开源开发人员会理解forking提供的安全性和隔离性，以及为什么项目外部人员必须fork才能做出贡献。他们还会理解同一团队的成员在同一代码库上工作会更好。
当我通常看到forking时，要么是因为有人设置了这种方式，然后后来的所有人都认为这是正确的方式。我在与机器学习团队合作时看到过这种情况，机器学习研究人员不是真正的开发人员，他们认为每个人都需要fork所有的存储库。
我看到forking的另一个原因是因为公司没有任何CICD，并且他们在将坏代码推送到主分支、跳过PR流程、审查流程或覆盖彼此代码方面存在问题。
我曾经在fork上使用Jenkins，没有遇到问题。也许是你使用的SCM不同。我使用的是私有的GitHub企业服务器和Github pipeline插件，在新的PR上运行多分支作业。
你已经说得很对。与单独的fork相比，它不利于协作，最好还是在同一个存储库上工作。
方案3
请注意以下操作注意版本差异及修改前做好备份。
git的设计初衷是通过forking来解决每个人都与一个单一的仓库绑定的问题。与Subversion或CVS（甚至是Visual SourceSafe）相比，从远程origin克隆的本地仓库在实际上是一个fork的副本。
在中央托管的Git SaaS提供商中，这种方式也演变为将项目分叉到以下两种情况之一：
1. 分叉为一个新项目 – 在另一个项目停止的地方继续。
2. 临时分叉 – 为了更容易管理Pull Request（仅当在同一提供商内时）。
对于完全分离管理的生态系统，没有支持forking工作流程的固有好处，因此我个人认为没有标准的支持forking工作流程的方法。对于开发代码和软件来说，这种方式没有好处。但对于开发DevOps解决方案来说，情况就不同了，因为你需要一个与其他环境完全隔离的环境来测试你的DevOps代码。