|
| 1 | +# Contributing |
| 2 | + |
| 3 | +When contributing to this repository, please first discuss the change you wish to make via issue, |
| 4 | +email, or any other method before making a change. |
| 5 | + |
| 6 | +Please note we have a code of conduct, please follow it in all your interactions with the project. |
| 7 | + |
| 8 | +## Forks and Pull Requests |
| 9 | + |
| 10 | +Development on lime-packages follows the Fork and Pull Request method popularized by GitHub: |
| 11 | + |
| 12 | +- Every contributor has their own complete copy, called a *Fork* |
| 13 | +- Contributors implement features or fix bugs on their own fork in a feature branch. |
| 14 | +- When the contributor wants to integrate their changes back into the main repository, |
| 15 | + they will create a *Pull Request*. |
| 16 | + |
| 17 | +Each of these steps will be discussed in turn: |
| 18 | + |
| 19 | +#### Forking |
| 20 | + |
| 21 | +The first thing that you will need for development, is to create a new copy of the repository to |
| 22 | +work on. This is known as "Forking" and is a defining characteristic of distributed |
| 23 | +SCM systems: each person works on their own complete copy of the repository. Git is designed to |
| 24 | +make it trivially easy to keep these repositories in sync by passing signed revisions amongst the |
| 25 | +individual copies. |
| 26 | + |
| 27 | +In order to create a fork: |
| 28 | + |
| 29 | +1. Log into GitHub and go to the [lime-packages GitHub repository](https://github.com/libremesh/lime-packages). |
| 30 | + |
| 31 | +2. Click "Fork". You should be redirected to a complete copy of the repository which now resides in your account. |
| 32 | + |
| 33 | +3. On your workstation, create a clone of the Git repository: |
| 34 | + ```git clone git@github.com:<your-username>/lime-packages.git``` |
| 35 | + This will create yet another complete copy of the repository: one that will reside |
| 36 | + on your workstation. |
| 37 | + |
| 38 | +4. Checkout the `master` branch. |
| 39 | + ```git checkout master``` |
| 40 | + |
| 41 | +### Branching |
| 42 | + |
| 43 | +Any changes that are made to the lime-packages code-base should be done in their own branch. The branch |
| 44 | +should be made from the tip of `master`, which is the development branch. Before starting |
| 45 | +any piece of work, ensure that you fetch the latest upstream changes from the repository. |
| 46 | +Doing so will ensure that you have an up-to-date copy of `master`, that changes made by others |
| 47 | +will not be lost, and will also reduce the chances of conflicts when it comes time to merging the |
| 48 | +changes back to lime-packages. |
| 49 | + |
| 50 | +#### Branch Names |
| 51 | + |
| 52 | +There is only one key branch: |
| 53 | + |
| 54 | +- `master`: this branch is the working version that is currently under development. All |
| 55 | + new feature branches should be made from the tip of `master` and all PR's should have `master` |
| 56 | + set as the target. |
| 57 | + |
| 58 | +For any new feature branches, the following naming convention is recommended: |
| 59 | + |
| 60 | +### `<type>/<name>` |
| 61 | + |
| 62 | +#### `<type>` |
| 63 | +``` |
| 64 | +issue - Code changes linked to a known issue. |
| 65 | +feature - New feature. |
| 66 | +hotfix - Quick fixes to the codebase. |
| 67 | +sandbox - Experiments (will never be merged). |
| 68 | +``` |
| 69 | + |
| 70 | +#### `<name>` |
| 71 | +Always use dashes to seperate words, and keep it short. |
| 72 | + |
| 73 | +##### Examples |
| 74 | +``` |
| 75 | +issue/133 |
| 76 | +feature/smonit |
| 77 | +hotfix/driver-xxx |
| 78 | +sandbox/new-crazy-thing |
| 79 | +``` |
| 80 | + |
| 81 | +#### General Workflow |
| 82 | + |
| 83 | +The general workflow for branching is as follows: |
| 84 | + |
| 85 | +1. Fetch the latest changes from `upstream` (i.e. the main repository): |
| 86 | + |
| 87 | + ```git fetch upstream master``` |
| 88 | + |
| 89 | +2. Check-out you copy of `master` and merge the upstream changes: |
| 90 | + |
| 91 | + ```git checkout master``` |
| 92 | + |
| 93 | + ```git merge upstream/master``` |
| 94 | + |
| 95 | + You now have an up-to-day copy of the `master` branch. |
| 96 | + |
| 97 | +3. Create a new branch for your changes: |
| 98 | + |
| 99 | + ```git checkout -b <branch name>``` |
| 100 | + |
| 101 | +4. Run the tests: read [[Testing docs](testing)]. |
| 102 | + |
| 103 | +5. Make your changes, we encourage you to try to add a test. |
| 104 | + |
| 105 | +6. Make sure the tests are still running with success. |
| 106 | + |
| 107 | +7. Push the changes to `origin` (i.e. your fork) |
| 108 | + |
| 109 | + ```git push origin <branch name>``` |
| 110 | + |
| 111 | +8. Create a new Pull Request (see below). |
| 112 | + |
| 113 | +#### Creating A Pull Request |
| 114 | + |
| 115 | +In order to integrate your changes into the main lime-packages repository, you will |
| 116 | +need to create a *Pull Request* in GitHub. |
| 117 | + |
| 118 | +1. Log into GitHub and go to your fork of lime-packages. |
| 119 | + |
| 120 | +2. Click "New Pull Request" |
| 121 | + |
| 122 | +3. Make sure that the following properties are set: |
| 123 | + |
| 124 | + - Base fork = `libremesh/lime-packages` |
| 125 | + - Base = `master` |
| 126 | + - Head fork = your fork of lime-packages |
| 127 | + - Compare = the branch you wish to merge |
| 128 | + |
| 129 | +4. Add a description of what the change is and click "Create Pull Request". |
| 130 | + |
| 131 | +At this point, it is recommended to notify one of the other developers of the |
| 132 | +pull request and ask them to perform a quick review. They will make any comments |
| 133 | +in the pull request itself, which you should receive as GitHub notifications or as |
| 134 | +emails. |
| 135 | + |
| 136 | +Once the reviewer has OK the pull request, and GitHub has indicated that it can |
| 137 | +be merged automatically, you are free to merge the pull request. |
| 138 | + |
| 139 | +#### Dealing With Conflicts |
| 140 | + |
| 141 | +Sometimes GitHub will report that the Pull Request cannot be merged automatically, |
| 142 | +which usually means that there are merge conflicts. |
| 143 | + |
| 144 | +It is usually a good idea to resolve the conflicts on the branch you are working on, |
| 145 | +rather than doing so on `master`. |
| 146 | + |
| 147 | +In order to do so: |
| 148 | + |
| 149 | +1. Fetch the latest changes from the upstream `master` branch |
| 150 | + |
| 151 | + ```git fetch upstream master``` |
| 152 | + |
| 153 | +2. Make sure that you are on your feature branch. |
| 154 | + |
| 155 | +3. Merge the upstream changes into master. You will see "conflict messages" |
| 156 | + |
| 157 | + ```git merge upstream/master``` |
| 158 | + |
| 159 | +4. Use a merge tool to resolve the conflicts. If one is configured with Git, |
| 160 | + running `git mergetool` should bring it up. Some GUI tools like |
| 161 | + [this](https://git-scm.com/download/gui/linux) have one built in. |
| 162 | + |
| 163 | +5. Ensure that the merge was successful by building and testing the changes. |
| 164 | + |
| 165 | +6. Commit the changes and push to origin. |
| 166 | + |
| 167 | + ```git commit``` |
| 168 | + |
| 169 | + ```git push origin <branch>``` |
| 170 | + |
| 171 | +If you have a Pull Request already pending, GitHub should pick up the recent |
| 172 | +changes and indicate that the PR is ready to be merged. |
| 173 | + |
| 174 | + |
| 175 | +### More Information |
| 176 | + |
| 177 | +For more information, please see [Collaborating on projects using issues and pull requests](https://help.github.com/categories/collaborating-on-projects-using-issues-and-pull-requests/) in the GitHub help guide. |
0 commit comments