blob: a1ee9fdfaf18a68d4db451c9c154f727793319b4 [file] [log] [blame] [view]
Andrew Top61a84952019-04-30 15:07:33 -07001All the basics that you need to know are documented on this page, but for the
2full GitHub documentation, visit [help.github.com][help].
3
4If you are already an experienced Git/GitHub user, all you need to
5know is that we use the normal GitHub Pull Request workflow for test
6submissions. The only unusual thing is that, to help with code review,
7we ask that you do not amend or otherwise squash your submission as
8you go along, but keep pushing updates as new commits.
9
10If you are a first-time GitHub user, read on for more details of the workflow.
11
12## Setup
13
141. Create a GitHub account if you do not already have one on
15 [github.com][github]
16
172. 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
213. 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
464. (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
52The test repository that you contribute to will depend on the specification
53that you are testing. Currently there are two test repositories, one for CSS
54specification tests and the main W3C repository that contains tests for all
55other 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
63Now that you have Git set up, you will need to fork the test repository. This
64will enable you to [submit][submit] your tests using a pull request (more on this
65[below][submit]).
66
671. 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
732. Click the ![fork][forkbtn] button in the upper right.
74
753. 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
804. After the fork is complete, you're ready to [clone](#clone).
81
82## Clone
83
84If your [fork](#fork) was successful, the next step is to clone (download a copy of the files).
85
86### Clone the test repo
87At 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
118Synchronizing your forked repository with the W3C repository will enable you to
119keep your forked local copy up-to-date with the latest commits in the W3C
120repository.
121
1221. On the command line, navigate to to the directory where your forked copy of
123 the repository is located.
124
1252. 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
1303. 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
1414. 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
154Now 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
157and now want to create another branch, you should always do so from the
158master branch. To do this follow the steps from the beginning of the [previous
159section][remote-upstream]. If you don't start with a clean master
160branch you will end up with a big nested mess._
161
162At the command line:
163
164 $ git checkout -b topic
165
166This will create a branch named `topic` and immediately
167switch this to be your active working branch.
168
169_The branch name should describe specifically what you are testing.
170For Example:_
171
172 $ git checkout -b flexbox-flex-direction-prop
173
174You'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
180Before you submit your tests for review and contribution to the main test
181repo, you'll need to first commit them locally, where you now have your own
182personal version control system with git. In fact, as you are writing your
183tests, you may want to save versions of your work as you go before you submit
184them to be reviewed and merged.
185
1861. 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
1892. 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
1953. 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
2044. Run `git status` again to see what you have on the 'Changes to be
205 committed' list. These files are now 'staged'.
206
2075. Alternatively, you can run `git diff --staged`, which will show you the
208 diff of things to be committed.
209
2106. 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
2157. Repeat these steps as many times as you'd like before you submit.
216
217## Submit
218
219If you're here now looking for more instructions, that means you've written
220some awesome tests and are ready to submit them. Congratulations and welcome
221back!
222
2231. The first thing you do before submitting them to the W3C repo is to push
224them 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
2342. 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
2393. Now create the pull request. There are several ways to create a PR in the
240GitHub 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
2694. Wait for feedback on your pull request and once your pull request is
270accepted, delete your branch (see '
271[When Pull Request is Accepted][cleanup]').
272
273That's it! If you're currently at a Test the Web Forward event, find an
274expert 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
276soon.
277
278## Modify
279
280Once you submit your pull request, a reviewer will check your proposed changes
281for correctness and style. It is likely that this process will lead to some
282comments asking for modifications to your code. When you are ready to make the
283changes, follow these steps:
284
2851. 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
2912. Make the changes needed to address the comments, and commit them just like
292 before.
293
2943. Push the changes to the remote branch containing the pull request:
295
296 $ git push origin topic
297
2984. 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
303Sometimes it takes multiple iterations through a review before the changes are
304finally accepted. Don't worry about this; it's totally normal. The goal of test
305review is to work together to create the best possible set of tests for the web
306platform.
307
308## Cleanup
309Once your pull request has been accepted, you will be notified in the GitHub
310UI and you may get an email. At this point, your changes have been merged
311into the main test repository. You do not need to take any further action
312on the test but you should delete your branch. This can easily be done in
313the GitHub UI by navigating to the pull requests and clicking the
314'Delete Branch' button.
315
316![pull request accepted delete branch][praccepteddelete]
317
318Alternatively, you can delete the branch on the command line.
319
320 $ git push origin --delete <branchName>
321
322## Tips & Tricks
323
324The following workflow is recommended:
325
3261. Start branch based on latest w3c/master
3272. Write tests
3283. Rebase onto latest w3c/master
3294. Submit tests
3305. Stop fiddling with the branch base until review is done
3316. After the PR has been accepted, delete the branch. (Every new PR should
332come from a new branch.)
3337. Synchronize your fork with the W3C repository by fetching your upstream and
334 merging it. (See '[Configure Remote / Upstream][remote-upstream]')
335
336You need to be able to set up remote upstream, etc. Please refer to [Pro Git
337Book][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