GitHub 中的分叉与分支

本文介绍了GitHub 中的分叉与分支的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

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

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

解决方案

您不能总是创建分支或拉取现有分支并将其推回该分支，因为您未注册为该特定项目的合作者.

分叉无非是GitHub服务器端的克隆:

• 无法直接推回
• 添加了
• 将原始 Github 存储库中的新更新拉入分叉的 Github 存储库

I'd like to know more about the advantages and disadvantages of forking a github project vs. creating a branch of a github project.

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?

解决方案

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:

• without the possibility to directly push back
• with fork queue feature added to manage the merge request

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.

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.

The goal is really to allow collaboration even though direct participation 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 one project, you don't need to manage another one with a fork.

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.

See also:

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