Git basics: branches, merges, and pull requests
Git tracks snapshots of your project over time. A branch is a movable pointer to a commit. Merging combines histories (often after review). A pull request (or merge request) is the social layer: discuss diff, run CI, then integrate. This lesson connects the mental model to everyday commands.
Widgets in this lesson: git-graph shows real topology—use it to see why merge conflicts happen at the join. Pipeline is the path of bytes from your editor to the shared remote. Code explorer annotates commands you will type daily. Comparison table explains merge vs rebase trade-offs. Tabbed code holds recipes for sync and recovery.
Visual: feature branch and merge commit
Before commands, stare at the graph: main moved from c1 → c2, then feature/login added c3 on top of c2. Merging brought c3 into main as c4. If two people edited the same lines since c2, Git would pause at the merge with a conflict marker—your job is to produce the correct combined file.
Each dot is a commit; lanes are branches. Click commits: c4 (merge) has two parents—c3 from feature and c2 from main. That is how Git records that two lines of history joined.
GIT GRAPH · 2 branches · 4 commits
Git graph
Click a commit to see details
main
feature/login
4 commits · 2 branches · click a commit to inspect
From working tree to remote
Your files live in the working directory. `git add` stages a snapshot into the index (staging). `git commit` records that snapshot in the local repository. `git push` sends commits to a remote (e.g. origin) so teammates can pull them.
Pipeline steps: Edit is uncommitted chaos—only you see it. Staging is the preview of the next commit (`git diff --cached`). Commit freezes history locally (offline). Push publishes; until then, backups and CI do not see your work. PR adds review + automated checks before the merge commit lands on main.
Click each step: this mirrors what happens on your disk vs on the server. If CI fails after push, fix and amend or add commits on the same branch—PR updates automatically.
📝
Edit
uncommitted files
→
➕
git add
staging / index
→
📌
git commit
local DAG of commits
→
☁️
git push
origin (remote)
→
🔀
PR / review
CI gates + merge
Anatomy of common commands
Code explorer: each line is a teaching moment—click through in order. Prefer `git switch` for branch changes on newer Git; `checkout` still appears in older docs.
Read explanations right of each command—they map to the pipeline above (branch → stage → commit → push).
bash
1
git checkout -b feature/login
▼
2
# edit files, then:
▼
3
git status
▼
4
git diff
▼
5
git add -p
▼
6
git commit -m "feat: login form"
▼
7
git push -u origin feature/login
▼
Merge vs rebase (when you are ready)
Both integrate your feature with main. Merge adds a merge commit (like c4 in the graph). Rebase replays your commits as new commits on top of main—history looks linear but rewrites SHAs. Never rebase public branches that teammates have based work on.
Use this table when choosing integrate strategy in PR settings or locally—merge preserves truth, rebase beautifies narrative.
| Merge | Rebase | |
|---|---|---|
| History graph | Keeps fork + merge bubble—shows parallel work honestly | Linear sequence: feature commits appear after latest main—easier git log --oneline |
| Collaboration | Safe when multiple people touch the same branch—no history rewrite | Dangerous if others pulled your old SHAs—coordinate or avoid |
| Conflict resolution | One merge conflict resolution at merge time | Potentially one conflict per replayed commit—more granular but tedious |
| Typical use | Default GitHub/GitLab “Create merge commit” | git pull --rebase before push; interactive rebase to squash fixups |
Pull request checklist
Before you ask for review
Small PRs merge faster and catch bugs earlier. CI should be green; include what you tested manually.
Describe intent in the PR title/body—not only the diff.
Link issue/ticket; mention risk areas (auth, payments, migrations).
If CI fails, fix or explain—do not rely on reviewers to debug pipeline.
Update feature branch from main
bash
git fetch origin
git checkout feature/login
git merge origin/main
# or: git rebase origin/mainℹ️Practice: create a test repo on GitHub/GitLab, open two clones, simulate two developers, and resolve a deliberate merge conflict—nothing teaches Git like real conflict resolution.