我是在一家小公司从事私人 GitHub 存储库的少数开发人员之一。repo 是我们老板在他的 GitHub 帐户下创建的，所有开发人员都可以推送访问它。
您可能知道，即使您没有付费订阅，也可以分叉主存储库，分叉仍将保持私有。并且每个添加到原始 repo 的人都会自动添加到 fork 的观察者列表中（我不知道为什么）。
这是我前一段时间出于好奇所做的（我不知道我能做到这一点）并且因为我认为将我的工作中的分支和临时内容保留在主仓库之外以保留内容会很好干净的。但是今天我的老板问我为什么要这样做，除了我上面说的，我想不出一个很好的理由。
是否有充分的理由在 GitHub 上分叉私有仓库而不是直接推送到主仓库？
需要分叉你老板的仓库的一个原因是他不允许你直接向这个仓库做出贡献。但是，由于他允许您直接访问，因此没有明确需要进行分叉。正如@Diego 指出的那样，GitHub 喜欢让用户从他们自己的存储库中推送和拉取，然后通过拉取请求将更改提交到上游存储库。但是，分叉不是审查更改所必需的。一个简单的替代方法是在您老板的远程存储库中创建功能分支，并让他查看这些更改。
我认为对为什么需要私有分叉的最佳描述是Atlassian 对分叉工作流程的解释。以下是我们如何处理我们的存储库、分叉和拉取请求。它的规模远远超过少数开发人员，并在合并之前保持隔离。
设置本地工作副本：
您的公司有一个中央付费 GitHub 帐户，其中包含一个或多个私有存储库。这些持有存储库的“黄金副本”。该存储库还与 TeamCity 等持续集成 (CI) 工具以及自动部署工具相关联。
中央公司存储库有两个分支。“master”分支是生产中的分支，“development”分支是部署到 QA 服务器的分支。您甚至可能有第三个长期存在的分支用于“登台”服务器。
开发人员将存储库分叉到他们自己的个人 GitHub 帐户。
开发人员将从他们的个人分支克隆到带有git clone git@github.com:username/reponame. 这将使“原点”指向他们的个人分支。
开发人员还添加了指向公司存储库的“上游”（命名约定）。这是通过git remote add upstream git@github.com:company/reponame.
这是新工作副本设置的结束。现在我们可以完成日常任务了。
对于开发人员来说，在创建新的功能分支之前，他们应该更新他们的本地开发分支
git fetch upstream && git checkout development && git merge
--ff-only upstream/development && git push origin development
```.
在开始修复问题或添加功能之前，在本地工作副本中创建一个功能分支。这可以用
git checkout development && git checkout -b new-branch-name
（如果我正在处理 GitHub 问题，我的分支名称是“i####-issue-description”，其中 #### 是 GitHub 问题编号。）
开始在本地处理功能分支，进行提交。您可以选择立即将它们推送到“原点”（GitHub 上的个人分支）。
一旦您对您的功能/修复分支感到满意并将其推送到“原点”，您将创建一个 GitHub 拉取请求 (PR) 以将其合并到公司存储库的“开发”分支中。这为您提供了一个很好的 UI 来查看更改，验证它们是否会干净地合并到公司存储库“开发”分支中。如果您正在使用 CI，那么您还可以在允许合并之前让 GitHub 对您的代码运行单元/集成测试。
一旦您的功能分支合并到公司存储库中，您的本地工作副本或您的个人分支中就不再需要它。但我通常会在将更改部署到生产环境后将它们保留 2-3 个月。
我们通常在“开发”分支上对事物进行质量检查，然后组合一个 PR 将更改从“开发”拉到“主”以进行最终部署。
有时您会遇到合并冲突，您将需要重新设置您的功能分支。
将最新的“开发”副本放入您的工作副本中
git fetch upstream && git checkout development && git merge --ff-only upstream/development && git push origin development
再次使用git checkout branch-name.
使用git rebase development.
使用 将重新定位的分支强制推送到原点git push --force origin branch-name。
GitHub PR 现在应该表明它与公司存储库中的“开发”分支没有冲突。