我想更多地了解一下分拨GitHub项目与创建GitHub项目分支的优缺点。

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

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

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

• 不能直接推回
• 添加了分叉队列功能以管理合并请求

通过以下方式使分叉与原始项目保持同步：

• 将原始项目添加为远程项目
• 定期从原始项目中获取
• 在感兴趣的分支上重新平衡您当前的开发，您将从该获取中得到更新。

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

我们的目标是允许合作，即使直接参与并不总是可能的。

您在Github端克隆的事实意味着您现在有两个"中央"存储库("中央"作为"从多个合作者可见")。如果您可以将它们直接添加为一个项目的合作者，则不需要使用fork管理另一个项目。

。

合并体验大致相同，但具有额外的间接性(先推动分叉，然后请求拉动，原始回购的演变风险使您的快速前进合并不再快速前进)。这意味着正确的工作流程是到git pull --rebase upstream(在上游新提交的基础上重新调整您的工作)，然后到git push --force origin，以这样的方式重写历史，您自己的提交总是在原始(上游)回购的提交之上。

另请参见：

• Git Fork是Git克隆吗？
• 将原始Github存储库中的新更新拉入分叉的Github存储库

以下是高级差异：

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

欺骗

• 使您更难看到所有处于活动状态的分支(或就此而言处于非活动状态)
• 在分支上进行协作更为棘手(fork所有者需要将此人添加为合作者)
• 您需要了解git中多个远程的概念。
  • 需要额外的心理簿记
  • 这将使那些对Git不太满意的人的工作流更加困难。

分支赞成的意见

• 将项目的所有工作保持在一个位置
• 所有合作者都可以推到同一个分支进行协作
• 只有一个Git遥控器可以处理

欺骗

• 被遗弃的树枝更容易堆积起来。
• 您的团队贡献流程与外部贡献流程不匹配
• 您需要先将团队成员添加为参与者，然后才能进行分支

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

一般模式如下：

• 将原始项目的存储库分叉为拥有自己的Github副本，然后允许您将更改推送到该副本。
• 将Github存储库克隆到本地计算机上
• 或者，将原始存储库添加为本地存储库上的其他远程存储库。然后您将能够直接获取在该存储库中发布的更改。
• 在本地进行修改和提交。
• 将您的更改推送到Github存储库(因为您通常不会直接拥有项目存储库的写入权限)。
• 联系项目的维护人员，让他们获取您的更改并审阅/合并，然后让他们返回到项目的存储库(如果您和他们愿意的话)。

没有这一点，公共项目就很难让任何人直接推动自己的承诺。

分叉从现有存储库创建一个全新的存储库(只需在GitHub/BitBucket上执行Git克隆)

Forks are best used: when the intent of the ‘split’ is to create a logically independent project, which may never reunite with its parent.

号

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

Branches are best used: when they are created as temporary places to work through a feature, with the intent to merge the branch with the origin.

号

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

这个问题是由forks解决的：每当开发人员想要在开放源码项目中更改某个内容时，他们不会直接克隆官方存储库。相反，他们通过分叉来创建一个副本。当工作完成后，它们会发出一个请求，以便存储库的所有者可以检查这些更改，并决定是否将它们合并到他的项目中。

在其核心分支类似于功能分支，但不创建分支，而是创建存储库分支，而不执行合并请求，而是创建拉请求。

以下链接以一种解释清楚的方式提供了差异：

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

https://buddy.works/blog/5-types-of-git-工作流

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