Part 4 - Summary

---

This completes Part 4.

To summarize, I'm going to contribute to the Getting Git repository by using the commands we learned in Part 4, as well as create Pull Requests.

A reminder not to worry about following along with the commands. Instead focus on the process.

In addition, I'll cover pull requests in more detail in one of the Everyday Git videos.

So the first thing I'll do is navigate to my workspace and clone my fork of the gettinggit repository.

Again it's best to use a fork as it provides your own copy of the repository to work on.

In addition, you may not have access to work on the parent repository directly.

I’ll also add an upstream remote.

This will allow me to pull changes from the parent repository.

Before starting my new work, I'll go run git fetch to see if there are any changes on upstream:

git fetch upstream

It looks like there are a few changes.

I'll pull them down to update my master branch and push them to my fork on GitHub to keep it up-to-date and clean so I can follow the workflow outlined in Part 3.

So now that I'm up-to-date, I will checkout a testimonial branch.

I'll edit of the testimonial.md file, and write a glowing review of the Getting Git video course.

Then I'll review my changes and commit them.

I'm done adding my testimonial, so I’ll push the branch to my fork and add tracking with the -u option.

Now that I pushed my changes I'll use a custom git open command to jump out to GitHub and create the Pull Request.

While there are a few ways to do this, GitHub calls out recently created branches making it easy to open a Pull Request.

I’ll verify my request to merge my testimonial branch into the master branch of gettinggit.

While you're welcome to change the Pull Request message, GitHub automatically pre-fills this with the most recent commit.

In this case, that's fine since it's the only commit. So I'll go ahead and click Open Pull Request.

Upon doing so it's available for the owner of the gettinggit repository to review and merge at their convenience.

Let's create one more Pull Request for the register branch we created in the git push video.

I'll go back to my fork and to the Branches tab to create the Pull Request.

Again I’ll verify my request to merge the register branch into the master branch of gettinggit and leave the default commit message.

However, notice this time the Create Pull Request button is disabled.

This indicates that my register branch is behind. While I could go ahead and open the Pull Request, let’s fix this first.

So I'll go back to the command line.

I'll switch to the master branch and pull the latest from the upstream remote.

So, I'll check out my register branch, and rebase it with master.

I could rebase with upstream/master, but since I just pulled changes from upstream to my master branch I know they're the same.

By doing so we see it picked up a few updates, but unfortunately there was a conflict when applying my changes.

If I run git status it looks like someone else has signed the registry since I have.

I'll quickly resolve this in my text editor by removing the conflict markers and re-appending my username.

I'll save and add the file. Then run git rebase ––continue to complete the rebase.

Now my local branch is up-to-date, so I'll push it to GitHub.

However, upon doing its rejected because the local commit history doesn't match the commit history on GitHub.

This makes sense as I used rebase to update our branch.

Since I know I used rebase, which changed the commit history, and I'm the only one working on this branch I'm comfortable force pushing.

Now that's been pushed I'll go back to GitHub to complete my Pull Request.

And that's it.

So I just contributed to the gettinggit repository on GitHub by opening 2 Pull Requests.

I did my work on separate branches which made them easy to manage, despite pulling changes from multiple remotes.

So that completes Part 4. You’re now ready to share your work with others.