Better Git Started: An Introduction to the Command Line, GitHub, and Git

To answer the question in Section 5.3, we are not quite done. See, even though your fork and the parent repository are connected, updates in one are not automatically reflected in the other. So if you just contributed to a repository and the pull request was accepted, you should be fine. But if someone else’s pull request also got approved, your fork will not have those changes. You have to tell GitHub to grab those changes and update your fork.

The act of grabbing changes from the parent repository is called fetching, aptly named since that is exactly what you are doing: fetching changes. Technically, this is distinct from a related merge. First, you fetch the changes, then you merge the changes into your fork.

You might remember from previous sections using git pull to fetch changes. In essence, using this command will fetch your changes. But it also merges the changes into your fork. In most cases, using git pull is fine and is a great shortcut. But as you get more experienced in the git world, you may want to fetch changes and then merge them later. We will explore pulling changes more in future sections.

Before continuing, you must wait until I accept your pull request from Section 5.3.

Another important concept is that of upstream. Remember from Subsection 4.3.4 when we talked about remotes? Back there, I mentioned that there were two types of remotes (origin and upstream) and that we would talk about upstream later. Well, now it’s later! This idea will become important again when we use Git to collaborate (see if you can figure out why).

Any repository you own or that you clone will have the remote identifier of “origin”, for you. Any repo you do not own and that you fork will have the remote identifier of “upstream”. Remember that a remote is like a connection between repositories; it’s the definition of the link between them. When you fork a repo, you are creating a remote connection between the parent repo (upstream) and your newly-created fork (origin). As we will explore in Chapter 6, when you clone a repo, you are creating a remote connection between your fork (origin) and your personal computer (local) with the future ability to be connected to the authoritative repo (upstream).

So in order to have changes from the parent repository reflected in your own fork, you have to fetch upstream. GitHub makes this easy! Remember that dialog box from Activity 5.3? Back then, we used the “Contribute” button to start a pull request. Here, we will use the option right next to it: “Fetch upstream”.

First, though, go back to the homepage of your fork. You might notice that a slightly different box has appeared. Now it might say something like “This branch is 1 commit behind ian-curtis:main” (you could have a different number). Earlier you were ahead of ian-curtis:main. What’s going on here?

You may be wondering why you are even any commits behind! If your addition to my repository was accepted, then our repos should match, right? Not quite. Actually, that act of accepting your pull request and merging into my main branch was a commit in itself which is where the mystery commit comes from.