Pull Requests and Collaboration — Module Recap

Module 06 is complete. You now have the full pull request workflow — from opening a PR to merging, resolving conflicts, and giving and receiving review feedback.

What you learned

What a pull request is — A proposal to merge one branch into another, with a structured review process on GitHub. Not a Git concept — a GitHub feature built on top of branches. Valuable even for solo developers for self-review, documentation, and portfolio.

Creating a pull request — Push a feature branch, open the PR on GitHub with base main and compare as your branch. Write a description covering what changed, why, and how to verify. Additional commits push to the branch update the PR automatically.

Reviewing and merging — Read diffs on the Files Changed tab. Leave inline comments. Submit reviews as Comment / Approve / Request Changes. Three merge strategies: merge commit (preserves branch history), squash and merge (one clean commit), rebase and merge (linear history). Delete the remote branch after merging; pull locally to sync main.

Merge conflicts in PRs — Appear when main and your branch changed the same lines. Resolve locally by pulling main into your branch, fixing conflict markers, and pushing. Or use GitHub’s web editor for simple conflicts. Keep branches short-lived and pull main frequently to reduce conflicts.

Pull request best practices — Small, focused PRs get reviewed faster and get better feedback. Descriptions answer what, why, and how to verify. Feedback is specific, distinguishes blockers from suggestions, and asks questions before assuming. Self-review your own diff before requesting review.

The complete pull request workflow

1. git switch -c feature/description
2. [make changes, commit]
3. git push -u origin feature/description
4. Open PR on GitHub (base: main, compare: feature/description)
5. Write description: what, why, how to verify
6. Review happens (self or team)
7. Address feedback: push additional commits to the branch
8. Merge (squash and merge for clean history)
9. Delete remote branch on GitHub
10. git switch main && git pull
11. git branch -d feature/description

Command reference

Command	What it does
git switch -c feature/name	Create and switch to feature branch
git push -u origin feature/name	Push branch and set upstream
git pull origin main	Pull main into current branch (conflict resolution)
git switch main && git pull	Sync local main after a merge
git branch -d feature/name	Delete local branch after merge
git branch --merged main	List branches already merged into main

Merge strategy quick reference

Strategy	History	When to use
Merge commit	Preserves branch commits	When intermediate commits are meaningful
Squash and merge	One commit per PR	When branch has WIP/cleanup commits
Rebase and merge	Linear, no merge commit	When team values clean linear history

What’s next — The STO Project on GitHub

Module 07 takes everything from the entire Git Foundations course and applies it to the real STO project you have built throughout this learning path.

You will publish the STO site to GitHub, create a proper repository structure with a README and .gitignore, tag a release, and enable GitHub Pages so the site is live on the web. The STO project becomes your first public portfolio piece.