Github组织存储库，问题，多个开发人员和分支-最佳工作流程实践

奇怪的标题，是的，但是我认为我有足够的基础要掩饰。

我们在github上有一个带有专用存储库的组织帐户。我们要使用github的本机问题/拉动请求功能（就代码审查和功能讨论而言，拉动请求基本上正是我们想要的）。我们通过defunkt找到了工具中心，它具有一个很酷的小功能，它能够将现有问题转换为请求请求，并自动将当前分支与其关联。

我想知道是否最好的办法是让组织中的每个开发人员都分叉组织的存储库来完成其功能工作/错误修复等。这似乎是一个相当可靠的工作流程（基本上，这是github上每个开源项目所做的工作），但是我们希望确保我们可以跟踪问题并从组织存储库ONE来源提取请求。

所以我有几个问题：

1. 在这种情况下，按开发人员分叉的方法是否合适？看来这可能有点过大。我不确定我们是否需要为每个开发人员准备一个分支，除非我们介绍没有直接推送访问权限并且需要审查其所有代码的开发人员。在这种情况下，我们只想针对那些开发人员制定这样的政策。那么，哪个更好？所有开发人员都在一个存储库中，还是每个人的叉子？
2. 是否有人对集线器工具（特别是拉动请求功能）有经验？如果我们按开发人员分叉（甚至针对特权较低的开发人员），那么集线器的请求请求功能将对上游主存储库（组织的存储库？）的拉取请求进行操作，还是有不同的行为？

编辑
我对问题，分支和请求请求进行了一些测试，发现了这一点。如果在组织的存储库上创建问题，则将存储库从组织存储到您自己的github帐户，进行一些更改，并合并到存储库的master分支。尝试运行hub -i <issue #>时，出现错误User is not authorized to modify the issue。因此，显然，工作流程将行不通。

在这种情况下，按开发人员分叉的方法是否合适？看来这可能有点过大。我不确定我们是否需要为每个开发人员准备一个分支，除非我们介绍没有直接推送访问权限并且需要审查其所有代码的开发人员。在这种情况下，我们只想针对那些开发人员制定这样的政策。那么，哪个更好？所有开发人员都在一个存储库中，还是每个人的叉子？

我想这取决于您团队的规模。我曾经在一个小型团队中工作，当时我们只有一个仓库，而功能在该仓库中拥有自己的分支机构。这对我们来说很好。

但是，我现在经常为一个更大的开源项目做贡献，那里有几十个人可以访问中央仓库。我们仍会在个人仓库中进行所有重大开发，并提交功能的PR，以便可以检查代码，尽管可以直接推送错误修正。主存储库仅包含主分支和释放分支，从而使其保持混乱。功能分支位于个人存储库中，因此仍可以被其他人看到（为其建立早期PR会提醒团队中的其他人正在进行功能的开发）。我可以将这个工作流程推荐给开发人员不多的任何项目。唯一的缺点是必须使用多个遥控器。

如果您重视代码审查和代码质量，那么按开发人员分叉的方法是非常好的方法。使用拉取请求的好处是，它将责任从维护者转移到开发者。

开发人员希望将其代码放入主分支，并要求将其包含在内。

这与人们承诺的旧模型有很大不同，后来审阅者不得不告诉他们：“哦，您几周前所做的事情还不太好，请立即解决。”

我们在公司中使用此模型。拉取请求使代码请求变得可行，鼓励讨论其他人的代码，并且通常对代码质量有所帮助，即使是最先反对新工具的开发人员也是如此。我觉得这也使人们更加重视代码审查，因为审查者必须积极地将代码合并到主分支中，而不是在已经提交代码之后只说“ ok”或“ not ok”。

我不会为所有事情做所有的分叉和分支。对于GitHub上的开源gem来说，这是一个很好的模型，但是您的模型位于通常对更改具有更高信任度的组织内。

源代码控制的一个重点是您可以看到，撤消，反向等更改。恕我直言，在您的情况下执行大量的分叉和分支是过大的。

我会为以下事务保留分支机构：版本升级，更改其中一项技术，在子模块上工作3个月，而这些子模块与主要基础没有什么共同之处。

我可能根本不在组织内分叉。这种模式似乎更适合本质上与内部项目不同的开源项目。

我会将您的重点转移到测试和代码审查上。人们在写测试吗？他们好吗？代码审查完成了吗？