Andrew Top | 61a8495 | 2019-04-30 15:07:33 -0700 | [diff] [blame] | 1 | All the basics that you need to know are documented on this page, but for the |
| 2 | full GitHub documentation, visit [help.github.com][help]. |
| 3 | |
| 4 | If you are already an experienced Git/GitHub user, all you need to |
| 5 | know is that we use the normal GitHub Pull Request workflow for test |
| 6 | submissions. The only unusual thing is that, to help with code review, |
| 7 | we ask that you do not amend or otherwise squash your submission as |
| 8 | you go along, but keep pushing updates as new commits. |
| 9 | |
| 10 | If you are a first-time GitHub user, read on for more details of the workflow. |
| 11 | |
| 12 | ## Setup |
| 13 | |
| 14 | 1. Create a GitHub account if you do not already have one on |
| 15 | [github.com][github] |
| 16 | |
| 17 | 2. Download and install the latest version of Git: |
| 18 | [http://git-scm.com/downloads][git]. Please refer to the instruction there |
| 19 | for different platforms. |
| 20 | |
| 21 | 3. Configure your settings so your commits are properly labeled: |
| 22 | |
| 23 | On Mac or Linux or Solaris, open the Terminal. |
| 24 | |
| 25 | On Windows, open Git Bash (From the Start Menu > Git > Git Bash). |
| 26 | |
| 27 | At the prompt, type: |
| 28 | |
| 29 | $ git config --global user.name "Your Name" |
| 30 | |
| 31 | _This will be the name that is displayed with your test submissions_ |
| 32 | |
| 33 | Next, type: |
| 34 | |
| 35 | $ git config --global user.email "your_email@address.com" |
| 36 | |
| 37 | _This should be the email address you used to create the account in Step 1._ |
| 38 | |
| 39 | Next, type: |
| 40 | |
| 41 | $ git config --global push.default upstream |
| 42 | |
| 43 | This ensures that git push will never unintentionally create or update |
| 44 | a remote branch. |
| 45 | |
| 46 | 4. (Optional) If you don't want to enter your username and password every |
| 47 | time you talk to the remote server, you'll need to set up password caching. |
| 48 | See [Caching your GitHub password in Git][password-caching]. |
| 49 | |
| 50 | ## Test Repositories |
| 51 | |
| 52 | The test repository that you contribute to will depend on the specification |
| 53 | that you are testing. Currently there are two test repositories, one for CSS |
| 54 | specification tests and the main W3C repository that contains tests for all |
| 55 | other specificatons: |
| 56 | |
| 57 | **Main W3C test repository**: [github.com/w3c/web-platform-tests][main-repo] |
| 58 | |
| 59 | **CSS specification test repository**: [github.com/w3c/csswg-test][css-repo] |
| 60 | |
| 61 | ## Fork |
| 62 | |
| 63 | Now that you have Git set up, you will need to fork the test repository. This |
| 64 | will enable you to [submit][submit] your tests using a pull request (more on this |
| 65 | [below][submit]). |
| 66 | |
| 67 | 1. In the browser, go the the GitHub page for the test repository: |
| 68 | |
| 69 | CSS test repository: [github.com/w3c/csswg-test][css-repo] |
| 70 | |
| 71 | Main W3C test repository: [github.com/w3c/web-platform-tests][main-repo] |
| 72 | |
| 73 | 2. Click the ![fork][forkbtn] button in the upper right. |
| 74 | |
| 75 | 3. The fork will take several seconds, then you will be redirected to your |
| 76 | GitHub page for this forked repository. If you forked the HTML test repo |
| 77 | (for example), you will now be at |
| 78 | **https://github.com/username/web-platform-tests**. |
| 79 | |
| 80 | 4. After the fork is complete, you're ready to [clone](#clone). |
| 81 | |
| 82 | ## Clone |
| 83 | |
| 84 | If your [fork](#fork) was successful, the next step is to clone (download a copy of the files). |
| 85 | |
| 86 | ### Clone the test repo |
| 87 | At the command prompt, cd into the directory where you want to keep the tests. |
| 88 | |
| 89 | * If you forked the W3C Web Platform tests: |
| 90 | |
| 91 | $ git clone --recursive https://github.com/username/web-platform-tests.git |
| 92 | |
| 93 | If you forked the CSS tests: |
| 94 | |
| 95 | $ git clone --recursive https://github.com/username/csswg-test.git |
| 96 | |
| 97 | _This will download the tests into a directory named for the repo:_ |
| 98 | `./web-platform-tests` _or_ `./csswg-test`. |
| 99 | |
| 100 | * You should now have a full copy of the test repository on your local |
| 101 | machine. Feel free to browse the directories on your hard drive. You can also |
| 102 | browse them on [github.com][github-w3c] and see the full history of contributions |
| 103 | there. |
| 104 | |
| 105 | ### Clone the submodules |
| 106 | |
| 107 | * If you cloned the test repo and used the `--recursive` option, you'll find its submodules in `[repo-root]/resources/`. |
| 108 | |
| 109 | * If you cloned the the test repo and did not use the `--recursive` option, you will likely have an empty `resources` directory at the root of your cloned repo. You can clone the submodules with these additional steps: |
| 110 | |
| 111 | $ cd test-repo-root |
| 112 | $ git submodule update --init --recursive |
| 113 | |
| 114 | _You should now see the submodules in the repository. For example,_ `testharness` _files in should be in the resources directory._ |
| 115 | |
| 116 | |
| 117 | ## Configure Remote / Upstream |
| 118 | Synchronizing your forked repository with the W3C repository will enable you to |
| 119 | keep your forked local copy up-to-date with the latest commits in the W3C |
| 120 | repository. |
| 121 | |
| 122 | 1. On the command line, navigate to to the directory where your forked copy of |
| 123 | the repository is located. |
| 124 | |
| 125 | 2. Make sure that you are on the master branch. This will be the case if you |
| 126 | just forked, otherwise switch to master. |
| 127 | |
| 128 | $ git checkout master |
| 129 | |
| 130 | 3. Next, add the remote of the repository your forked. This assigns the |
| 131 | original repository to a remote called "upstream" |
| 132 | |
| 133 | If you forked the [Web Platform Tests repository][main-repo]: |
| 134 | |
| 135 | $ git remote add upstream https://github.com/w3c/web-platform-tests.git |
| 136 | |
| 137 | If you forked the [CSSWG-test repository][css-repo]: |
| 138 | |
| 139 | $ git remote add upstream https://github.com/w3c/csswg-test.git |
| 140 | |
| 141 | 4. To pull in changes in the original repository that are not present in your |
| 142 | local repository first fetch them: |
| 143 | |
| 144 | $ git fetch upstream |
| 145 | |
| 146 | Then merge them into your local repository: |
| 147 | |
| 148 | $ git merge upstream/master |
| 149 | |
| 150 | For additional information, please see the [GitHub docs][github-fork-docs]. |
| 151 | |
| 152 | ## Branch |
| 153 | |
| 154 | Now that you have everything locally, create a branch for your tests. |
| 155 | |
| 156 | _Note: If you have already been through these steps and created a branch |
| 157 | and now want to create another branch, you should always do so from the |
| 158 | master branch. To do this follow the steps from the beginning of the [previous |
| 159 | section][remote-upstream]. If you don't start with a clean master |
| 160 | branch you will end up with a big nested mess._ |
| 161 | |
| 162 | At the command line: |
| 163 | |
| 164 | $ git checkout -b topic |
| 165 | |
| 166 | This will create a branch named `topic` and immediately |
| 167 | switch this to be your active working branch. |
| 168 | |
| 169 | _The branch name should describe specifically what you are testing. |
| 170 | For Example:_ |
| 171 | |
| 172 | $ git checkout -b flexbox-flex-direction-prop |
| 173 | |
| 174 | You're ready to start writing tests! Come back to this page you're ready to |
| 175 | [commit][commit] them or [submit][submit] them for review. |
| 176 | |
| 177 | |
| 178 | ## Commit |
| 179 | |
| 180 | Before you submit your tests for review and contribution to the main test |
| 181 | repo, you'll need to first commit them locally, where you now have your own |
| 182 | personal version control system with git. In fact, as you are writing your |
| 183 | tests, you may want to save versions of your work as you go before you submit |
| 184 | them to be reviewed and merged. |
| 185 | |
| 186 | 1. When you're ready to save a version of your work, go to the command |
| 187 | prompt and cd to the directory where your files are. |
| 188 | |
| 189 | 2. First, ask git what new or modified files you have: |
| 190 | |
| 191 | $ git status |
| 192 | |
| 193 | _This will show you files that have been added or modified_. |
| 194 | |
| 195 | 3. For all new or modified files, you need to tell git to add them to the |
| 196 | list of things you'd like to commit: |
| 197 | |
| 198 | $ git add [file1] [file2] ... [fileN] |
| 199 | |
| 200 | Or: |
| 201 | |
| 202 | $ git add [directory_of_files] |
| 203 | |
| 204 | 4. Run `git status` again to see what you have on the 'Changes to be |
| 205 | committed' list. These files are now 'staged'. |
| 206 | |
| 207 | 5. Alternatively, you can run `git diff --staged`, which will show you the |
| 208 | diff of things to be committed. |
| 209 | |
| 210 | 6. Once you've added everything, you can commit and add a message to this |
| 211 | set of changes: |
| 212 | |
| 213 | $ git commit -m "Tests for indexed getters in the HTMLExampleInterface" |
| 214 | |
| 215 | 7. Repeat these steps as many times as you'd like before you submit. |
| 216 | |
| 217 | ## Submit |
| 218 | |
| 219 | If you're here now looking for more instructions, that means you've written |
| 220 | some awesome tests and are ready to submit them. Congratulations and welcome |
| 221 | back! |
| 222 | |
| 223 | 1. The first thing you do before submitting them to the W3C repo is to push |
| 224 | them back up to the server: |
| 225 | |
| 226 | $ git push origin topic |
| 227 | |
| 228 | _Note: Here,_ `origin` _refers to remote repo from which you cloned |
| 229 | (downloaded) the files after you forked, referred to as |
| 230 | web-platform-tests.git in the previous example;_ |
| 231 | `topic` _refers to the name of your local branch that |
| 232 | you want to push_. |
| 233 | |
| 234 | 2. Now you can send a message that you have changes or additions you'd like |
| 235 | to be reviewed and merged into the main (original) test repository. You do |
| 236 | this by using a pull request. In a browser, open the GitHub page for your |
| 237 | forked repository: **https://github.com/username/web-platform-tests**. |
| 238 | |
| 239 | 3. Now create the pull request. There are several ways to create a PR in the |
| 240 | GitHub UI. Below is one method and others can be found on |
| 241 | [GitHub.com][github-createpr] |
| 242 | |
| 243 | a. Click the ![pull request link][pullrequestlink] link on the right side |
| 244 | of the UI, then click the ![new pull request][pullrequestbtn] button. |
| 245 | |
| 246 | b. On the left, you should see the base repo is the |
| 247 | w3c/web-platform-tests. On the right, you should see your fork of that |
| 248 | repo. In the branch menu of your forked repo, switch to |
| 249 | `topic` |
| 250 | **Note:** If you see _'There isn't anything to compare'_, click the |
| 251 | ![edit][editbtn] button and make sure your fork and your |
| 252 | `topic` branch is selected on the right side. |
| 253 | |
| 254 | c. Select the ![create pull request][createprlink] link at the top. |
| 255 | |
| 256 | d. Scroll down and review the diff |
| 257 | |
| 258 | e. Scroll back up and in the Title field, enter a brief description for |
| 259 | your submission. |
| 260 | |
| 261 | Example: "Tests for CSS Transforms skew() function." |
| 262 | |
| 263 | f. If you'd like to add more detailed comments, use the comment field |
| 264 | below. |
| 265 | |
| 266 | g. Click ![the send pull request button][sendpullrequest] |
| 267 | |
| 268 | |
| 269 | 4. Wait for feedback on your pull request and once your pull request is |
| 270 | accepted, delete your branch (see ' |
| 271 | [When Pull Request is Accepted][cleanup]'). |
| 272 | |
| 273 | That's it! If you're currently at a Test the Web Forward event, find an |
| 274 | expert nearby and ask for a review. If you're doing this on your own |
| 275 | (AWESOME!), your pull request will go into a queue and will be reviewed |
| 276 | soon. |
| 277 | |
| 278 | ## Modify |
| 279 | |
| 280 | Once you submit your pull request, a reviewer will check your proposed changes |
| 281 | for correctness and style. It is likely that this process will lead to some |
| 282 | comments asking for modifications to your code. When you are ready to make the |
| 283 | changes, follow these steps: |
| 284 | |
| 285 | 1. Check out the branch corresponding to your changes e.g. if your branch was |
| 286 | called `topic` |
| 287 | run: |
| 288 | |
| 289 | $ git checkout topic |
| 290 | |
| 291 | 2. Make the changes needed to address the comments, and commit them just like |
| 292 | before. |
| 293 | |
| 294 | 3. Push the changes to the remote branch containing the pull request: |
| 295 | |
| 296 | $ git push origin topic |
| 297 | |
| 298 | 4. The pull request will automatically be updated with the new commit. Note |
| 299 | for advanced users: it is generally discouraged to rebase your pull request |
| 300 | before review is complete. Tests typically have few conflicts so this |
| 301 | should not be a problem in the common case. |
| 302 | |
| 303 | Sometimes it takes multiple iterations through a review before the changes are |
| 304 | finally accepted. Don't worry about this; it's totally normal. The goal of test |
| 305 | review is to work together to create the best possible set of tests for the web |
| 306 | platform. |
| 307 | |
| 308 | ## Cleanup |
| 309 | Once your pull request has been accepted, you will be notified in the GitHub |
| 310 | UI and you may get an email. At this point, your changes have been merged |
| 311 | into the main test repository. You do not need to take any further action |
| 312 | on the test but you should delete your branch. This can easily be done in |
| 313 | the GitHub UI by navigating to the pull requests and clicking the |
| 314 | 'Delete Branch' button. |
| 315 | |
| 316 | ![pull request accepted delete branch][praccepteddelete] |
| 317 | |
| 318 | Alternatively, you can delete the branch on the command line. |
| 319 | |
| 320 | $ git push origin --delete <branchName> |
| 321 | |
| 322 | ## Tips & Tricks |
| 323 | |
| 324 | The following workflow is recommended: |
| 325 | |
| 326 | 1. Start branch based on latest w3c/master |
| 327 | 2. Write tests |
| 328 | 3. Rebase onto latest w3c/master |
| 329 | 4. Submit tests |
| 330 | 5. Stop fiddling with the branch base until review is done |
| 331 | 6. After the PR has been accepted, delete the branch. (Every new PR should |
| 332 | come from a new branch.) |
| 333 | 7. Synchronize your fork with the W3C repository by fetching your upstream and |
| 334 | merging it. (See '[Configure Remote / Upstream][remote-upstream]') |
| 335 | |
| 336 | You need to be able to set up remote upstream, etc. Please refer to [Pro Git |
| 337 | Book][git-book] and enjoy reading. |
| 338 | |
| 339 | [branch]: #branch |
| 340 | [commit]: #commit |
| 341 | [clone]: #clone |
| 342 | [css-repo]: https://github.com/w3c/csswg-test |
| 343 | [forkbtn]: /assets/forkbtn.png |
| 344 | [git]: http://git-scm.com/downloads |
| 345 | [git-book]: http://git-scm.com/book |
| 346 | [github]: https://github.com/ |
| 347 | [github-w3c]: https://github.com/w3c |
| 348 | [github-fork-docs]: https://help.github.com/articles/fork-a-repo |
| 349 | [github-createpr]: https://help.github.com/articles/creating-a-pull-request |
| 350 | [help]: https://help.github.com/ |
| 351 | [main-repo]: https://github.com/w3c/web-platform-tests |
| 352 | [password-caching]: https://help.github.com/articles/caching-your-github-password-in-git |
| 353 | [pullrequestlink]: /assets/pullrequestlink.png |
| 354 | [pullrequestbtn]: /assets/pullrequestbtn.png |
| 355 | [editbtn]: /assets/editbtn.png |
| 356 | [createprlink]: /assets/createprlink.png |
| 357 | [sendpullrequest]: /assets/sendpullrequest.png |
| 358 | [praccepteddelete]: /assets/praccepteddelete.png |
| 359 | [submit]: #submit |
| 360 | [remote-upstream]: #configure-remote-upstream |
| 361 | [cleanup]: #cleanup |