Creating a GitHub Pull Request for Beginners: From Branching to Merging

What is a Pull Request and Why Do You Need It?

A Pull Request (PR) is a request to merge your changes into a branch. Using PRs offers several benefits:

• Easily compare changes (view added/removed lines)
• Exchange review comments directly beside the code
• Reduce the risk of damaging the main branch by mistake

Pre-Setup: Key Terms You Should Know

• main/master: The stable branch ready for deployment
• feature branch: Your dedicated working branch (e.g., feature/login)
• upstream / origin: Differentiates between the original repository and your fork (varies by team)

1) Creating a Branch (An Essential Habit)

First, pull the latest main and create a new branch from it.

git checkout main
git pull origin main
git checkout -b feature/login

Branch names should clearly reflect their purpose like feature/feature-name, fix/bug, or refactor/cleanup. This clarity aids collaboration.

2) Commit Code Changes: "Small and Meaningful"

Make your updates and check changed files:

git status
git diff

Stage and commit your changes:

git add .
git commit -m "feat: Add login form validation"

If your team doesn't have specific commit message rules, ensure it at least reflects what you did (verb + target). Example: fix: Correct password length validation issue

3) Push to Remote Branch and Create PR

Set upstream if this is the first push:

git push -u origin feature/login

Now, you can use the Compare & pull request button or start a new PR in the Pull Requests tab on GitHub.

Tips for Writing a PR (Catch the Reviewer’s Eye)

• Title: Clearly state the work's purpose Example: Add validation for login inputs
• Body (example template): Key takeaway: Provide step-by-step "Testing Instructions" so reviewers can replicate the changes, speeding up the review process.

4) Getting Code Reviewed: Handling Comments

When receiving review comments, stay calm and understand the feedback's intent.

• Simple change request: Implement and commit
• Needs discussion: Explain your reasoning and offer alternatives Commit changes to the same branch; they’ll automatically reflect in the PR.

git add .
git commit -m "refactor: Separate validation functions"
git push

Organize review comments on GitHub with Resolve conversation to signal completion.

5) Merging Without Conflicts: Syncing with Latest Main

If the main updates during review, sync your branch with the latest changes.

Method A) Merging (Safe for Beginners)

git checkout feature/login
git fetch origin
git merge origin/main

Resolve any conflicts in the files as marked by Git, then commit.

Method B) Rebasing (Keeps History Clean, Requires Team Agreement)

If your team prefers rebasing, proceed if comfortable, or ask first.

6) Choosing a Merge Method: Squash / Merge / Rebase

Once the PR is approved, it’s time to merge. Depending on your repo settings, different options may be available:

• Squash and merge: Combines all commits into one (commonly used)
• Create a merge commit: Maintains a clear history
• Rebase and merge: Provides a linear history (depends on team rules) For beginners, following your team's standard practice is advised.

Conclusion: Three Common Beginner Mistakes

1. Working directly on main – Always use a feature branch
2. Submitting a PR without explanation – Include change details and testing instructions
3. Taking review comments personally – Focus on improving code quality together Once you master this process, PRs can become part of your “safe collaboration routine” instead of a daunting procedure. In your next PR, just by clearly stating a title and testing steps, reviews can become much smoother.