Section 6.3 Revisiting the Three Step Process
Just as in Section 4.3, this is a very important section. Take care to do everything in the correct order and with the correct keywords.
Recall that the three step process for sending changes back to GitHub consists of
- Staging your files for sending
- Commiting your changes
- Pushing your changes to GitHub
Since we’ve already covered much of this material, I won’t go into as much detail. I will, however, point out any significant differences. As you move forward, don’t forget about the handy
git status command to remind you what files have been edited, staged, or committed.Subsection 6.3.1 Staging Files
This step will not be any different from before. Use Git Procedure 4.5 to stage your edited
secret.txt file.Remember that
git add is pretty flexible. If you’ve edited more than one file, you can choose which files to add. Maybe you want to make two commits. In that case, stage some files and commit them, then stage the other files and commit them.Subsection 6.3.2 Committing Files
This step will also not be any different from before. Just remember that you should try to design your commit messages to be short and descriptive. If the repo you are contributing to has a preference for how commit messages are written, you should try to follow that as best you can. Otherwise, don’t be offended when your commit message is changed.
Git Procedure 4.6 will probably be helpful as will the reminders at the end of Subsection 4.3.3. Commit your
secret.txt file and provide an apt commit message (especially one that shows you were reading this book).Subsection 6.3.3 Pushing Files
Alright, here is where some small changes come up. In Section 4.3, we pushed to the origin repository. But from Section 5.2 and Section 5.4, when you fork, you introduce another remote: upstream. And now that we have a clone, we also have a local repo.
Alright, so what about right now? You have your changes staged and committed, but to where do you push? Local? That won’t work since you already have the changes locally. Upstream? It might make sense to push directly to the authoritative repo, but since you don’t have write access, this will likely not work. The right thing to do here is push to origin. Remember, “origin” in this case, refers to your fork.
From Subsection 4.3.4 (and Git Procedure 4.7) can you figure out what to type into the terminal to push to origin?
Remember you need to specify the remote and the branch you are pushing to so
git push origin <branch-name> will do nicely.Believe it or not, Git Procedure 4.8 was written in generic terms, so it applies here as well! Keep it handy, or perhaps keep Section 4.5 and Section 6.5 in mind as you proceed in your Git career. Now let’s go create a pull request from that push we just made.
