GitHub中的分叉vs.分支

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

分叉使我的项目版本与原始版本更加隔离，因为我不必在原始项目的合作者列表中。因为我们在内部开发一个项目，所以增加合作者是没有问题的。但是，我们想要了解的是，分支一个项目是否会使合并变更更难回到主项目。也就是说，我想知道分支是否能使两个项目更容易保持同步。换句话说，当我进行分支时，是否更容易在我的主项目版本和主项目版本之间合并和推动更改?

216153 次浏览
小开

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

一般模式如下:

  • Fork原始项目的存储库以拥有自己的GitHub副本，然后允许您将更改推送到该副本。
  • 克隆你的GitHub存储库到你的本地机器上
  • 可以选择将原始存储库作为额外的远程存储库添加到本地存储库上。然后，您将能够直接获取该存储库中发布的更改。
  • 在本地进行修改和自己的提交。
  • 将您的更改推到您的GitHub存储库(因为您通常不会直接对项目的存储库有写权限)。
  • 联系项目的维护者，请他们获取您的更改并检查/合并，并让他们推回项目的存储库(如果您和他们愿意的话)。

如果没有这一点，公共项目让任何人直接推动他们自己的提交是很不寻常的。

小开
最佳答案

您不能总是创建一个分支或拉出一个现有的分支并将其推回，因为您没有注册为该特定项目的合作者。

fork只不过是一个克隆在GitHub服务器端:

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

  • 将原始项目添加为远程
  • 定期从原始项目中获取
  • 将您的当前开发重新基于您从该获取中更新的兴趣分支之上。

rebase允许您确保您的更改是直接的(没有合并冲突需要处理)，当您希望原始项目的维护者将您的补丁包含在他的项目中时，使您的拉取请求更加容易。

目标是允许协作，尽管直接参与并不总是可能的。

你在GitHub端克隆的事实意味着你现在有两个“中央”存储库(“中央”为“从几个合作者可见”) 如果你可以直接将它们作为一个项目的合作者添加，你就不需要用fork来管理另一个。< / p >

fork on GitHub

合并的体验大致相同，但有额外的间接层次(先推分叉，然后要求拉，原始回购的演进风险使您的快进合并不再快进) 这意味着正确的工作流程是git pull --rebase upstream(在上游新提交的基础上重新构建你的工作)，然后是git push --force origin，以便以这样一种方式重写历史，使你自己的提交始终位于原始(上游)回购的提交之上

参见:

小开

以下是高层次的差异:

分叉

优点

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

缺点

  • 使得查看所有活动(或不活动)的分支变得更加困难
  • 在分支上的协作是比较棘手的(分支所有者需要将人添加为合作者)
    • 你需要理解Git中多个远程的概念
    • 需要额外的心理记帐
    • 这将使那些对Git不太熟悉的人的工作流程变得更加困难

分支

优点

  • 让所有围绕一个项目的工作都集中在一个地方
  • 所有合作者都可以推送到同一个分支进行协作
  • 只有一个Git远程需要处理

缺点

  • 被丢弃的分支更容易堆积起来
  • 您的团队贡献流程与外部贡献者流程不匹配
  • 在团队成员可以进行分支之前，您需要将他们添加为贡献者
小开

fork从现有的存储库创建一个全新的存储库(简单地在gitHub/bitbucket上克隆git)

最好使用分叉:当“分裂”的目的是创建一个逻辑上独立的项目时，该项目可能永远不会与其父项目合并。

分支策略在现有/正在工作的存储库之上创建一个新的分支

最好使用分支:当它们被创建为处理某个特性的临时场所时，目的是将分支与起源合并。

更具体:- 在开源项目中，由存储库的所有者决定谁可以推送到存储库。然而，开源的理念是每个人都可以为项目做出贡献

这个问题可以通过分叉来解决:任何时候开发人员想要改变开源项目中的某些东西，他们都不会直接克隆官方存储库。相反，他们用分叉来创建一个副本。当工作完成时，他们发出拉取请求，以便存储库的所有者可以检查更改并决定是否将它们合并到他的项目中。

在其核心上，分叉类似于特性分支，但不是创建分支，而是创建存储库的分叉，并且不是执行合并请求，而是创建拉请求。

下面的链接很好地解释了两者的区别:

https://blog.gitprime.com/the-definitive-guide-to-forks-and-branches-in-git/

< a href = " https://buddy。工作/博客/ 5-types-of-git-workflows noreferrer“rel = > https://buddy.works/blog/5-types-of-git-workflows < / >

http://www.continuousagile.com/unblock/branching.html


提交答案