16

我正在寻找最佳实践，在 GitHub 上分叉与分支。我已经在 GitHub 中阅读了这个 Forking vs. Branching，但它并不相关。

我们的 5 人团队在同一个存储库上工作，我们希望避免合并代码中的问题、冲突或回归。目标是让 5 个人在项目的不同部分工作，通常在同一个文件上。

我想知道是否值得：

  • 分叉项目，工作并创建拉取请求，因此每个人都可以轻松地查看代码，或者
  • 创建一个新分支 - 工作完成后在 master 上工作并合并。
4

6 回答 6

25

对我来说，与多个开发人员一起处理项目时的最佳实践是使用gitflow分支模型。

首先，master 分支现在将仅用于跟踪您的应用程序的版本、主要版本、次要版本或补丁版本，遵循Semantic Versionning。

开发分支将成为您项目的核心，因为它将在不同功能和您的版本之间架起一座桥梁。

这个系统有助于减少合并的次数，就像一个简单的分支系统会做的那样，但是增加了语义逻辑，以及它附带的友好和简单的命令。

有关 gitflow 的更多信息，您可以点击此链接。

于 2014-07-30T20:41:34.850 回答
12

维护分叉会带来额外的开销，因为每个分叉都需要从上游拉取更改。当每个开发人员都可以访问共享存储库时，我认为这样做没有任何好处。

拉取请求可能是一种非常有用的代码审查机制，但它们并不要求您使用分叉。您可以在同一存储库中创建分支并使用拉取请求来管理将它们合并到您的主分支中。

于 2014-07-25T18:11:07.237 回答
5

在我的办公室，我们也遇到了类似的情况：一个大型项目，其中五个或更多开发人员拥有提交访问权限，并且通常至少有三个人在任何时候都在处理它。我们使用带有分支和拉取请求的单个存储库来管理所有内容，并且我们没有遇到任何问题（无论如何，这是由我们的源代码控制设置引起的）。

拉取请求是向其他开发人员征求代码审查的绝佳方式，当这些开发人员可能在第二天使用您的代码时，这一点尤其重要。另一方面，分叉并没有真正提供任何好处。它解决了允许更广泛地访问受控代码库的问题，并且当每个人都可以提交对 repo 的访问权限时，这个问题就不存在了。

于 2014-07-29T13:23:30.603 回答
3

Atlassian 在其 git 教程页面上对分叉和其他 git 工作流程之间的差异进行了出色的描述。（请参阅分叉工作流程 | Atlassian Git 教程）

相关报价：

分叉工作流的主要优点是可以集成贡献，而无需每个人都推送到单个中央存储库。开发者推送到自己的服务器端仓库，只有项目维护者可以推送到官方仓库。这允许维护人员接受来自任何开发人员的提交，而无需授予他们对官方代码库的写入权限。

...

理解分叉工作流中“官方”存储库的概念只是一种约定，这一点很重要。从技术的角度来看，Git 没有看到每个开发者的公共存储库和官方存储库之间有任何区别。事实上，使官方仓库如此正式的唯一原因是它是项目维护者的公共仓库。

...

所有这些个人公共存储库实际上只是与其他开发人员共享分支的便捷方式。每个人仍然应该使用分支来隔离单个特性，就像在特性分支工作流和 Gitflow 工作流中一样。唯一的区别是这些分支是如何共享的。在 Forking Workflow 中，它们被拉入另一个开发人员的本地存储库，而在 Feature Branch 和 Gitflow Workflows 中，它们被推送到官方存储库。

于 2014-07-29T14:21:46.590 回答
2

我会以“集中式”的方式工作，也就是说，拥有一个每个人都 fork 的主仓库，每个开发人员都会提交自己的仓库，这使得代码审查过程更容易。代码审查完成后，您可以将更改合并到主存储库。

这只是主要思想...

您还需要设置有关如何分支的策略。我会推荐Nvie 模型

于 2014-07-29T14:11:20.130 回答
1

我觉得，瓶颈不是分叉或分支。在这两种方法中，您都需要手动干预合并/审查更改。

所以瓶颈在于应用程序开发方法。当一个团队在同一个文件上进行协作时，我看到了一个问题。通过适当的架构设计，可以将其拆分为带有单独文件的单独模块吗？在运行时或构建时，可以聚合单独的模块（或文件）以形成整个功能（或单个文件）。

如果我们能在那个层次上解决它，一旦团队规模增加或功能复杂性增加，事情就会顺利扩展。

于 2014-08-05T12:18:48.217 回答