Skip to main content

Branching and Integration Lab

What This Practice Page Is For​

This lab forces you to branch, merge, rebase, and resolve one real conflict in a controlled environment.

The goal is not speed. The goal is to make branch history legible.

Retrieval Prompts​

  1. Why is creating a branch cheap in Git?
  2. What is the main difference between merge and rebase?
  3. When is rebasing a bad idea?

Compare and Distinguish​

Write one careful paragraph comparing:

  • fast-forward merge
  • merge commit
  • rebase followed by fast-forward merge

Your answer should mention history shape, not just final file content.

Common Mistake Check​

Explain why each move is risky:

  1. Rebasing a branch that teammates already pulled.
  2. Deleting a branch before confirming the work is integrated.
  3. Resolving a merge conflict by choosing a side without reading the actual code.

Mini Application​

Use a throwaway repository and do the full sequence:

  1. create main with one initial commit
  2. create feature-a and make two commits
  3. return to main and make one overlapping commit
  4. rebase feature-a onto main
  5. inspect the graph
  6. create feature-b from main
  7. create a conflicting edit on feature-b
  8. merge feature-b into main and resolve the conflict manually
  9. inspect the graph again

Evidence Check​

You are done only when you can show:

  • one rebased local branch
  • one successful merge
  • one manually resolved conflict
  • one written explanation of why the final history looks the way it does

If You Got Stuck​

Revisit:

Integrated Practice Expansion​

Run this extra pass in a disposable repository before you use rebase on a real project.

  1. Create main with two commits: README.md and notes/git-lab.md.
  2. Create feature/history-cleanup and make three commits: one useful change, one typo fix, and one accidental debug file.
  3. Use interactive rebase to squash the typo fix into the useful change and drop the accidental file commit.
  4. Merge main forward once, then repeat the same exercise by rebasing the unpublished feature branch onto main.
  5. Draw both commit graphs and write which history is easier to review and why.

Evidence check:

  • git log --oneline --graph --decorate --all before and after cleanup
  • one sentence explaining why rewriting unpublished work is acceptable here
  • one sentence explaining why the same operation would be risky after teammates have based work on the old commits