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?

Answer 1

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. If you don't intend to contribute to Alice's repo any time soon, you can safely delete your fork, to save space on GitHub's servers. If, on the other hand, you frequently contribute to Alice's repo, keep your fork and frequently sync it with Alice's repo.

Answer 2

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/

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