303

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?

reprogrammer
  • 13,350
  • 15
  • 52
  • 91

4 Answers4

303

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.

fork on 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.

See also:

Community
  • 1
  • 1
VonC
  • 1,042,979
  • 435
  • 3,649
  • 4,283
  • 3
    We're developing a project in house and there is no problem in adding people as collaborators. But, we'd like to understand if forking a project would make merging changes back to the main project harder. – reprogrammer Aug 31 '10 at 17:05
  • 7
    @reprogrammer: if you can add collaborators, then forking is not needed. they can rebase locally then merge on the target branch, and then push directly to *one* central repo, instead of having to manage *two* central repo (the original one and the fork). The rebase would be about the same, but with an extra indirection when a fork is involved. Again: not needed here. I have updated my answer. – VonC Aug 31 '10 at 17:09
  • 17
    Honestly, even if you don't have to, it is always a good idea to **have a sacred repo that is writable only for senior developers, team leads or other "trusted" people**. All other team members should work in their forks (~sandboxes) and contribute their changes in the form of pull request. Since DVCS makes it possible, we adapted it as a "best practice" and successfully use this even in the smallest projects... – intland Apr 26 '12 at 12:07
  • 1
    @intland so you are more in favor of an "Integration-manager workflow" as described in http://stackoverflow.com/users/6309/vonc?tab=responses then? For having introduced Git in a big corp, I tend to adopt a centralized workflow first (more familiar for everybody), before shifting to an "Integration-manager" one. – VonC Apr 26 '12 at 13:26
  • 1
    @VonC could you explain the "with the risk of evolutions on the original repo" a bit? What does that exactly mean? – faizal Aug 14 '14 at 02:50
  • 1
    @faizal it means you have two parallel histories, and if you ever want to contribute back to the original repo, it is best to pull first from the original (upstream) repo and rebase your work on top of it, instead of merging from time to time of original repo commits into your own. By rebasing, you maintain your commits on top of upstream commits, which means when it is time to merge your work back in the original repo, the merge is a trivial fast-forward one. – VonC Aug 14 '14 at 05:16
  • 18
    We should call forks "twigs" since they're broken off a branch and are used to start a whole new tree. Just my two cents--I like the arboreal idiom. – Eric Jan 13 '15 at 00:17
77

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

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

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
Aidan Feldman
  • 4,263
  • 32
  • 44
  • What is meant by "the outside contributor process" ? – Kars Barendrecht Nov 16 '16 at 10:07
  • 1
    @KarsBarendrecht Updated to use the term "external contributor". Someone who doesn't have `write` permissions on the repository. – Aidan Feldman Nov 17 '16 at 16:32
  • If you have a lot of abandoned branches, it's a good idea to establish a procedure for deliberately abandoning a branch. For example, a last commit on it with the comment "BRANCH ABANDONED". It helps if you have to find a branch that was just left hanging when a merge was intended or desired. – Forbin May 04 '21 at 17:26
46

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.

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).

Without this, it's quite unusual for public projects to let anyone push their own commits directly.

Bruno
  • 110,518
  • 24
  • 258
  • 357
  • @RecoJohnson, well... I haven't used the word "pull" in my answer (but "pull" is effectively "fetch" + "merge" in Git terms). Which usage of "push" do you think is wrong? – Bruno Apr 04 '14 at 17:31
  • 2
    @RecoJohnson You as a contributor push to your GitHub fork; the project's maintainers pull your contribution from your fork. – mljrg May 14 '14 at 11:03
  • 1
    I think the assumption that you are unlikely to be assigned a collaborator is more true in the open source world than in many organizations with development teams now using git where the development team is well defined. I think this is an important distinction to make and one that isn't made enough, probably why companies like gitlab are thriving because they understand the needs of the enterprise and need for controls. – code4cause Jan 20 '17 at 17:20
10

Forking creates an entirely new repository from existing repository (simply doing git clone on gitHub/bitbucket)

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.

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://buddy.works/blog/5-types-of-git-workflows

http://www.continuousagile.com/unblock/branching.html

Community
  • 1
  • 1
whoami - fakeFaceTrueSoul
  • 13,846
  • 4
  • 23
  • 39
  • The "best used" statements in this answer seem to ignore many of the issues that prevent branching from working for things like open-source projects, as well as the reality of how forks are used in the real world. It's extremely common to see forks used in conjunction with pull requests to allow people to collaborate on a project which don't all have permissions to modify a given repository directly. – StriplingWarrior Mar 26 '18 at 17:41