Git
Git itself has no notion of a base branch. A branch is (mostly—people use the word in different ways; see What exactly do we mean by "branch"?) just a name, with the name containing the hash ID of a commit. The commit that the name identifies is called the tip commit. That commit almost certainly has at least one parent commit and the parent(s) are also on the branch. The parent commits have their own parents; these commits are also on the branch. The chain that you get, by starting at the tip and working backwards, enumerates all the commits that are on the branch.
If you move the branch label—Git will let you move it arbitrarily—that changes which commits are on the branch, without changing anything inside any of the commits themselves. As long as the commits themselves are still in the repository, you can make as many branch names as you like to find them. Think of the commits as forming a series of connections:
C--D--E <-- branch1
/
...--A--B
\
F--G--H <-- branch2
You can add and remove labels wherever you like, without actually changing anything (except now there's a name for commit B):
C--D--E <-- branch1
/
...--A--B <-- branch3
\
F--G--H <-- branch2
What git rebase does is to copy some set of commits, e.g., to put the new copies in a more suitable place in this set of commits. For instance, suppose the three commits that are currently only reachable from branch2—starting at the right and working towards the left we find H, then G, then F—would be improved if they came after the last commit on branch1. To make that happen, you could run:
git checkout branch2
git rebase --onto branch1 branch3
which tells Git: Find the commits starting from where I am, branch2, but stopping at branch3 where the two branches converge. Now that you have a list of the correct commits, copy them one by one, starting with F and then doing G and last H. Before you start copying commits, check out commit E.
Let's call the copy of F, F', to denote how similar it is to F, even though it has a different hash ID. Once the copy is complete, the picture will look like this:
F' <-- HEAD
/
C--D--E <-- branch1
/
...--A--B <-- branch3
\
F--G--H <-- branch2
The rebase will go on to copy G and H, and then as its last act, will yank the name branch2 up so that it points to the copy of H:
F'-G'-H' <-- branch2 (HEAD)
/
C--D--E <-- branch1
/
...--A--B <-- branch3
\
F--G--H [abandoned]
Since git log will, by default, not show any of the abandoned commits, when you run git log you will see:
F'-G'-H' <-- branch2 (HEAD)
/
C--D--E <-- branch1
/
...--A--B <-- branch3
and it will seem like the commits moved. They didn't: they were supplanted by newer shinier commits, and the old dull ones are still in the repository. (If the new shiny ones turn out to be broken, you can switch your name branch2 back to the originals, as long as you catch them before they expire. They're still good for at least 30 days by default.)
GitHub
The GitHub notion of a base branch is, according to this GitHub page:
the parent repository's default branch.
The notion of a parent repository is likewise GitHub specific: Git repositories do not have parents.
The GitHub help page goes on to say:
If the default parent repository isn't correct, you can change both the parent repository and the branch with the drop-down lists ...
Hence, to change the parent repository, use the GitHub web interface. Once you have chosen the correct parent repository, the base branch will be that repository's default branch. To change the default branch of a GitHub-hosted repository, use the GitHub web interface (as described on this page).
For more GitHub information about collaboration, start at this page.
