|
2 | 2 |
|
3 | 3 | We appreciate your initiative and would love to integrate your work with the rest of the project! Here is how you can help us do it as quickly as possible. |
4 | 4 |
|
5 | | -- check, that your feature branch is up-to-date. If it's not, there is a risk of merge conflicts or other issues that will complicate merging your changes into the main repository. Refer to these resources for more information on syncing your repo: |
| 5 | +- Check, that your feature branch is up-to-date. If it's not, there is a risk of merge conflicts or other issues that will complicate merging your changes into the main repository. Refer to these resources for more information on syncing your repo: |
6 | 6 | - [GitHub Help: Syncing a Fork](https://help.github.com/articles/syncing-a-fork/) |
7 | 7 | - [AC: Keep Your Forked Git Repo Updated with Changes from the Original Upstream Repo](http://www.andrewconnell.com/blog/keep-your-forked-git-repo-updated-with-changes-from-the-original-upstream-repo) |
8 | 8 | - Looking for a quick cheat sheet? Look no further: |
9 | 9 |
|
10 | | - ```sh |
11 | | - # assuming you are in the folder of your locally cloned fork.... |
12 | | - git checkout dev |
| 10 | +```bash |
| 11 | +# assuming you are in the folder of your locally cloned fork.... |
| 12 | +git checkout dev |
13 | 13 |
|
14 | | - # assuming you have a remote named `upstream` pointing to the official **sp-dev-fx-property-controls** repo |
15 | | - git fetch upstream |
| 14 | +# assuming you have a remote named `upstream` pointing to the official **sp-dev-fx-property-controls** repo |
| 15 | +git fetch upstream |
16 | 16 |
|
17 | | - # update your local dev branch to be a mirror of what's in the main repo |
18 | | - git pull --rebase upstream dev |
| 17 | +# update your local dev branch to be a mirror of what's in the main repo |
| 18 | +git pull --rebase upstream dev |
19 | 19 |
|
20 | | - # switch to your branch where you are working, say "issue-xyz" |
21 | | - git checkout issue-xyz |
| 20 | +# switch to your branch where you are working, say "issue-xyz" |
| 21 | +git checkout issue-xyz |
22 | 22 |
|
23 | | - # update your branch to update its fork point to the current tip of dev & put your changes on top of it |
24 | | - git rebase dev |
25 | | - ``` |
26 | | -- submit PR to the **dev** branch of the main repo. PRs submitted to other branches will be declined |
27 | | -- let us know what's in the PR: is it a new command, bug fix or a minor update in the docs? The clearer the information you provide, the quicker your PR can be verified and merged |
28 | | -- ideally 1 PR = 1 commit - this makes it easier to keep the log clear for everyone and track what's changed. If you're new to working with git, we'll squash your commits for you when merging your changes into the main repo |
29 | | -- don't worry about changing the version or adding yourself to the list of contributors in `package.json`. We'll do that for you when merging your changes. |
| 23 | +# update your branch to update its fork point to the current tip of dev & put your changes on top of it |
| 24 | +git rebase dev |
| 25 | +``` |
| 26 | + |
| 27 | +- Submit PR to the **dev** branch of the main repo. PRs submitted to other branches will be declined |
| 28 | +- Let us know what's in the PR: is it a new command, bug fix or a minor update in the docs? The clearer the information you provide, the quicker your PR can be verified and merged |
| 29 | +- Ideally 1 PR = 1 commit - this makes it easier to keep the log clear for everyone and track what's changed. If you're new to working with git, we'll squash your commits for you when merging your changes into the main repo |
| 30 | +- Don't worry about changing the version or adding yourself to the list of contributors in `package.json`. We'll do that for you when merging your changes. |
30 | 31 |
|
31 | 32 |  |
0 commit comments