分叉与GitHub中的分支

 

我想知道更多关于分叉github项目与创建github项目分支的优缺点。

分叉使得我的项目版本与原始版本更加分离，因为我不必在原始项目的协作者列表中。 由于我们正在内部开发一个项目，因此将人员添加为合作者没有任何问题。 但是，我们想要了解一个项目是否会使合并更改变回主项目更困难。 也就是说，我想知道分支是否能让两个项目更容易同步。 换句话说，当我分支时，在我的主项目版本和主项目之间合并和推送更改更容易吗？

您不能始终创建分支或将现有分支拉回来，因为您未注册为该特定项目的协作者。

分叉只不过是GitHub服务器端的一个克隆：

  • 没有可能直接推回去
  • 添加叉队列功能来管理合并请求

    • 您可以通过以下方式与原始项目保持同步：

  • 将原始项目添加为远程
  • 定期从原始项目中提取
  • 重新分配您目前的发展，使其在您从该获取中更新的感兴趣的分支之上。

    • 借助rebase，您可以确保您的更改非常简单（无需处理合并冲突），从而在您希望原始项目的维护人员将他们的修补程序包含在他的项目中时，使您的请求更加容易。

    尽管直接参与并非总是可行，但目标确实是允许协作。

    你在GitHub端克隆的事实意味着你现在有两个“中央”存储库（“几个合作者可见的”中央“存储库）。
    如果您可以直接将它们添加为一个项目的协作者，则不需要使用分叉管理另一个项目。

    叉在GitHub上

    合并经验大致相同，但有一个额外的间接水平（先推动分叉，然后要求拉动，原始回购的风险会让你的快速合并不再快进） 。
    这就意味着正确的工作流程就是git pull --rebase upstream （在上游提交的新提交之前git pull --rebase upstream工作），然后git push --force origin ，以便以您自己的提交始终如此的方式重写历史记录在原始（上游）回购的提交之上。

    也可以看看：

  • Git fork是git clone？
  • 将原始Github存储库中的新更新引入分叉的Github存储库

    • 以下是高级别的区别：

    分叉

    优点

  • 保持由用户分开的分支
  • 减少主要存储库中的混乱
  • 您的团队流程反映了外部贡献者流程

    • 缺点

  • 使得看到所有活跃的分支（或者不活跃的分支）变得更加困难，
  • 在分支上进行合作更为棘手（分支所有者需要将该人员添加为合作者）
  • 你需要了解Git中多个遥控器的概念
  • 需要额外的智力簿记
  • 对于那些对Git不太满意的人来说，这会使工作流程变得更加困难

    • 分枝

    优点

  • 在一个地方围绕一个项目完成所有工作
  • 所有协作者都可以推送到同一分支进行协作
  • 只有一个Git遥控器可以处理

    • 缺点

  • 被遗弃的分支可以更容易地堆积起来
  • 您的团队投稿流程与外部投稿人流程不匹配
  • 您需要添加团队成员作为贡献者才能分支

    • 它与Git的一般工作流程有关。 您不可能直接将其推送到主项目的存储库。 我不确定GitHub项目的存储库是否支持基于分支的访问控制，因为您不想授予任何人推送到主分支的权限。

    一般模式如下：

  • 分叉原始项目的存储库以拥有自己的GitHub副本，然后您可以将其推送到更改。
  • 将您的GitHub存储库克隆到本地机器上
  • 或者，将原始存储库添加为本地存储库上的其他远程存储库。 然后，您可以直接获取在该存储库中发布的更改。
  • 在本地进行修改和自己的提交。
  • 将更改推送到您的GitHub存储库（因为您通常不会直接在项目存储库上拥有写入权限）。
  • 联系项目的维护人员并要求他们获取您的更改和审查/合并，并让他们推回到项目的存储库（如果您和他们想要的话）。

    • 没有这个，公共项目让任何人直接推送他们自己的提交是非常不寻常的。

    链接地址: http://www.djcxy.com/p/90459.html

    上一篇: Forking vs. Branching in GitHub

    下一篇: How to tag an older commit in Git?