Last updated by 2 years ago
Page: GitHub Forking and Pull Requests, Version:2
One of the benefits of GitHub is the way that you can easily contribute to a project by forking the repository and sending pull requests with your changes.What follows are some guidelines to help ensure that your pull requests are speedily dealt with and provide the information we need. They will also make your life easier!
Create a local branch for your changesYour life will be greatly simplified if you create a local branch to make your changes on. For example, as soon as you fork a repository and clone the fork locally, execute
This will create a new local branch called "mine" based off the "master" branch. Of course, you can name the branch whatever you like - you don't have to use "mine".
git checkout -b mine
Create JIRAs for non-trivial changesFor any non-trivial changes, raise a JIRA issue if one doesn't already exist. That helps us keep track of what changes go into each new version of Grails.
Include JIRA issue ID in commit messagesThis may not seem particularly important, but having a JIRA issue ID in a commit message means that we can find out at a later date why a change was made. Include the ID in any and all commits that relate to that issue. If a commit isn't related to an issue, then there's no need to include an issue ID.
Merge insignificant commitsYou may find that you miss a bunch of files when you do a commit or that one or more typos need fixing. The follow up commits that result are basically just noise. Do the users of the main repository really care if you had to add a bunch of files that were "missing from the previous commit"? Fortunately, you can remove the commit without losing the changes by doing a rebase.Start by finding the most recent commit that you don't want to affect:
Copy the hash that identifies that commit and then run
This will put you into interactive rebase mode and launch an editor containing a list of the commits since the one you specified. If you want to merge one commit (A) into another one (B), then just move the line representing that commit (A) immediately after the line for commit B. Next, replace the "pick" for commit A with either "squash" or "fixup" (you'll see what each of these means in the editor).Once you've made the changes you want, save the file in the editor and git will do all the necessary merging. If you then run
git rebase -i <hash>
git logagain, you'll see a cleaner sequence of commits!
Make sure your fork is up to dateSince the core developers must merge your commits into the main repository, it makes life much easier if your fork on GitHub is up to date before you send a pull request.Let's say you have the main repository set up as a remote called "upstream" and you want to submit a pull request. Also, all your changes are currently on the local "mine" branch but not on "master". The first step involves pulling any changes from the main repository that have been added since you last fetched and merged:
This should complete without any problems or conflicts. Next, rebase your local branch against the now up-to-date master:
git checkout master git pull upstream
What this does is rearrange the commits such that all of your changes come after the most recent one in master. Think adding some cards to the top of a deck rather than shuffling them into the pack.You'll now be able to do a clean merge from your local branch to master:
git checkout mine git rebase master
Finally, you must push your changes to your remote repository on GitHub, otherwise the core developers won't be able to pick them up:
git checkout master git merge mine
You're now read to send the pull request from the GitHub user interface.