Git & Version Control Branching and Merging Flashcards

24 sample cards from the Branching and Merging deck

Sampled from the end of the deck, so these are different cards from the ones shown on the syllabus page.

1. What do the conflict markers <<<<<<<, =======, and >>>>>>> delimit?

   <<<<<<< marks the start of your current branch's version (ours), ======= separates the two versions, and >>>>>>> marks the end of the incoming branch's version (theirs).

2. In a conflict block, which side appears above the ======= line and which appears below?

   Above =======: the current branch's content (labeled HEAD / 'ours'). Below =======: the incoming branch's content ('theirs'), ending at >>>>>>> with the branch/commit name.

3. What is the diff3 conflict style and what extra information does it add?

   The diff3 style (git config merge.conflictstyle diff3) adds a third section marked ||||||| showing the original common-ancestor (base) content, so you can see what both sides changed from.

4. What are the manual steps to resolve a merge conflict?

   1) Open each conflicted file. 2) Edit to keep the desired content and remove all conflict markers. 3) git add the file to mark it resolved. 4) git commit to finish the merge.

5. How do you list which files are currently conflicted?

   git status shows them under 'Unmerged paths'. You can also use git diff --name-only --diff-filter=U to list only conflicted files.

6. During a conflict, what do 'git checkout --ours <file>' and '--theirs <file>' do?

   They resolve the file by taking one entire side: --ours keeps the current branch's version, --theirs keeps the incoming branch's version, discarding the other side's changes for that file.

7. What command launches a configured graphical merge tool to resolve conflicts?

   git mergetool. It opens the tool set in the merge.tool config (e.g., meld, kdiff3, vimdiff) for each conflicted file.

8. In a typical three-pane merge tool, what do LOCAL, REMOTE, and BASE represent?

   LOCAL = your current branch's version (ours), REMOTE = the incoming branch's version (theirs), BASE = the common ancestor. The center/output pane is the merged result you produce.

9. How do you configure a default merge tool?

   git config --global merge.tool <toolname> (e.g., meld). You can also set mergetool.<tool>.path if the executable is not on PATH.

10. Name three practical strategies to avoid merge conflicts.

    1) Pull/rebase from the shared branch frequently to stay current. 2) Keep branches short-lived and changes small/focused. 3) Coordinate so team members avoid editing the same lines/files, and use consistent formatting to reduce spurious conflicts.

11. How does frequently integrating (small, frequent merges/pulls) reduce conflicts?

    It keeps divergence small, so each merge reconciles fewer differences. Long-lived branches accumulate many changes that overlap, dramatically raising conflict likelihood and difficulty.

12. What is the fundamental difference between merge and rebase?

    Merge combines two histories by creating a new merge commit, preserving the actual branching structure. Rebase replays your commits on top of another base commit, creating new commits and producing a linear history.

13. Does rebase modify existing commits, and what does that imply about their SHAs?

    Rebase creates new commits with new SHA-1 hashes (rewriting history), even if the content is identical, because a commit's hash depends on its parent and metadata. The originals become unreferenced.

14. When is merge preferred over rebase, and vice versa?

    Merge is preferred for integrating shared/public branches and preserving true history. Rebase is preferred for cleaning up local commits before sharing and for keeping a linear, readable history on private branches.

15. What command starts an interactive rebase over the last 3 commits?

    git rebase -i HEAD~3. It opens an editor with a to-do list of those commits to reorder, edit, squash, or drop.

16. Name the common interactive rebase actions (todo commands) and their effects.

    pick (keep commit), reword (change message), edit (pause to amend), squash (combine into previous, keep both messages), fixup (combine into previous, discard its message), drop (remove commit).

17. What is the difference between 'squash' and 'fixup' in interactive rebase?

    Both merge a commit into the preceding one. squash lets you combine and edit both commit messages; fixup discards the squashed commit's message, keeping only the previous one's.

18. State the Golden Rule of Rebasing.

    Never rebase commits that have been pushed to a shared/public branch that others may have based work on. Rebasing rewrites history and forces collaborators into painful re-syncs.

19. Why does violating the Golden Rule of Rebasing cause problems for collaborators?

    Rebasing replaces shared commits with new ones (different SHAs). Others still have the old commits, so their histories diverge, producing duplicate commits and confusing merges when they pull.

20. How do you resolve conflicts during a rebase and continue?

    Edit and stage the conflicted files with git add, then run git rebase --continue. Use git rebase --skip to drop the current commit, or git rebase --abort to cancel and restore the original branch.

21. During a rebase conflict, what do 'ours' and 'theirs' refer to (and why is it counterintuitive)?

    In rebase, 'ours' is the branch you are rebasing onto (the new base), and 'theirs' is your commit being replayed. This is reversed from merge because rebase applies your commits on top of the base.

22. What is the difference between a lightweight tag and an annotated tag?

    A lightweight tag is just a name pointing to a commit (like a fixed branch). An annotated tag is a full object stored in the database with tagger name, email, date, message, and optional GPG signature.

23. How do you create a lightweight tag versus an annotated tag?

    Lightweight: git tag <name>. Annotated: git tag -a <name> -m "message" (or -s for a signed tag). Annotated is recommended for releases.

24. By default, does git push send tags to the remote, and how do you push them?

    No. Tags are not pushed automatically. Push one with git push origin <tagname>, or push all tags with git push origin --tags (use --follow-tags to push annotated tags reachable from pushed commits).

What this deck covers

Branching and Merging flashcards FAQ