To do

Tutorials

"Fork" is a GitHub concept; it isn't a Git command.
If you have the permission to create and push to a branch on the original repo that's probably what you want to do. Forking is for when you don't have permission to create/push to a branch on the original repo.
Forking is basically a remote-clone operation. The original repo is the original 'remote' / 'origin' repo (and you presumably don't have control of it), and you're cloning it into a new remote/origin repo that you control.
If you intend to have some kind of permanent divergence in the path of the repo from the original, that is a situation to fork.
Previously, I'd thought that the main reason to use forks rather than just having people work on branches is when you want to be able to introduce a formal / mandatory code-review step before someone can update the canonical version of a project.
- But I've since worked on a project where I did not fork the repo, but instead pushed to a branch of the main repo, and created a PR from that branch, and I did not have permission to push directly to the master branch. So a fork is not needed to restrict access to particular branches.

From "Learn Git Branching": The second way of combining work between branches is rebasing. Rebasing essentially takes a set of commits, "copies" them, and plops them down somewhere else. While this sounds confusing, the advantage of rebasing is that it can be used to make a nice linear sequence of commits. The commit log / history of the repository will be a lot cleaner if only rebasing is allowed.
From what I can tell, it seems the best reason to rebase isn't "to keep things in order", which was the impression I'd gotten from the explanations I heard at Infer and from "Learn Git Branching"; it's that if you check out a branch and make 100 commits to it, then merge that into master, then delete the branch, you don't have those individual commits anymore; you just have the smooshed-together mega-commit. So you lose the granularity of having many small code changes with the rationale for each in its commit message.