Branches, Merging & Pull Requests

Required tools

• Git (2.x or newer)
• A terminal (or Git Bash on Windows) (any current version)

Setup

1. Open a terminal.
2. Create a fresh practice repository: `mkdir git-branching-practice && cd git-branching-practice && git init`.
3. Make one commit on main so there's a starting point to branch from: `echo "# Branching Practice" > README.md && git add README.md && git commit -m "Initial commit"`.

Project structure

git-branching-practice/
  .git/
  README.md
  nav.md         (added on the feature branch)

Starter files

TODO: create this yourself with the setup command above.

Requirements

• A branch named feature/nav-bar exists, created from main.
• At least two commits exist on feature/nav-bar that do not exist on main.
• feature/nav-bar is merged back into main.
• `git log --oneline --graph --all` shows both the branch point and the merge.

Commands to run

• Create and switch to a new branch in one step

  git checkout -b feature/nav-bar

• Add a new file for the feature

  printf "- Home\n- About\n" > nav.md

• Stage and commit it

  git add nav.md && git commit -m "Add nav-bar markup"

• Make a second commit on the same branch

  printf "- Contact\n" >> nav.md && git add nav.md && git commit -m "Add Contact link to nav-bar"

• Switch back to main

  git checkout main

• Merge the feature branch into main

  git merge feature/nav-bar

• View the branch and merge in the commit graph

  git log --oneline --graph --all

• Delete the now-merged branch (safe: git refuses if it isn't fully merged)

  git branch -d feature/nav-bar

Expected behavior

Because nothing changed on main while feature/nav-bar was being worked on, `git merge feature/nav-bar` performs a fast-forward: main's pointer simply moves forward to the branch's latest commit, with no separate merge commit. `git log --oneline --graph --all` shows a single straight line of commits, not a diverging-then-rejoining shape -- that straight line is exactly what a fast-forward merge looks like.

Verify it yourself

• git branch

  Expected: lists only 'main' (feature/nav-bar was deleted in the last command, since it was safely merged first)

• cat nav.md

  Expected: prints all three lines (Home, About, Contact) -- confirming both feature-branch commits are now part of main

• git log --oneline

  Expected: shows all commits from both the initial commit and the two feature-branch commits, in one combined history

Troubleshooting

• `error: branch 'feature/nav-bar' is not fully merged` — This means `git branch -d` correctly refused to delete a branch with unmerged work -- go back and confirm `git merge feature/nav-bar` actually completed successfully first.
• `git merge` opens a text editor for a merge commit message — This only happens for a real (non-fast-forward) merge, which needs a message describing the merge itself -- save and close the editor to accept the default message, exactly like `git commit` without -m.
• Merge conflict markers (<<<<<<<, =======, >>>>>>>) appear in a file — This lab is designed to avoid a real conflict, but if you experiment further and hit one: open the file, manually keep the correct lines, delete the marker lines themselves, then `git add` the file and `git commit` to complete the merge -- never force through a conflict without reading what both sides changed.

Extension challenge

Before merging, make a NEW commit directly on main (e.g. edit README.md and commit it) so main and feature/nav-bar have both diverged -- then merge feature/nav-bar and compare: this time Git creates a real merge commit with two parents, and `git log --graph` shows the branches actually diverging and rejoining instead of one straight line.