分叉与GitHub中的分支
我想了解更多关于分叉github项目与创buildgithub项目分支的优缺点。
分叉使得我的项目版本与原始版本更加分离，因为我不必将其放在原始项目的协作者列表中。 由于我们正在内部开发一个项目，因此将人员添加为合作者没有任何问题。 但是，我们想了解一个项目是否会使合并变更更难回到主项目。 也就是说，我想知道分支是否能让两个项目更容易同步。 换句话说，当我分支的时候，我的版本的主项目和主项目之间的合并和推送更容易吗？
你不能总是build立一个分支或者拉一个现有的分支并推回去，因为你没有注册为该特定项目的协作者。
分叉只不过是GitHub服务器端的一个克隆：
- 没有可能直接推回去
- 添加叉队列function来pipe理合并请求
您通过以下方式与原始项目保持同步：
- 将原始项目添加为远程
- 定期从原始项目中获取
- 重新设置你目前的发展，在你从这个获取更新的感兴趣的分支之上。
rebase可以让你确保你的改变是直截了当的（不需要合并冲突），当你想让原始项目的维护者在他的项目中包含你的补丁时，使得你的请求更容易。
即使直接参与并不总是可能，但目标确实是允许协作。
您在GitHub端克隆的事实意味着您现在有两个 “中央”存储库（“中央”如同几个合作者可见的）。
如果您可以将它们直接添加为一个项目的协作者，则不需要使用分叉pipe理另一个项目。
合并的经验大致相同，但有一个额外的间接水平（先推上叉，然后要求拉回，原始回购的风险会让你的快进合并不再快进） 。
这意味着正确的工作stream程是git pull --rebase upstream （在上游提交的新提交之前git pull --rebase upstream工作），然后git push --force origin ，以便以自己的提交方式重写历史logging在原始（上游）回购的承诺之上。
也可以看看：
- Git的叉子是git克隆？
- 将原始Github存储库中的新更新引入分叉的Github存储库
它与Git的一般工作stream程有关。 您不可能直接将其推送到主项目的存储库。 我不确定GitHub项目的存储库是否支持基于分支的访问控制，因为您不想授予任何人推送到主分支的权限。
一般模式如下：
- 将原始项目的存储库分叉以拥有自己的GitHub副本，然后您可以将其推送到更改。
- 将你的GitHub仓库克隆到你的本地机器上
- （可选）将原始存储库添加为本地存储库上的其他远程存储库。 然后，您将能够直接获取在该存储库中发布的更改。
- 在本地进行修改和自己的提交。
- 将更改推送到您的GitHub存储库（因为您通常不会直接在项目存储库上拥有写入权限）。
- 联系项目的维护者，要求他们获取你的修改和审查/合并，让他们推回到项目的存储库（如果你和他们想要的）。
没有这个，公共项目让任何人直接推他们自己的提交是非常不寻常的。
以下是高级别的区别：
分叉
优点
- 保持由用户分隔的分支
- 减less主存储库中的混乱
- 你的团队过程反映了外部贡献者的过程
缺点
- 使得看到所有活跃的分支（或者不活跃的分支）变得更加困难，
- 在一个分支上进行协作是比较棘手的（分支所有者需要把这个人作为协作者）
- 您需要了解Git中多个远程的概念
- 需要额外的智力簿记
- 这对于那些不太熟悉Git的人来说会使工作stream程变得更加困难
分枝
优点
- 保持围绕一个项目在一个地方完成所有的工作
- 所有协作者都可以推送到相同的分支进行协作
- 只有一个Git远程处理
缺点
- 被遗弃的分支可以更容易地堆积起来
- 您的团队投稿stream程与外部投稿人stream程不匹配
- 您需要添加团队成员作为贡献者才能分支
