Section 4.4 The Final Steps
We’re almost done! At this point, you should have completed the three-step process as outlined in Section 4.3. What could be known as the fourth step is to head back to GitHub and submit a pull request. Again, it does seem silly to ask yourself for permission to include your own changes, but it makes more sense when contributing to someone elses repository. In order for your changes to be included into any main branch, you need to ask the repo owner/moderator(s) for permission to pull in your changes.
It is important to make a distinction between a push and a pull. When you push changes, you are sending your changes from place to another, such as how we pushed changes from local to origin. Submitting a pull request is equivalent to pushing your changes to the main branch, but since this often requires permission, we typically use the term pull request. In this case, you are asking someone else to pull in your changes to their main branch.
A lot of this section will look familiar to the ideas expressed in Section 3.3. However, it is worth going over again just to make sure everything stuck.
Note that it is possible to create a pull request using the terminal. However, I prefer to do so on GitHub. The interface is nicer and human-friendly which allows me to be sure that I am doing the right thing and to verify once more that I edited the correct files.
(a)
Navigate back to your GitHub repository.
(b)
Once there, you might see that a nice bar has popped up at the top of the page with a button that says you can “Compare and pull request”. If you see this, great! Click on that button and proceed to Task 4.9.d. If not, read on.
(c)
If your repository looks like nothing changed, never fear. There are a couple of ways to get to where we need to get. Either of the following will work so pick what you like best.
- When in the Code tab, click on the dropdown menu that currently has “main” selected. Click on your new branch title (“country”). A new box should pop up saying that this branch is 1 commit ahead of main. On the right of that box, click “contribute” and then “Open pull request”.
- When in the Code tab, click on the branch icon that says “2 branches” (this is different from before…previously it only said one branch). This gives a list of all the branches. Find the “country” branch and click on “New pull request”
- Navigate to the Pull requests tab. Click on the button near the top right that says “New pull request”. Select the branch you want to pull into main from either the “Compare” drop-down menu at the top or the example comparisons table. Click “Create pull request”.
(d)
Regardless of the method you chose in Task 4.9.c or if you had the automatic pop-up banner, you should be on the same screen. This might look familiar. Notice that your commit message you chose back in Section 4.3 appears here. You have the choice to add a further description.
Note the drop-down menus at the top of the page. With these, you can easily decide which branches you want to merge into and which branches you are merging from. You should only see two choices since we only have two branches but this will not always be the case (especially if you are merging from an origin to an upstream, see Section 6.4).
You can also scroll down and see all of the files that were changed and all of the changes. This is good to check that everything is as you expected. This also works to check that someone who is trying to contribute to your repo is not destroying your project.
(e)
Once everything looks good, click on “Create pull request”.
All that’s left to do now is to merge that pull request into your main branch. (Note that if you did not own the repository that you just submitted a pull request to, you will not be able to do this step.) Click on "Merge pull reqeust" and then "Confirm merge". Unless you plan on using the branch again, click on “Delete branch” so as to not clutter your branch list. Go back to your Code tab and make sure that the README has been updated with your additions.
Unfortunately, we’re not quite done. Now we have another problem: GitHub has changes that our local computer does not! We just merged the country branch into the main branch but our local computer doesn’t know that. We have to tell it to pull in the changes from the origin remote.
Git Procedure 4.10. Trying git pull.
The easiest way to bring in new changes from GitHub is to use the
git pull command. git pull works exactly like git push. You need to tell Git which remote you are pulling from and which branch.(a)
Head back to your command line. If you need to, navigate (
cd) to your repo. You should notice that you are still on your country branch.(b)
Switch back to your main branch (Remember how?)
Answer.
git switch main(c)
Just like with
git push, decide on your remote and your branch. These will be the remote and branch from which you are pulling. Type in the correct command.
Answer.
> git pull origin main
remote: Enumerating objects: 1, done.
remote: Counting objects: 100% (1/1), done.
remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (1/1), 631 bytes | 631.00 KiB/s, done.
From <repo-url>
<commit-id> main -> origin/main
Updating <commit-id>
Fast-forward
README.md | 4 ++++
1 file changed, 4 insertions(+)
Note that it is possible to pull from other branches. Suppose you were working on the
country branch and someone else made changes to just the country branch (but the changes hadn’t been merged into main yet). You could use git pull origin country while on the country branch to update your local branch with the origin changes.Warning 4.4.0.1.
Git Procedure 4.10 demonstrates that your local repository and GitHub only communicate with each other when you tell them to. Any changes you make on GitHub will not be reflected on your computer unless you pull. Vice versa, any changes you make on your local computer will not be reflected on GitHub unles you push. Be careful with this. If you change a file locally and remotely on GitHub without pulling or pushing you might create a merge conflict. These are best avoided. The simplest conflicts can be resolved somewhat easily but they can quickly get very complicated. See Section C.7 for more information on this.
When working by yourself, merge conflicts are easier to avoid. Just make sure that you only edit at one place at a time (e.g. locally or remotely) then make sure both locations are up to date before editing in another place.
Small note for advanced users: as explained in Section C.7, you can edit in both locations at once as long as you do not edit the same line. Merge conflicts only arise when the same line(s) has been changed. So if I change lines 3 and 4 locally and 5 and 6 remotely, I can merge, pull, and push without any problems. But if I change line 7 in both locations … eek!
And that’s that! You now have made new changes and updated GitHub and your local computer and GitHub repo are on the same page. Great!
This might seem like a lot of work for one tiny edit. And you’re right. We edited four lines and it probably would have been easier to use GitHub for that edit. But it’s always nice to start simple. As it turns out, the steps discussed in this chapter are the same for each time you want to update GitHub with changes from local. The next section puts your skills to the test with an extensive activity and also provides a (hopefully) useful summary of the Git process.
