我想知道更多关于分叉一个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?
fork从现有的存储库创建一个全新的存储库(简单地在gitHub/bitbucket上克隆git)
最好使用分叉:当“分裂”的目的是创建一个逻辑上独立的项目时，该项目可能永远不会与其父项目合并。
分支策略在现有/正在工作的存储库之上创建一个新的分支
最好使用分支:当它们被创建为处理某个特性的临时场所时，目的是将分支与起源合并。
更具体的:-
在开源项目中，由存储库的所有者决定谁可以推送到存储库。然而，开源的理念是每个人都可以为项目做出贡献。
这个问题可以通过分叉来解决:任何时候开发人员想要改变开源项目中的某些东西，他们都不会直接克隆官方存储库。相反，他们用分叉来创建一个副本。当工作完成时，他们发出拉取请求，以便存储库的所有者可以检查更改并决定是否将它们合并到他的项目中。
在其核心上，分叉类似于特性分支，但不是创建分支，而是创建存储库的分叉，并且不是执行合并请求，而是创建拉请求。
下面的链接很好地解释了两者的区别:
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
它与Git的一般工作流程有关。您不太可能直接推送到主项目的存储库。我不确定GitHub项目的存储库是否支持基于分支的访问控制，因为你不会想授予任何人推送到主分支的权限。
一般模式如下:
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).
如果没有这一点，公共项目让任何人直接推动他们自己的提交是很不寻常的。
您不能总是创建一个分支或拉出一个现有的分支并将其推回，因为您没有注册为该特定项目的合作者。
分叉只不过是GitHub服务器端的克隆:
没有直接反击的可能
添加了fork队列功能来管理合并请求
您可以通过以下方式保持fork与原始项目同步:
将原始项目添加为远程
定期从原始项目中获取
将您的当前开发重新基于您从该获取中更新的兴趣分支之上。
rebase允许您确保您的更改是直接的(没有合并冲突需要处理)，当您希望原始项目的维护者将您的补丁包含在他的项目中时，使您的拉取请求更加容易。
我们的目标是允许合作，尽管直接参与并不总是可能的。
事实上，你在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 fork是Git克隆吗?
从原始的Github存储库拉新的更新到分叉的Github存储库
