A Beginner's Guide to Creating a GitHub Pull Request and Getting Code Reviews

Starting out in development, the fastest way to grow is by having others review your code. To get your code reviewed, you'll need to create a Pull Request (PR) on GitHub. Today, we'll walk through the entire process from creating a branch → making a commit → generating a PR → incorporating feedback (modifying commits/rebasing) → merging, making it easy for beginners to follow.

Essentials: What You Need

• Git installed, a GitHub account
• A cloned local repository
• Assuming the default remote branch is main (it might be master depending on your project)

1) Creating a Branch: “Always branch off before you start working”

Working directly on the main branch can make rollbacks difficult and lead to conflicts. It's standard to have one branch per task.

git switch main
git pull origin main
git switch -c feature/add-greeting

Branch names typically reflect the purpose, like feature/, fix/, or refactor/. It makes the PR list easier to navigate later.

2) Code Modification Example: Practice with a Simple Change

For example, let's add a simple greeting function in app.js.

// app.js
export function greet(name) {
  return `Hello, ${name}!`;
}

It's best for each PR to serve one purpose. This makes it easier for reviewers to understand and approve.

3) Commit: “Meaningful changes, clear messages”

Check your changes and commit them.

git status
git add app.js
git commit -m "feat: add greet function"

Commit messages should explain what was done and why. Examples: fix: handle null name in greet, refactor: extract greeting formatter

4) Push Remotely & Create a PR

Push your branch to the remote.

git push -u origin feature/add-greeting

Then create a PR on GitHub. Use the following for the PR title and body:

Example PR Title

• feat: add greet function

Example PR Body Template

• Change: Added greet(name) function
• Test: Verified with a simple local call
• Note: No impact on existing code The reviewer should be able to understand the situation just by reading the PR body.

5) Receiving a Code Review: Common Feedback Patterns

Here are three typical comments you might receive:

1. Naming/Readability: Function names, variable names, comment placement
2. Exception Handling: Null/empty strings, type assumptions
3. Structure Improvements: Eliminating redundancy, separating responsibilities For example, you might get asked, “What happens if the name is empty?”

6) Incorporating Review Feedback: Update with a Fix Commit

Adjust your code to meet the feedback, and commit on the same branch to automatically update the PR.

// app.js
export function greet(name) {
  const safeName = (name ?? "").trim();
  if (!safeName) return "Hello!";
  return `Hello, ${safeName}!`;
}

git add app.js
git commit -m "fix: handle empty name in greet"
git push

Respond to review comments like this:

• “Implemented the requested changes. Empty strings/spaces default to a generic greeting.” Important: Don't just say “implemented”, also explain how you implemented the changes for higher credibility.

7) Final Checks Before Merging

Before approval, check the following:

Have any unnecessary files (build artifacts, logs) been committed?

Do the changes align with the PR's purpose?

Are there potential conflicts? (If needed, update your branch with the latest main)

To update your branch with the latest main:

git switch main
git pull origin main
git switch feature/add-greeting
git merge main

If conflicts arise, resolve them directly in the files, commit, and push.

8) After Merging: Clean Up the Branch

After merging, tidy up by removing the branch (recommended but optional).

git switch main
git pull origin main
git branch -d feature/add-greeting

You can delete the remote branch on GitHub through the interface or by command.

Conclusion: PRs Are “Conversations,” Not “Submissions”

Creating and reviewing PRs is not merely an approval process but rather a training ground for aligning team code quality and improving development habits. It’s normal to receive many comments initially. The key is to avoid defensiveness, reproduce the issue, fix it, and explain your changes. Mastering this cycle accelerates your growth in software development.