分叉与GitHub中的分支

Question

我想更多地了解分支github项目与创建github项目分支的优缺点。

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

Answer 1

您不能总是创建分支或拉动现有分支并推回到它，因为您没有注册为该特定项目的协作者。

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

• 无法直接推回
• 添加了fork queue功能以管理合并请求

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

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

rebase允许您确保您的更改很简单（没有要处理的合并冲突），当您希望原始项目的维护者将修补程序包含在他的项目中时，使您的提取请求更加容易。

即使直接参与并非总是可行，但目标仍然是允许协作。

---

您在GitHub端克隆的事实意味着您现在已经两个“中央”存储库（“中央”作为“从多个协作者可见”）。 如果您可以直接将它们添加为一个项目的协作者，则无需使用fork管理另一个。

合并经验大致相同，但是有一个额外的间接水平（先推上叉子，然后要求拉动，原始仓库的进化风险使你的快进合并不快 - 再转发。） 这意味着正确的工作流程是git pull --rebase upstream（在上游的新提交之后重新设置您的工作），然后是git push --force origin，以便以这样的方式重写历史记录，您自己的提交始终位于顶部来自原始（上游）回购的提交。

另见：

• Git fork is git clone?
• Pull new updates from original Github repository into forked Github repository

Answer 2

以下是高层差异：

分岔

赞成

• 保持分支由用户分隔
• 减少主存储库中的混乱
• 您的团队流程反映了外部撰稿人流程

缺点

• 使查看所有活动的分支（或非活动的分支）变得更加困难
• 在分支上进行协作比较棘手（分叉所有者需要将此人添加为协作者）
• 您需要了解Git中多个遥控器的概念
  • 需要额外的心理记账
  • 对于那些对Git
  不太满意的人来说，这将使工作流程变得更加困难

分支

赞成

• 将项目的所有工作放在一个地方
• 所有合作者都可以推送到同一个分支机构进行协作
• 只有一个Git遥控器可以处理

缺点

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

Answer 3

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

一般模式如下：

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

如果没有这个，公共项目很难让任何人直接推送自己的提交。

Answer 4

Forking从现有存储库创建一个全新的存储库（只需在gitHub / bitbucket上执行git clone）

  

最好使用Fork：当'split'的意图是创建一个逻辑上独立的项目时，它可能永远不会与其父项重新组合。

分支策略在现有/工作存储库

上创建新分支

  

最好使用分支：当它们被创建为临时位置以处理特征时，意图将分支与原点合并。

更具体： - 在开源项目中，它是存储库的所有者，它决定谁可以推送到存储库。但是，开源的想法是每个人都可以为项目做出贡献。

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

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

以下链接以一种解释清楚的方式提供了不同之处：

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

https://buddy.works/blog/5-types-of-git-workflows

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