GitHub: Why should I fork?

Question

I understand that forking is cloning the repository on the server side. But I don't understand why I would do that.

Why not clone the original repository to my machine, add my code, than push the new branch to GitHub and make a pull request?

Solution 1

From the Github documentation

A fork is a copy of a repository. Forking a repository allows you to freely experiment with changes without affecting the original project.

Most commonly, forks are used to either propose changes to someone else's project or to use someone else's project as a starting point for your own idea.

https://help.github.com/articles/fork-a-repo/

Solution 2

I understand that forking is cloning the repository on the server side [...]

That's about right. On GitHub, a fork is a copy of some other GitHub repo, with a reference to the repo it was copied from.

Remark: the concept of a fork originated with GitHub; it is not a Git concept.

[...] but I don't understand why I would do that. Why not clone the original repository to my machine, add my code, then push the new branch to GitHub and make a pull request?

Unless you have write access to the repository in question, you cannot simply push anything to it; your push will be denied by the server with an error message of the form

remote: Permission to bos/text.git denied to Jubobs.
fatal: unable to access 'https://github.com/bos/text/': The requested URL returned error: 403

That's where a fork comes into play. By forking someone else's repo, you get a copy to which you have write access, i.e. to which you can push your contributions. The entire workflow goes something like this:

1. Identify an area in Alice's repo that can be improved.
2. Fork that repo.
3. Make a clone of your fork on your local machine.
4. In that clone, make changes, run tests, create commits (possibly on a new branch), etc.
5. Optionally, once you're happy with your amendments to Alice's code, make your work more presentable: tidy/squash your commits, write good commit messages that respect the style of Alice's repo. You may also want to rebase your branch to that of Alice's branch, if Alice has pushed changes to her repo since you forked her repo.
6. Push to your fork.
7. Issue a pull request to Alice (essentially notifying Alice to take a look at the changes you made in your fork of her repo) and wait for her to review it.
8. Push more commits to (and possibly rebase) your branch until Alice is satisfied with your work.
9. If all goes well, Alice merges your pull request; your work gets integrated into her GitHub repo. Champagne! Your work was not in vain.
10. To save space on GitHub's servers, and if you don't intend to contribute to Alice's repo any time soon, you can safely delete your fork.

Solution 3

Forking makes it clear that your repository derives from the other, by marking your repository as "forked from..." and more importantly, it will list your repository in the fork list of the original project.

One of the advantages of that is that in the event that the original project becomes discontinued while you are still working on it, people can still find your repository looking on the fork list from the main repository.

From github's point of view, they can save some disk space by knowing that the git objects between your and the original repository are the same and can be shared

Moreover, I think you cannot make a pull request from a repository which is not a fork of the original one. At least I wasn't able to do it, I had to fork, push to the fork, ask for a pull request.

Comments

[Kos]

Because you don't have push permissions to someone's GitHub repo

[Aviv Cohn]

@Kos So how can I later 'merge' my forked repository into the original?

[Mauricio Trajano]

Also some people aren't just adding new features but want to completely branch out into a new project

[TheGeorgeous]

@AvivCohn by opening a pull request. Whether it should be merged with the original is entirely upto the author of the original

[Aviv Cohn]

So why not clone the repository, implement my new feature as a new branch, push the branch (can you say that?) and issue a pull request on it?

[TheGeorgeous]

Normally you cannot push the new branch unless you have been added as a collaborator on that repo. Forking and creating pull requests is polite way of proposing changes. It is upto the author of the original to add the changes or not

[TheGeorgeous]

Whoa, whoa, no need for a flame war, forget I said anything

[Aviv Cohn]

Do I have to fork in order to make a pull request? If so, I understand why I'd want to fork. But I think you can issue a pull request simply by cloning, editing, pushing to the server and issuing the request. Am I wrong?

[Aviv Cohn]

Do I have to fork in order to be able to make pull requests on a repository?

[TheGeorgeous]

yes and no. Depends on whether you have write access to the repo

[pqnet]

@AvivCohn you can issue pull request either from a branch in the same repository (if you have write permits on there) or another repository which is a branch of the original one

[Ufos]

An awesome How-To @Jubobs. Github should have it the same way!

[user239558]

Forked repositories often cannot be used in PRs because for example travis doesn't support decrypting secrets in this case.

[CrusherJoe]

I like how you explained this by adding the typical, entire workflow. Thanks.

[Krupa]

Yea I understand that forking allows us to work independently. But if am not wrong, we can achieve the same by creating new branch on the same repo. Then what's the difference between forking a repo and creating feature branches ?

[TheGeorgeous]

@Krupa that is assuming you have access to create branches on some repo. Most open source communities won't give access to repos to other developers willy-nilly.

[David V. Corbin]

@AvivCohn - lets presume YOU have a repository, and allow me to push to a branch (and only to that branch)..... Now, I turn out to be a "Bad actor" and push really horrible stuff, the kind that can get YOU in legal hot water.... In theory you could delete the branch, but there may be dangling objects for a long time... Also any backups taken (perhaps by GitHub or other provider) of YOUR repository will contain copies of that BAD material...... Practically speaking you cannot erase it to the point of preventing authorities from finding it...

[David V. Corbin]

On the other hand, if I fork the repository, then anything I do is on ME. You have NO involvement. At some point you look at my repository - and if I have been a bad actor, run away quickly - with your repository NEVER having been touched and you having no risk (technical, legal, moral)