Skip to main content

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

Ian Curtis

Section 5.3 Editing

This part should seem familiar. Remember how to edit files on GitHub? (Hint: Subsection 3.2.3.) Let’s try editing a file on my aboutme repo. Click on the aboutyou.md file on the home page of the repo. This is a Markdown file, just like the README we were working with in Section 3.2. Follow Activity 5.2 to edit this file. Remember, things should look very similar to Markdown Basics and Checkpoint 3.2.3.4.
When most people collaborate, they make a bunch of changes on their fork. Then, when the changes are ready, they send them over to the main repository. This activity focuses on the first part of that process, editing files on your own fork.

(a)

Click on the “edit” button (the pencil icon on the right side of the page)

(b)

Follow the instructions on the file to add your own entry.
To contribute, add your name as a level two heading. This can be just your first name, just your last name, both, all names, initials, a name you like, your GitHub username, etc. In a paragraph, type the month, year, and the country and/or state/province you are contributing from. If you feel like it, tell us something cool about you! (See my example.)
Responses will be moderated. No explicit content whatsoever will be accepted (keep things G rated please!).

(c)

Once you are done editing, head to the Commit changes dialog. In the box that is autofilled with “Update aboutyou.md”, type a more informative commit message. A description is not necessary.

(d)

Do not select the button that says “Commit directly to the main branch”. It is always a good idea to create a branch when editing someone else’s work.
Select the button that allows you to create a new branch and type in a better branch name.

(e)

Notice that the button now says “propose changes” rather than “commit changes”. Again, this is because you do not have permission to commit changes to my repo, just propose them. Click on this button once you have changed the branch name.

(f)

This will conveniently bring you right to the pull request page, which might look familiar. Your previous commit message will automatically be there. The only thing you really need to do is click on “Create pull request”. (But read below before you click it.)
Also take note at the top of this page GitHub tells you what branches are being merged. You will probably see
base: main compare: <your-branch-name>.
If not, use the dropdown menus to make yours look like the above. This means that you are taking your branch and attempting to merge your changes into the main branch from the “base” repository, or your repo.
Like before, if you scroll down, you can see all of the changes you made. Later, I will be able to see this too, to make sure that you only changed what you were supposed to and didn’t write anything R-rated.
Now you can create the pull request.

(g)

Here, you are asking yourself for permission to merge into your fork. Hopefully you give yourself permission to do so. Click on “Merge pull request” and then “Confirm merge”. You may delete the branch if you’d like.
Assuming you have completed Activity 5.2, you might notice that a new box has popped up in the main page of your fork. It might say something like “This branch is 2 commits ahead of ian-curtis:main”. This is how you create a pull request.
Now you can make as many changes and commits as you want before opening a pull request (this will change the message on the dialog box). You don’t even have to merge your changes into your fork’s main branch before opening a pull request. However, I usually choose to do so just so I know that all of my changes from my various branches are included where they are supposed to be. Feel free to continue making edits and/or commits to your entry in the aboutyou.md file before continuing!
This activity assumes you have been following along throughout the section. Activity 5.2 must be completed before this activity. Just like in Subsection 3.3.4, we will use the “Contribute” option on the Code tab of a repo (see Figure 5.3.0.1) even though there are other ways to open a pull request.
Image of top part of home page of a fork. This is the Code tab with main branch selected. At least one commit must be made to have the contribute dialog appear.
Figure 5.3.0.1. The Contribute dialog box on GitHub.

(a)

Make sure you are on your fork’s home page (the Code tab). Click on the Contribute drop down menu and then the “Open pull request” button. This will bring you to a new page containing familiar elements.

(b)

This task is all about noticing. Take a minute to identify each of the following elements on the page. These will help you in the future to recognize that you are opening a pull request for someone else’s repository and can be a reassurance that you are in the right place.
  1. The title of the repository has changed. You are no longer on your fork, but on the forked-from repo. As such, the Watch, Fork, and Star data have changed to describe that authoritative repo.
  2. There is a dialog box indicating which branches are being merged. There are more boxes than before. There should be four, allowing you to specify which repo and branch to want to merge from and which repo and branch you want to merge to. Usually GitHub gets it right, but not always, so check to make sure these are what you want.
    The base repository is the repo you are merging to (here, the authoritative repo), the head repository is the repo you are merging from (here, your fork). The base branch is the specific branch you are merging to (often main) and the compare branch is the branch from your fork you are merging from (often main for me personally).
  3. After these boxes is, hopefully, a green checkmark and an “Able to merge” message. This is what you want. You might also get a red message about conflicts or other messages. In this case, you might have a merge conflict and will need to do some extra work. See Section C.7.
  4. There is a summary of all the commits made on the branch (with their commit messages)
  5. There is info on all of your specific changes in each file

(c)

Once you have found all of the above, go ahead and click on the “Create pull request” button. If your pull request has more than one commit, you will have to enter a title for the request. This is where a description might be helpful. Choose a title that describes what you are doing. If you would like to supply more information, ask a question, or give clarification, type as much as you want into the “Leave a comment” text box. Then click “Create pull request”.

(d)

This time notice that there is no option to “Merge” into the main branch. This is because you do not have write access to the parent repository. At this point, wait for a moderator from the authoritative repo to approve your pull request.
Note that forking can drastically increase the complexity of the GitHub tree. Recall from Figure 3.3.4.5 that branches make another branch on the tree which you eventually merge back into the main branch, or the trunk of the tree. Cloning made this more complex due to the copy on your computer. Forking adds another copy into the mix. Figure 5.3.0.2 provides a possible diagram of the forking process. But there are many different variations to this diagram as it is up to you how many branches/commits to make and to which branch you push.
Arrow diagram. Main repo to fork copy. Branches and edits are made on the fork and are merged into the fork’s main branch. Then all edits are merged into main repo’s main branch.
Figure 5.3.0.2. Example of GitHub Tree with a fork
Now you can sit back and relax until a moderator reviews your contribution. If they make a comment or approve your pull request, you will get an email to the email address on your account. Once they approve your work, great! Congrats! Are you done? Proceed to Section 5.4 to find out!
PrevTopNext