@@ -243,18 +243,85 @@ If in doubt, you can always ask for guidance in the Pull Request or on
243
243
[ IRC in the #node-dev channel] ( https://webchat.freenode.net?channels=node-dev&uio=d4 ) .
244
244
245
245
Feel free to post a comment in the Pull Request to ping reviewers if you are
246
- awaiting an answer on something.
246
+ awaiting an answer on something. If you encounter words or acronyms that
247
+ seem unfamiliar, check out this
248
+ [ glossary] ( https://sites.google.com/a/chromium.org/dev/glossary ) .
247
249
250
+ Note that multiple commits often get squashed when they are landed (see the
251
+ notes about [ commit squashing] ( #commit-squashing ) ).
248
252
249
253
### Step 8: Landing
250
254
251
- Once your Pull Request has been reviewed and approved by at least one Node.js
252
- Collaborators (often by saying LGTM, or Looks Good To Me), and as long as
253
- there is consensus (no objections from a Collaborator), a
254
- Collaborator can merge the Pull Request . GitHub often shows the Pull Request as
255
- ` Closed ` at this point, but don't worry. If you look at the branch you raised
256
- your Pull Request against (probably ` master ` ), you should see a commit with
257
- your name on it. Congratulations and thanks for your contribution!
255
+ In order to get landed, a Pull Request needs to be reviewed and
256
+ [ approved] ( #getting-approvals-for-your-pull-request ) by
257
+ at least one Node.js Collaborator and pass a
258
+ [ CI (Continuous Integration) test run] ( #ci-testing ) .
259
+ After that, as long as there are no objections
260
+ from a Collaborator, the Pull Request can be merged. If you find your
261
+ Pull Request waiting longer than you expect, see the
262
+ [ notes about the waiting time] ( #waiting-until-the-pull-request-gets-landed ) .
263
+
264
+ When a collaborator lands your Pull Request, they will post
265
+ a comment to the Pull Request page mentioning the commit(s) it
266
+ landed as. GitHub often shows the Pull Request as ` Closed ` at this
267
+ point, but don't worry. If you look at the branch you raised your
268
+ Pull Request against (probably ` master ` ), you should see a commit with
269
+ your name on it. Congratulations and thanks for your contribution!
270
+
271
+ ## Additional Notes
272
+
273
+ ### Commit Squashing
274
+
275
+ When the commits in your Pull Request get landed, they will be squashed
276
+ into one commit per logical change, with metadata added to the commit
277
+ message (including links to the Pull Request, links to relevant issues,
278
+ and the names of the reviewers). The commit history of your Pull Request,
279
+ however, will stay intact on the Pull Request page.
280
+
281
+ For the size of "one logical change",
282
+ [ 0b5191f] ( https://github.com/nodejs/node/commit/0b5191f15d0f311c804d542b67e2e922d98834f8 )
283
+ can be a good example. It touches the implementation, the documentation,
284
+ and the tests, but is still one logical change. In general, the tests should
285
+ always pass when each individual commit lands on the master branch.
286
+
287
+ ### Getting Approvals for Your Pull Request
288
+
289
+ A Pull Request is approved either by saying LGTM, which stands for
290
+ "Looks Good To Me", or by using GitHub's Approve button.
291
+ GitHub's Pull Request review feature can be used during the process.
292
+ For more information, check out
293
+ [ the video tutorial] ( https://www.youtube.com/watch?v=HW0RPaJqm4g )
294
+ or [ the official documentation] ( https://help.github.com/articles/reviewing-changes-in-pull-requests/ ) .
295
+
296
+ After you push new changes to your branch, you need to get
297
+ approval for these new changes again, even if GitHub shows "Approved"
298
+ because the reviewers have hit the buttons before.
299
+
300
+ ### CI Testing
301
+
302
+ Every Pull Request needs to be tested
303
+ to make sure that it works on the platforms that Node.js
304
+ supports. This is done by running the code through the CI system.
305
+
306
+ Only a Collaborator can request a CI run. Usually one of them will do it
307
+ for you as approvals for the Pull Request come in.
308
+ If not, you can ask a Collaborator to request a CI run.
309
+
310
+ ### Waiting Until the Pull Request Gets Landed
311
+
312
+ A Pull Request needs to stay open for at least 48 hours (72 hours on a
313
+ weekend) from when it is submitted, even after it gets approved and
314
+ passes the CI. This is to make sure that everyone has a chance to
315
+ weigh in. If the changes are trivial, collaborators may decide it
316
+ doesn't need to wait. A Pull Request may well take longer to be
317
+ merged in. All these precautions are important because Node.js is
318
+ widely used, so don't be discouraged!
319
+
320
+ ### Check Out the Collaborator's Guide
321
+
322
+ If you want to know more about the code review and the landing process,
323
+ you can take a look at the
324
+ [ collaborator's guide] ( https://github.com/nodejs/node/blob/master/COLLABORATOR_GUIDE.md ) .
258
325
259
326
<a id =" developers-certificate-of-origin " ></a >
260
327
## Developer's Certificate of Origin 1.1
0 commit comments