git GitHub 存储库上的最佳实践，用于分叉或创建新分支

Best practices on GitHub repos, to Fork or create a New Branch

提问by Erowlin

I'm looking for the best practice, forking vs branching on GitHub. I've read this Forking vs. Branching in GitHub, but it's not relevant.

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

Our team of 5 people are working on the same repository, and we would like to avoid merging problems, conflicts or regression in the code. The goal is for the 5 persons to work on different parts of the project, often on the same file.

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

I would like to know if it's worth it to :

我想知道是否值得：

• fork the project, work and create pull requests, so each persons can review the code easily, or
• create a new branch - work and merge on master when work is done.

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

回答by Balthazar

To me, the best practice when dealing with a project with more than one developer, is to use gitflowbranching model.

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

First, the master branch will now only be used to keep track of the releases of your app, major, minor or patch versions, following the Semantic Versionning.

首先，主分支现在仅用于跟踪您的应用程序的发布，主要版本，次要版本或补丁版本，遵循语义版本控制。

The develop branch will be the core of your project, since it will make the bridge between the different features and your releases.

develop 分支将是您项目的核心，因为它将在不同功能和您的发布之间架起桥梁。

This system helps to reduce the number of merge, just as a simple branching system will do, but add the semantic logic, and the friendly and simple commands that comes with it.

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

For more info about gitflow you can follow this link.

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

回答by Jonah

Maintaining forks introduces additional overhead as each fork needs to pull changes from upstream. I see no benefit to doing so when every developer can have access to a shared repository.

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

Pull requests can be a very useful mechanism for code reviews but they do not demand that you use forks. You can create branches in the same repository and use pull requests to manage merging them into your master branch.

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

回答by Wally Altman

At my office we have a similar situation: a large project where five or more developers have commit access, and typically at least three are working on it at any time. We manage everything using a single repository with branches and pull requests, and we haven't had any issues (that were caused by our source control setup, anyway).

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

Pull requests are an excellent way to solicit code reviews from other developers, which is especially important when those same developers may be working with your code the next day. Forking, on the other hand, doesn't really provide any benefit; it is a solution to the problem of allowing broader access to a controlled codebase, and that problem just doesn't exist when everyone has commit access to the repo.

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

回答by Ajedi32

Atlassian has an excellent write up on the differences between forking and other git workflows on their git tutorials page. (See Forking Workflow | Atlassian Git Tutorial)

Atlassian 在他们的 git 教程页面上有一篇关于分叉和其他 git 工作流程之间差异的优秀文章。（参见分叉工作流程 | Atlassian Git 教程）

Relevant quotes:

相关引述：

The main advantage of the Forking Workflow is that contributions can be integrated without the need for everybody to push to a single central repository. Developers push to their own server-side repositories, and only the project maintainer can push to the official repository. This allows the maintainer to accept commits from any developer without giving them write access to the official codebase.

...

It's important to understand that the notion of an “official” repository in the Forking Workflow is merely a convention. From a technical standpoint, Git doesn't see any difference between each developer's public repository and the official one. In fact, the only thing that makes the official repository so official is that it's the public repository of the project maintainer.

...

All of these personal public repositories are really just a convenient way to share branches with other developers. Everybody should still be using branches to isolate individual features, just like in the Feature Branch Workflow and the Gitflow Workflow. The only difference is how those branches get shared. In the Forking Workflow, they are pulled into another developer's local repository, while in the Feature Branch and Gitflow Workflows they are pushed to the official repository.

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

...

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

...

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

回答by Guillermo Mansilla

I would work in a "centralized" way, that is, having a main repo that everyone fork, every developer would commit to their own repo, that makes the code review process easier. Once the code review has been done you can merge the changes to the main repo.

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

This is just the main idea...

这只是主要思想......

You would also need to set up the strategies on how to branch. I would recommend Nvie model

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

回答by Sairam Krish

I feel, the bottleneck is not forking or branching. In both approaches, you need manual intervention of merging / reviewing the changes.,

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

So the bottleneck is with the application development approach. I see a problem, when a team is collaborating on the same file. With a proper architecture design, can it be split as separate modules with individual files ? On runtime or build time, the separate modules (or files) could be aggregated to form the whole feature (or a single file).

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

If we could solve it in that level, once the team size increases or the feature complexity increases, things will be smooth to scale.

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