git GitHub 中的分叉与分支
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/3611256/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Forking vs. Branching in GitHub
提问by reprogrammer
I'd like to know more about the advantages and disadvantages of forking a github project vs. creating a branch of a github project.
我想更多地了解分叉 github 项目与创建 github 项目的分支的优缺点。
Forking makes my version of the project more isolated from the original one because I don't have to be on the collaborators list of the original project. Since we're developing a project in house, there is no problem in adding people as collaborators. But, we'd like to understand if forking a project would make merge changes back to the main project harder. That is, I wonder if branching makes keeping the two projects in sync easier. In other words, is it easier to merge and push changes between my version of the main project and the main project when I branch?
Forking 使我的项目版本与原始项目更加隔离，因为我不必在原始项目的合作者列表中。由于我们正在内部开发项目，因此添加人员作为合作者是没有问题的。但是，我们想了解分叉项目是否会使合并更改回主项目变得更加困难。也就是说，我想知道分支是否能让两个项目更容易保持同步。换句话说，在我分支时，在我的主项目版本和主项目之间合并和推送更改是否更容易？
回答by VonC
You cannot always make a branch or pull an existing branch and push back to it, because you are not registered as a collaborator for that specific project.
你不能总是创建一个分支或拉一个现有的分支并推回它，因为你没有注册为该特定项目的合作者。
Forking is nothing more than a clone on the GitHub server side:
Forking 只不过是 GitHub 服务器端的一个克隆：
- without the possibility to directly push back
- with fork queuefeature added to manage the merge request
- 无法直接推回
- 添加了fork 队列功能来管理合并请求
You keep a fork in sync with the original project by:
您可以通过以下方式与原始项目保持同步：
- adding the original project as a remote
- fetching regularly from that original project
- rebase your current development on top of the branch of interest you got updated from that fetch.
- 将原始项目添加为远程
- 定期从那个原始项目中获取
- 将您当前的开发重新建立在您从该 fetch 更新的感兴趣的分支之上。
The rebase allows you to make sure your changes are straightforward (no merge conflict to handle), making your pulling request that more easy when you want the maintainer of the original project to include your patches in his project.
rebase 允许您确保您的更改是直接的（没有合并冲突要处理），当您希望原始项目的维护者将您的补丁包含在他的项目中时，使您的拉取请求更加容易。
The goal is really to allow collaboration even though directparticipation is not always possible.
目标实际上是允许协作，即使直接参与并不总是可能的。
The fact that you clone on the GitHub side means you have now two"central" repository ("central" as "visible from several collaborators).
If you can add them directly as collaborator for oneproject, you don't need to manage another one with a fork.
您在 GitHub 端克隆这一事实意味着您现在拥有两个“中央”存储库（“中央”为“对多个合作者可见”）。
如果您可以将它们直接添加为一个项目的合作者，则无需管理另一个一个用叉子。
The merge experience would be about the same, but with an extra level of indirection (push first on the fork, then ask for a pull, with the risk of evolutions on the original repo making your fast-forward merges not fast-forward anymore).
That means the correct workflow is to git pull --rebase upstream(rebase your work on top of new commits from upstream), and then git push --force origin, in order to rewrite the history in such a way your own commits are always on top of the commits from the original (upstream) repo.
合并体验大致相同，但有一个额外的间接级别（先推动分叉，然后要求拉动，原始存储库的演变风险使您的快进合并不再快进） .
这意味着正确的工作流程是git pull --rebase upstream（在上游的新提交之上重新构建您的工作），然后git push --force origin，为了以这种方式重写历史记录，您自己的提交始终位于原始（上游）存储库的提交之上.
See also:
也可以看看：
回答by Aidan Feldman
Here are the high-level differences:
以下是高层差异：
Forking
分叉
Pros
优点
- Keeps branches separated by user
- Reduces clutter in the primary repository
- Your team process reflects the external contributor process
- 保持分支由用户分隔
- 减少主存储库中的混乱
- 您的团队流程反映了外部贡献者流程
Cons
缺点
- Makes it more difficult to see all of the branches that are active (or inactive, for that matter)
- Collaborating on a branch is trickier (the fork owner needs to add the person as a collaborator)
- You need to understand the concept of multiple remotes in Git
- Requires additional mental bookkeeping
- This will make the workflow more difficult for people who aren't super comfortable with Git
- 使查看所有活动（或不活动，就此而言）的分支变得更加困难
- 在分支上进行协作比较棘手（分叉所有者需要将该人添加为协作者）
- 你需要了解Git中多个遥控器的概念
- 需要额外的心理簿记
- 对于对 Git 不太熟悉的人来说，这将使工作流程变得更加困难
Branching
分枝
Pros
优点
- Keeps all of the work being done around a project in one place
- All collaborators can push to the same branch to collaborate on it
- There's only one Git remote to deal with
- 将围绕项目完成的所有工作集中在一个地方
- 所有协作者都可以推送到同一个分支进行协作
- 只需要处理一个 Git 遥控器
Cons
缺点
- Branches that get abandoned can pile up more easily
- Your team contribution process doesn't match the external contributor process
- You need to add team members as contributors before they can branch
- 被遗弃的树枝更容易堆积
- 您的团队贡献流程与外部贡献流程不匹配
- 您需要将团队成员添加为贡献者，然后才能进行分支
回答by Bruno
It has to do with the general workflow of Git. You're unlikely to be able to push directly to the main project's repository. I'm not sure if GitHub project's repository support branch-based access control, as you wouldn't want to grant anyone the permission to push to the master branch for example.
它与 Git 的一般工作流程有关。您不太可能直接推送到主项目的存储库。我不确定 GitHub 项目的存储库是否支持基于分支的访问控制，因为例如您不想授予任何人推送到 master 分支的权限。
The general pattern is as follows:
一般模式如下：
- Fork the original project's repository to have your own GitHub copy, to which you'll then be allowed to push changes.
- Clone your GitHub repository onto your local machine
- Optionally, add the original repository as an additional remote repository on your local repository. You'll then be able to fetch changes published in that repository directly.
- Make your modifications and your own commits locally.
- Push your changes to your GitHub repository (as you generally won't have the write permissions on the project's repository directly).
- Contact the project's maintainers and ask them to fetch your changes and review/merge, and let them push back to the project's repository (if you and them want to).
- Fork 原始项目的存储库以获得您自己的 GitHub 副本，然后您将被允许将更改推送到该副本。
- 将您的 GitHub 存储库克隆到您的本地机器上
- 或者，将原始存储库添加为本地存储库上的附加远程存储库。然后，您将能够直接获取在该存储库中发布的更改。
- 在本地进行修改和自己的提交。
- 将您的更改推送到您的 GitHub 存储库（因为您通常不会直接拥有对项目存储库的写入权限）。
- 联系项目的维护者并要求他们获取您的更改并进行/合并，然后让他们推送回项目的存储库（如果您和他们想要的话）。
Without this, it's quite unusual for public projects to let anyone push their own commits directly.
没有这个，公共项目让任何人直接推送他们自己的提交是很不寻常的。
回答by whoami
Forking creates an entirely new repository from existing repository (simply doing git clone on gitHub/bitbucket)
Forking 从现有存储库创建一个全新的存储库（只需在 gitHub/bitbucket 上执行 git clone）
Forks are best used: when the intent of the ‘split' is to create a logically independent project, which may never reunite with its parent.
最好使用分叉：当“拆分”的目的是创建一个逻辑上独立的项目时，该项目可能永远不会与其父项团聚。
Branch strategy creates a new branch over the existing/working repository
分支策略在现有/工作存储库上创建一个新分支
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.
最好使用分支：当它们被创建为临时位置以处理功能时，意图将分支与原点合并。
More Specific :-In open source projects it is the owner of the repository who decides who can push to the repository. However, the idea of open source is that everybody can contribute to the project.
更具体：-在开源项目中，由存储库的所有者决定谁可以推送到存储库。然而，开源的理念是每个人都可以为项目做出贡献。
This problem is solved by forks: any time a developer wants to change something in an open source project, they don't clone the official repository directly. Instead, they fork it to create a copy. When the work is finished, they make a pull request so that the owner of the repository can review the changes and decide whether to merge them to his project.
这个问题是通过 fork 解决的：任何时候开发人员想要改变开源项目中的某些东西，他们都不会直接克隆官方存储库。相反，他们分叉它来创建一个副本。工作完成后，他们会发出拉取请求，以便存储库的所有者可以查看更改并决定是否将它们合并到他的项目中。
At its core forking is similar to feature branching, but instead of creating branches a fork of the repository is made, and instead of doing a merge request you create a pull request.
其核心分支类似于功能分支，但不是创建分支，而是创建存储库的分支，而不是执行合并请求，而是创建拉取请求。
The below links provide the difference in a well-explained manner :
以下链接以一种很好解释的方式提供了差异：
https://blog.gitprime.com/the-definitive-guide-to-forks-and-branches-in-git/
https://blog.gitprime.com/the-definitive-guide-to-forks-and-branches-in-git/
https://buddy.works/blog/5-types-of-git-workflows
https://buddy.works/blog/5-types-of-git-workflows
