GitHub and Pull Requests

Introduction

GitHub (and GitLab, Gitee) host Git remotes and add collaboration tools: Pull Requests (PRs), code review, Issues, and CI checks. This chapter walks from creating a remote repo through branch, push, opening a PR, and merging— the workflow most teams use daily.

Prerequisites

Remote Repositories
GitHub account (GitLab/Gitee steps are similar)
Local repo linked to origin

Create a Remote Repository

On GitHub:

New repository → name my-app
Choose Public or Private
Optional: add README, .gitignore template, License
Create

Warning

Empty Remote vs Existing Local

If local repo already has commits, do not add README on GitHub unless you plan to merge unrelated histories. Prefer empty remote + git push -u origin main.

If platform created README, pull first:

bash

git pull origin main --allow-unrelated-histories

Then push your work.

Push a Feature Branch

bash

git switch main
git pull
git switch -c feature/add-search

Implement change:

bash

echo "export function search() {}" > search.js
git add search.js
git commit -m "Add search module stub"
git push -u origin feature/add-search

Open a Pull Request

On GitHub:

Repository page shows Compare & pull request banner
Base: main ← Compare: feature/add-search
Title: imperative summary—Add search module stub
Description: what, why, how to test

Good PR body template:

markdown

## Summary
- Add initial search.js export for upcoming API
 
## Test plan
- [ ] File exists and imports in Node without error
- [ ] No breaking changes to existing routes

Create PR.

Code Review Workflow

Reviewers comment on lines or files. Author pushes fixes to same branch:

bash

git add search.js
git commit -m "Address review: export named function"
git push

PR updates automatically—no new PR needed.

Code explanation:

PR tracks branch tip, not a single commit

Merge Options on GitHub

Button	Result
Merge commit	Preserves all commits + merge commit
Squash and merge	One commit on `main`
Rebase and merge	Linear replay on `main`

Team policy picks one—beginners often use merge commit or squash.

After merge, update local:

bash

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

Issues and Commits

Link work to tracking:

bash

git commit -m "Fix null email validation
 
Fixes #42"

Code explanation:

Fixes #42 closes Issue #42 when PR merges (GitHub keyword)

Use Issues for bugs and features; reference #number in PR description.

Fork Workflow (Preview)

Contributing to someone else’s repo:

Fork on GitHub (copy under your account)
Clone your fork
Branch → commit → push → PR to upstream

Full walkthrough in Fork an Open Source Project.

GitLab / Gitee Notes

Platform	PR name
GitHub	Pull Request
GitLab	Merge Request (MR)
Gitee	Pull Request

Commands (push, fetch) stay the same—only UI labels differ.

FAQ

PR shows conflicts?

Merge or rebase main into feature branch locally, fix conflicts, push.

Draft PR?

Mark Draft until ready for review—reduces noise.

Who can merge?

Repo settings—often require review + CI pass (chapter 22).

Delete branch after merge?

GitHub offers checkbox—keeps remote tidy.

PR too large?

Split into smaller PRs—easier review, fewer conflicts.

License on new repo?

Add MIT/Apache/etc. early for open source clarity.