Pull Requests

Page history last edited by Jörn Zaefferer 4 months, 1 week ago

How to add a remote repo

In many cases you'll need to add a remote repo in order to pull changes.

git remote add -f <username> <repo-url>

git remote add -f scottgonzalez https://github.com/scottgonzalez/jquery-ui.git

With hub installed and an additional alias in your .gitconfig (fork = remote add -f), you can just do this:

git remote fork scottgonzalez

To update an existing remote (or when forgot the -f flag), use fetch:

git fetch <username>

git fetch scottgonzalez

How to test a pull request

In some cases, the pull request will be simple enough to verify straight from GitHub's pull request interface. In those cases, you can use the merge functionality built into GitHub. However, you'll often want to test the changes locally before accepting the pull request.

From a pull request, you can click on one of the commits to find the repo URL. For example, from https://github.com/jquery/jquery-ui/pull/162 we can click on commit 710d762 and find out that the repo URL is https://github.com/petersendidit/jquery-ui.git. Once you've got the repo URL, follow the steps above to add the remote repo.

Testing the branch (optional)

To test the branch that will be pulled, you can checkout the branch locally. The pull request page will tell you which branch the commits live in.

git checkout <username>/<branch>

git checkout petersendidit/tabs_4386

Testing the merge

To test if the fix works when merged into the official repo, you simply merge the remote branch into your local master branch.

Note: You don't need to test the branch on its own as described above.

Note: You must be on your local master branch (or whatever branch you want to merge into) before executing the following command.

git merge <username>/<branch>

git merge petersendidit/tabs_4386

If everything looks good after the merge, you can push the changes up to GitHub and it will automatically close the pull request.

git push origin master

If there is a problem with the merge, you can reset back to the previous state and then leave a comment on the pull request.

git reset --hard origin/master

How to correct a commit message

Sometimes there will be a pull request with a single commit that looks good, but the commit message doesn't conform to our Commit Message Style Guide. You can either ask the developer to fix the commit message or you can cherry-pick the commit and edit the message yourself.

First you'll need to add the remote repo, follow the steps in the How to test a pull request section above to find and add the remote repo.

git cherry-pick -e <sha>

git cherry-pick -e 710d762

The -e flag tells git that you want to edit the commit message.

Unlike merging, cherry-picking creates a new commit. This means that after you edit the commit message, your history will contain a commit with a different sha than the one in the pull request. When you push this commit up to GitHub the pull request will not be automatically closed. After pushing to GitHub, close the pull request with a comment that says "Thanks, landed in <sha>" where <sha> is the new commit.

How to edit a commit or squash multiple commits

There are often cases where a pull request fixes a bug, but doesn't conform to our coding standards. In these cases, you can choose to fix the mistakes yourself or leave comments on the pull request asking the developer to fix them.

Editing a commit

To edit a commit, you'll need to follow the steps in the How to test a pull request section above to find and add the remote repo.

git cherry-pick -n <sha>

git cherry-pick -n 710d762

The -n flag tells git not to create a commit. This results in pulling and staging the changes.

You can now edit the code, add your changes and commit. When you commit, you'll want to ensure that you set the original committer as the author.

First you'll need to find the name and email address from the original committer. To find this, you can simply look at the commit that you cherry picked.

git log <sha>

git log 710d762

You'll see a line that specifies the author of the commit

Author: David Petersen <public@petersendidit.com>

When you commit, you'll specify this information for the author:

git commit --author="<author>"

git commit --author="David Petersen <public@petersendidit.com>"

Squashing commits

If you ask the developer to fix the style problems, there's a good change they wil do it with additional commits, as opposed to creating a new branch. When this happens, you may want to squash the commits into a single commit.

To squash the commits, simply follow the steps in the How to test a pull request section above, but when you get to the merge step, use the --squash flag. This will apply and stage all the changes, but won't commit anything. You can then proceed to create the new single commit, making sure you set the author.

git merge --squash <username>/<branch>

git commit --author="<author>"

How to merge into 1-8-stable

If you merge (or cherry-pick) a fix into master that should be included in the next 1.8.x release, you'll need to copy the fix over to the 1-8-stable branch.

Note: If you used GitHub's pull request interface to merge a pull request, you'll need to pull the changes into your local master branch before cherry-picking.

git cherry-pick -x <sha>

git cherry-pick -x 710d762

The -x flag tell git to include a reference to the original commit in the new commit message.

This copies the changes from the commit in the master branch into the 1-8-stable branch, creating a new commit. Because this is a new commit, we use the -x option so that we can easily associate changes in the 1-8-stable branch with the original fix in the master branch.

Now that you've cherry-picked the commit into the 1-8-stable branch, all you need to do is push the commit to GitHub.