Then you can retrieve upstream changes and rebase on them into your code like this:
```bash
$ git pull --rebase upstream master
```
For more information on maintaining a fork, please see the GitHub Help article [Fork a Repo][] and information on
[rebasing][] from git.
## 3. Create a Branch
The easiest workflow is to keep your master branch in sync with the upstream branch and do not locate any of your own
commits in that branch. When you want to work on a new feature, you then ensure you are on the master branch and create
a new branch from there. While the name of the branch can be anything, it can often be easy to use the ticket number
you might be working on. For example:
```bash
$ git checkout -b t12345 master
Switched to a new branch 't12345'
```
You will then be on the feature branch. You can verify what branch you are on like this:
```bash
$ git status
# On branch t12345
nothing to commit, working directory clean
```
## 4. Make Changes and Commit
Now you just need to make your changes. Once you have finished your changes (and tested them) you need to commit them
to your local repository (assuming you have staged your changes for committing):
```bash
$ git status
# On branch t12345
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: somefile.js
#
$ git commit -m"Corrects some defect, fixes #12345, refs #12346"
[t12345 0000000] Corrects some defect, fixes #12345, refs #12346
1 file changed, 2 insertions(+), 2 deletions(-)
```
## 5. Rebase and Push Changes
If you have been working on your contribution for a while, the upstream repository may have changed. You may want to
ensure your work is on top of the latest changes so your pull request can be applied cleanly:
```bash
$ git pull --rebase upstream master
```
When you are ready to push your commit to your GitHub repository for the first time on this branch you would do the
following:
```bash
$ git push -u origin t12345
```
After the first time, you simply need to do:
```bash
$ git push
```
## 6. Issue a Pull Request
In order to have your commits merged into the main repository, you need to create a pull request. The instructions for
this can be found in the GitHub Help Article [Creating a Pull Request][]. Essentially you do the following:
1. Go to the site for your repository.
2. Click the Pull Request button.
3. Select the feature branch from your repository.
4. Enter a title and description of your pull request mentioning the corresponding [bug database][] ticket in the description.
5. Review the commit and files changed tabs.
6. Click `Send Pull Request`
You will get notified about the status of your pull request based on your GitHub settings.
## 7. Request is Reviewed and Merged
Your request will be reviewed. It may be merged directly, or you may receive feedback or questions on your pull
request.
# What Makes a Successful Pull Request?
Having your contribution accepted is more than just the mechanics of getting your contribution into a pull request,
there are several other things that are expected when contributing to the Dojo Toolkit which are covered below.
## Coding Style and Linting
Dojo has a very specific [coding style][styleguide]. All pull requests should adhere to this.
## Inline Documentation
Dojo has an inline API documentation called [DojoDoc][]. Any pull request should ensure it has updated the inline
documentation appropriately or added the appropriate inline documentation.
## Test Cases
If the pull request changes the functional behaviour or is fixing a defect, the unit test cases should be modified to
reflect this. The committer reviewing your pull request is likely to request the appropriate changes in the test
cases. Dojo utilises [Intern][] for all new tests, and has legacy support for its previous generation test harness called [D.O.H.][] and is available as part of the [dojo/util][] repository. All new tests should be authored using Intern.
It is expected that you will have tested your changes against the existing test cases and appropriate platforms prior to
submitting your pull request.
## Licensing
All of your submissions are licensed under a dual "New" BSD/AFL license.
## Expect Discussion and Rework
Unless you have been working with contributing to Dojo for a while, expect a significant amount of feedback on your
pull requests. We are a very passionate community and even the committers often will provide robust feedback to each
other about their code. Don't be offended by such feedback or feel that your contributions aren't welcome, it is just
that we are quite passionate and Dojo has a long history with many things that are the "Dojo-way" which may be
unfamiliar to those who are just starting to contribute.
