The Final Steps

Section 6.4 The Final Steps

All that’s left to do is to create some pull requests. There are technically two ways you could make this work. You can either open a pull request from your new branch directly to the authoritative main branch or you can merge from your new branch to your fork’s main branch and then to the authoritative main branch.

Subsection 6.4.1 Opening a Pull Request

Use Activity 4.9 to go back to GitHub and start opening a pull request. When you arrive at the pull request creation screen (titled “Comparing changes”), you generally have two choices, as mentioned above. The following list describes the branches and repos you should have selected at the top of the screen, under the page heading.

Merge from your new branch to your fork, then to the authoritative.
Your base repository should be <your-username>/<your-fork>, base should be main, and compare should be <your-branch. Do note that once you select your fork for the base repository, the page will reload and the base and head repository options will disappear.

Then, click Create pull request and merge in to main. You may now open another pull request with options base repository of <authoritative-username>/<authoritative-repo>, base should be main, head repository should be <your-username><your-fork> and compare should be main.
Merge from your new branch directly to the authoritative.
Your base repository should be <authoritative-username>/<authoritative-repo>, base should be main, head repository should be <your-username><your-fork> and compare should be <your-branch>.

After either of those two, click on “Create pull request”, enter a title, and click “Create pull request” again. From there, you will have to wait for approval and moderator merge.

Subsection 6.4.2 Pulling/Fetching Upstream

Recall from Section 5.4 that you can update your fork with the latest upstream changes through the “Fetch upstream” button. That works great for updating the fork, but it doesn’t update your local clone. There are two main ways in which you can update both your fork and your clone with new changes to upstream.

Git Procedure 6.1. Updating Origin and Local, Method 1.

This method will first fetch upstream on GitHub, then pull in changes from origin.

(a)

Use Subsection 5.4.3 to fetch (and merge) upstream content into the main branch of your fork (origin).

(b)

Now, head back to your terminal and make sure you are navigated to your clone. Do a check to make sure you are on your main branch; if not, use git switch main.

If you are planning on making more changes to a branch, but want it updated to the latest upstream changes, you can stay on a branch. If you have any uncommitted changes, you might make a merge conflict.

(c)

Now use git pull to pull in the changes from your recently-updated fork. Git Procedure 4.10 may be helpful. Just remember that you are pulling in changes from the main branch on origin.

Answer.

git pull origin main (if you are pulling from origin, just git pull can work, too)

Git Procedure 6.2. Updating Origin and Local, Method 2.

This method will first set up a remote to upstream, pull in changes from upstream, then push changes to origin.

(a)

Head to your terminal and make sure you are navigated to your clone. Do a check to make sure you are on your main branch; if not, use git switch main.

(b)

This step will only have to be done once per repo that you have forked, then cloned. When you clone a fork, the connection between origin and upstream is not carried over. If I tried to pull from upstream without this connection, I would get an error:

> git pull upstream main
fatal: 'upstream' does not appear to be a git repository
fatal: Coult not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

This is troublesome! Clearly upstream exists; how else would we have forked it? To fix this, you need to manually set the remote connection. Again, this only has to be done once per forked/cloned repo.

(i)

Navigate to the authoritative repo’s homepage and copy its HTTPS clone link, just as if you were going to clone the repo.

(ii)

Head back to your terminal and use git remote add upstream <https-link>. There will be no output.

(iii)

Verify that it worked with git remote -v. This will print out the HTTPS links for origin and upstream. Make sure your username is on the origin remotes and the official repo/username is on the upstream remotes.

(c)

Ok, that was the hardest part. Once again, that only has to be done once. After that, every time you want to pull from upstream and update local and origin, you just need two commands: git pull upstream main and git push origin main.

git pull will fetch and merge upstream changes from its main branch and git push will take all of your files and push them to origin, updating them there.

Warning 6.4.2.1. Use `git pull` Frequently.

On a repository for which you are an active editor, do not get behind on your pulls. As mentioned in Warning 5.4.3.1, sometimes changes to upstream can improve or change how you work locally. Pulling often keeps your work at the very edge of the Git tree and reduces the likelihood you create a merge conflict. You also want to push back to origin often to prevent merge conflicts with yourself.

Prev Top Next