Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Send Pull Request from branch, not from master. #341

Merged
merged 2 commits into from
Jul 28, 2015
Merged

Send Pull Request from branch, not from master. #341

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
608b0db
Send Pull Request from branch, not from master.
rlovtangen Jul 22, 2015
3a40781
Use "issue_123" as example branch name to illustrate that there shoul…
rlovtangen Jul 22, 2015
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 12 additions & 11 deletions src/en/guide/contributing/patchesCore.gdoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,10 +9,10 @@ h4. Create a local branch for your changes

Your 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
{code}
git checkout -b mine
git checkout -b issue_123
{code}

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".
This will create a new local branch called "issue_123" based off the "master" branch. Of course, you can name the branch whatever you like, but a good idea would be to reference the GitHub issue number that the change is relevant to. Each Pull Request should have its own branch.

h4. Create Github issues for non-trivial changes

Expand All @@ -26,31 +26,32 @@ h4. Make sure your fork is up to date

Since 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:
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 "issue_123" 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:
{code}
git checkout master
git pull upstream
{code}

This should complete without any problems or conflicts. Next, rebase your local branch against the now up-to-date master:
{code}
git checkout mine
git checkout issue_123
git rebase master
{code}

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:
{code}
git checkout master
git merge mine
{code}
h4. Push your branch to GitHub and send Pull Request

Finally, you must push your changes to your fork on GitHub, otherwise the core developers won't be able to pick them up:

Finally, you must push your changes to your remote repository on GitHub, otherwise the core developers won't be able to pick them up:
{code}
git push
git push origin issue_123
{code}

{note}
You should not merge your branch to your forks master. If the Pull Request is not accepted, your master will then be out of sync with upstream forever.
{note}

You're now ready to send the pull request from the GitHub user interface.

h4. Say what your pull request is for
Expand Down