|
| 1 | +# Contributing |
| 2 | + |
| 3 | +When contributing to this repository, please first discuss the change you wish to make via issue with the owners and maintainers of this repository before making a change. |
| 4 | + |
| 5 | +Please note we have a [code of conduct](CODE_OF_CONDUCT.md), please follow it in all your interactions with the project. |
| 6 | + |
| 7 | +## Pull Request Process |
| 8 | + |
| 9 | +So you want to submit some changes to the project, awesome! The Solrevdev.InstagramBasicDisplay project welcomes new contributors. This section will guide you through the contribution process. |
| 10 | + |
| 11 | +### Step 1: Fork |
| 12 | + |
| 13 | +Fork Solrevdev.InstagramBasicDisplay [on GitHub](https://github.com/solrevdev/instagram-basic-display) and checkout your local copy |
| 14 | + |
| 15 | +``` |
| 16 | +> git clone [email protected]:your-github-username/instagram-basic-display.git |
| 17 | +> cd instagram-basic-display |
| 18 | +> git remote add upstream git://github.com/solrevdev/instagram-basic-display.git |
| 19 | +``` |
| 20 | + |
| 21 | +### Step 2: Branch |
| 22 | + |
| 23 | +Create a feature branch for your code and start hacking away. |
| 24 | + |
| 25 | +``` |
| 26 | +> git checkout -b my-new-feature -t upstream/dev |
| 27 | +``` |
| 28 | + |
| 29 | +### Step 3: Commit |
| 30 | + |
| 31 | +**Writing good commit messages is important.** A commit message should describe what changed, why, and reference issues closed (if any). Follow these guidelines when writing one: |
| 32 | + |
| 33 | +1. The first line should be around 50 characters or less and contain a short description of the change. |
| 34 | +2. Keep the second line blank. |
| 35 | +3. Wrap all other lines at 72 columns. |
| 36 | +4. Include `Closes #N` where *N* is the issue number the commit fixes, if any. |
| 37 | + |
| 38 | +The first line must be meaningful as it's what people see when they run `git shortlog` or `git log --oneline`. |
| 39 | + |
| 40 | +### Step 4: Stay Up To Date |
| 41 | + |
| 42 | +Periodically, you'll want to pull in the latest committed changes. Merge commits and clean-up commits from merges lowers the signal-to-noise ratio of your Pull Request. Rebase helps keep the commits on the branch about just your feature. |
| 43 | + |
| 44 | +``` |
| 45 | +> git fetch upstream |
| 46 | +> git pull --rebase |
| 47 | +``` |
| 48 | + |
| 49 | +**note**: If a conflict comes up during a rebase, because of the way rebase works your changes will be on the *remote* side of the conflict while the pulled-in commits are the *local* side. This is probably opposite of how you are thinking about it but makes sense since rebase essentially stashes your branch commits, pulls in the new commits from the source, and finally re-applies your commits. So your commits are now the "new" ones, hence the *remote* side. |
| 50 | + |
| 51 | +### Step 5: Push |
| 52 | + |
| 53 | +You're almost done! Push the entire branch to your clone |
| 54 | + |
| 55 | +``` |
| 56 | +> git push origin my-new-feature |
| 57 | +``` |
| 58 | + |
| 59 | +Go to https://github.com/your-github-username/instagram-basic-display.git, press *Pull Request*, and fill out the form. |
| 60 | + |
| 61 | +Congratulations! |
| 62 | + |
| 63 | +### Other Items of Note |
| 64 | + |
| 65 | +1. Ensure any install or build dependencies are removed before the end of the layer when doing a build. |
| 66 | +2. Update the [README.md](../readme.md) with details of changes to the interface, this includes new environment variables, exposed ports, useful file locations. |
| 67 | +3. Please submit all pull-requests to the master branch unless you are working on a formal project, in which case you should submit the pull-request to that project-specific branch. |
| 68 | +4. Project maintainers may merge the Pull Request. |
0 commit comments