-
Notifications
You must be signed in to change notification settings - Fork 22
Part 4: Pull Requests
If you remember from 4 wiki pages ago, a Pull Request is how you request to make changes to a public git repository.
Now that you've made an event post and committed the changes to your personal fork of this repository, you are going to need to submit a pull request for the change to this repository.
Doing this on GitHub is pretty easy. Just navigate to your profile, and find your fork of the git-workshop-W16 repository. Click on the branches tab and find the branch you just made. Then click "New pull request".
This will take you to a page to review what the pull request you're submitting is. In this workshop, you changed one thing -- you added a new event post. As such, your pull request should contain one commit and one changed file. If you see more than one changed file, or more than one commit you're going to need to reset your branch and submit a new PR. Luckily, we wrote a wiki page for this (Resetting a Branch), but we recommend you call over a mentor to help walk you through it.
Otherwise, just hit the submit button. Congratulations, you've just submitted your first PR!
Another important part of open source contributions is code review. Any time someone submits a pull request to a public repository, any other contributors on GitHub can comment on the PR.
Mentors will be reviewing everyone's pull requests, but we encourage you to comment on each other's PRs as well!
In GitHub each PR has three tabs: Comments, Commits, and Files Changed.
On the Comments tab you will see all the conversation on that PR. Here you can add general comments about the PR or respond to comments by others.
The Commits tab will show you a detailed list of every commit in the PR.
In the Files Changed tab you can view the specific changes on the files this PR proposes changes to. Click the small + sign next to each line to add a comment about a specific line.
Things to look out for in an event post:
- Spelling/grammar errors
- Correct times and dates
- Accurate tags in the metadata
- Markdown mistakes (hyperlinks, bolding etc)
Once a mentor signs off on your PR, they will merge it into master and deploy our special workshop copy of the site. When your PR is merged you can view what the website now looks like here.
After you submit your PR, other contributors might add comments asking you to change things. If someone asks you to make a small change to the file you're submitting, such as editing a typo, you can just make the changes in your local repo and do this:
git status # See what's been changed
git add filename # Stage your changes for a commit
git commit --amend --no-edit # Amend your previous commit without editing the commit message
git push origin HEAD -f # **Force-push** (-f) your changes back to GitHub
Other changes you could potentially be asked to make might require you to add new commits. Sometimes you might end up adding too many commits, and you'll be asked to squash them (see Squashing Commits).
If there is a problem with your commits that requires resetting a branch, you could be asked to do that, too.
If you forget to push your amended commits with the -f flag (for "force"), git will reject your changes by default:
$ git push origin HEAD
To [email protected]:j2smith/awesomesauce-repo.git
! [rejected] HEAD -> test-fail (non-fast-forward)
error: failed to push some refs to '[email protected]:j2smith/awesomesauce-repo.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
THIS HINT IS WRONG. The hint makes sense if you are working on a shared repository with a number of other contributors; it is possible that they could have made changes in the interim since you last fetched the remote repository. However, when we're working with GitHub, we know that we are the only person working on the remote "origin" repo. The reason we get this error message is because our amend mutated our git tree, and by default git doesn't want you to accidentally break things with mutation. However, since we're working on a feature branch, it is okay to mutate history.
Do not git pull! Use git push origin HEAD -f instead.
If you're all done the curriculum read the Part 5: Beyond this Workshop page to see how else you can learn about Git and Open Source software.