> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Demo How to Comment on a Posted Link to a Line or Lines of Code From a File
> Guide to reviewing GitHub pull requests, adding inline and multi line comments, requesting changes, fixing code by avoiding array mutation during iteration, and merging updated commits.
In this lesson you'll learn how to leave inline comments on specific lines (or a contiguous selection of lines) inside a GitHub pull request (PR), review those comments, apply fixes in a follow-up commit, and complete the merge. This walkthrough uses a small game project example where a multi-ball power-up could unintentionally cause exponential growth of the `balls` array.
Open the pull request that needs review. In this example the PR is awaiting review from Alice and Siddharth Barahalikar.
Switch to Alice’s account to perform the review. Alice sees a notification for a requested review; clicking it opens the PR where she can read the description, comments, and examine the Files changed tab. She starts by inspecting the changed code.
Example of the buggy implementation under review (this mutates the array during iteration which may lead to exponential growth):
```javascript theme={null}
// Buggy example: mutates the array while iterating and may cause exponential growth
switch (type) {
case 'multiBall':
if (gameState.balls.length < 5) {
gameState.balls.forEach(ball => {
gameState.balls.push({ ...ball });
});
}
// Add two new balls with slightly different trajectories
gameState.balls.push({ ...gameState.balls[0], dx: gameState.balls[0].dx });
gameState.balls.push({ ...gameState.balls[0], dy: Math.abs(gameState.balls[0].dy) });
gameState.powerups.multiBall.active = true;
gameState.powerups.multiBall.activationTime = currentTime;
break;
}
```
How to add inline comments and multi-line comments
* Click the plus icon to the left of a line to open a small comment box tied to that specific line.
* To comment on multiple contiguous lines, click and drag to select them — the resulting comment will reference the selection.
* Comments can be standalone or grouped into a pending review. Starting a review collects comments until you submit them as a single review action.
Sample inline reviewer comment (added to the PR):\
"This block mutates `gameState.balls` while iterating — that can cause exponential growth. Please avoid mutating the array while iterating and also ensure we cap the total number of balls."
Review workflows and submission options
When you start a review, comments are added as pending on the PR. When submitting the review you choose one of three outcomes:
* Comment — general feedback that does not block merging
* Approve — indicates the PR is ready to merge
* Request changes — prevents merging until required changes are made
In this scenario, Alice requests changes and suggests a safe, non-mutative approach that caps the number of balls. One corrected implementation applied in a follow-up commit looks like this:
```javascript theme={null}
function activatePowerUp(type) {
switch (type) {
case 'multiBall': {
// Only add new balls if we have fewer than 4 (prevents excessive growth)
if (gameState.balls.length < 4) {
// Use a base ball to create new balls, don't mutate during iteration
const base = gameState.balls[0];
gameState.balls.push({ ...base, dx: -base.dx }); // mirrored dx
gameState.balls.push({ ...base, dy: Math.abs(base.dy) }); // ensure positive dy
gameState.powerups.multiBall.active = true;
gameState.powerups.multiBall.activationTime = currentTime;
}
break;
}
default:
break;
}
}
```
Avoid mutating an array while iterating over it (for example, pushing into the same array inside a `forEach`). Instead, collect new items separately or push a known small number of items derived from an existing base element.
After Alice submits a "request changes" review with inline comments, the PR UI reflects that a change was requested. The PR page also provides options to dismiss the review, ask the reviewer to re-check, or see who requested changes.
Author applies the suggested fix locally
Switch back to the author’s account (Siddharth). He reads Alice’s comments and updates the code locally. Typical local workflow to stage, commit, and push the fix to the same PR branch:
```bash theme={null}
# Stage your change
git add path/to/file.js
# Commit with a message that references the issue or describes the change
git commit -m "Ref #1: Prevent exponential ball growth on multi-ball pickup"
# Push the changes to the branch tied to the pull request
git push origin your-branch-name
```
After pushing, the PR automatically includes the new commit(s). Refreshing the PR shows the updated diff and lets reviewers inspect the exact lines that changed.
Review re-check and approval
Once the author pushes the fix, reviewers can reopen the review flow, inspect the new commits, and approve if the changes are satisfactory. In this example Alice inspects the update and submits an approval with a brief message:
```javascript theme={null}
// The updated portion in the PR reflects the new guard and non-mutative additions
switch (type) {
case 'multiBall': {
// Guard to prevent excessive balls
if (gameState.balls.length < 4) {
const base = gameState.balls[0];
// Create new balls from a snapshot of an existing ball — don't iterate and mutate
gameState.balls.push({ ...base, dx: -base.dx });
gameState.balls.push({ ...base, dy: Math.abs(base.dy) });
gameState.powerups.multiBall.active = true;
gameState.powerups.multiBall.activationTime = currentTime;
}
break;
}
default:
break;
}
```
Merging the PR and post-merge actions
After approval the author (or an authorized maintainer) can merge the PR. If the PR or commit references an issue (for example, by including `#1`), GitHub will automatically close that linked issue on merge.
Once merged, the PR displays as merged and closed and the UI offers the option to delete the source branch.
Returning to the linked issue will show it as closed with a reference to the PR that fixed it; the issue timeline includes the PR link and the merge.
If your repository enforces branch protection or requires multiple approvals, make sure you understand those rules before merging. Deleting the source branch is optional—only delete it when you no longer need it for additional work.
Quick reference: review outcomes and what they mean
| Review action | Effect on PR | When to use it |
| --------------- | ------------------------------------- | ---------------------------------------- |
| Comment | Does not block merge | General feedback or discussion |
| Approve | Marks PR as ready to merge | Changes are verified and acceptable |
| Request changes | Blocks merging until changes are made | Required fixes or regressions identified |
Helpful links and references
* [GitHub Pull Requests documentation](https://docs.github.com/en/pull-requests) — official docs for reviewing and merging
* [GitHub Code review guides](https://docs.github.com/en/get-started/using-github/about-code-reviews) — tips for reviewers and authors
Summary
* Use the plus icon to comment on a single line; select multiple lines to create a multi-line comment that references a block of code.
* Start a review to collect multiple inline comments before submitting (you can Comment / Approve / Request changes).
* Avoid mutating arrays while iterating — instead, snapshot an element or collect new items separately and cap additions to prevent exponential growth.
* Push fixes to the same branch; the PR will update automatically so reviewers can re-check and approve before merging.