Exercises — Git operations — branch, merge, rebase, cherry-pick, stash, bisect

A commit. A branch is only a movable pointer; HEAD points to where you are; the index is the staging snapshot. The word "immutable snapshot" is the giveaway — snapshots that never change are commits. This links to Immutability and content-addressable storage: the commit's SHA is a fingerprint of its content, so changing content would change the name.

A fast-forward (FF) merge. WHY no commit: there is nothing to reconcile — one line already contains the other's full history, so Git only has to move the sticky-note.

bisect. Under the hood it is Binary Search over the commit history.

1. Created a new branch pointer feature pointing at the current commit (a 41-byte file write — $O(1)$, i.e. constant time, independent of how big the repo is).
2. Moved HEAD to feature (so future commits advance feature, not main). -c = "create then switch". Without -c, git branch feature creates the pointer but leaves you on main.

git stash. It saves the dirty working tree + index onto a stack and reverts you to a clean HEAD. Now git switch hotfix succeeds. Later git stash pop reapplies the edits and removes them from the stack.

git switch main
git cherry-pick a1b2c3d

It computes the patch parent(a1b2c3d) → a1b2c3d and re-applies it on main as a new commit with a new SHA — see Diff and patch (Myers algorithm) for how that patch is built.

Result: "y". No conflict. Apply the parent note's per-line rule: $\text{result}=\{\begin{array}{ll}O& T=B\\ T& O=B\\ O(=T)& O=T\\ \text{CONFLICT}& O\ne B,T\ne B,O\ne T\end{array}$ Here $O=B=$ "x" (we did not change) and $T=$ "y". That matches case $O=B\Rightarrow$ take $T$. Only one side changed, so the answer is unique — no human needed. See Three-way merge algorithm.

Case: $O\ne B,T\ne B,O\ne T$ → CONFLICT. Both sides changed the same region to different values. Git has no rule to prefer "a" over "b" — picking one would silently discard someone's work. So it writes <<<<<<< ======= >>>>>>> markers and hands you the decision. See Conflict resolution.

(a) Merge: creates one merge commit with two parents — the graph keeps both diverging lines and joins them at a "we came together here" node. History is true but branchy. (b) Rebase: takes feature's 3 commits, replays each as 3 brand-new commits with new SHAs on top of main's tip → one straight line, no merge commit. History is linear but rewritten.

$\text{tests}=\lceil {\log }_{2}1000\rceil =\lceil 9.97\rceil =10.$ WHY: each good/bad answer halves the candidate range $1000\to 500\to 250\to \cdots \to 1$. The number of halvings to shrink 1000 down to 1 is ${\log }_{2}1000\approx 9.97$, and the ceiling $\lceil \cdot \rceil$ rounds up because you cannot do a fractional test.

git stash                 # shelve dirty feature work → clean HEAD
git switch main           # now allowed (tree is clean)
# ...edit the one-line fix...
git commit -am "hotfix"   # lands on main only
git switch feature        # back to feature
git stash pop             # restore your work, drop from stack

WHY each step: stash is required because Git refuses to switch when edits would be overwritten. The hotfix commits only on main, so feature never sees it. pop returns you to the exact dirty state.

git rebase -i HEAD~5
# keep the 1st as 'pick', mark commits 2–5 as 'squash' (or 'fixup')

Remaining from those 5: 1 commit. HEAD~5 is the base; interactive rebase replays the range, folding 4 commits into the 1st. New SHAs are produced (rebase always rewrites), so only do this while the branch is local/unpushed.

Cherry-pick duplicates C's diff as a new commit C' on main (different SHA, same textual change). Git tracks history by SHA identity, not by "did this text already appear". So when you later merge feature, Git's three-way merge treats C as a change feature still "owns" that main supposedly doesn't have — because main has C', not C. How it goes wrong: if surrounding lines shifted, applying C's diff on top of already-present C' lands in the CONFLICT case ($O\ne B,T\ne B,O\ne T$) — the same edit fighting itself. Best case Git notices they're textually identical and no-ops; worst case you get a spurious conflict or a doubled hunk. Better: prefer merge/rebase for integration; reserve cherry-pick for isolated hot-fixes you won't later merge.

Single suspect ($N=1$): $\lceil {\log }_{2}1\rceil =0$ further tests — bisect immediately reports that commit as the first bad one. There is nothing left to halve. Flaky test: binary search assumes monotonicity — everything before the bug is good, everything after is bad, one clean transition. A flaky test breaks that assumption: a false "good" on a truly-bad commit sends bisect into the wrong half and it converges on an innocent commit. Fix: make the test deterministic (or use git bisect skip on commits you genuinely can't judge, so they're excluded rather than guessed).

A branch is a file in .git/refs/heads/ holding a 40-hex-char SHA + newline = 41 bytes. Creating it writes 41 bytes and touches no commit objects → $O(1)$ (constant, independent of history size). 1000 branches ≈ 41 KB total; the commit graph is untouched. A rebase is the opposite: it must (1) find the merge base, (2) extract the diff of each of the $n$ replayed commits (a Myers diff each), (3) re-apply all $n$ patches, creating $n$ new commit objects. Cost scales with $n$ commits × diff size — real work per commit, possibly with conflicts at each step. Pointers are free; rewriting content-addressed snapshots is not.

Name the objects (commit/branch/HEAD), run the pointer moves (switch/stash/cherry-pick), predict the graph from the three-way rule, combine stash+switch+rebase into a workflow, and defend your choice by counting bytes and ${\log }_{2}N$ tests. Every scary command is just new commits + moved sticky-notes on a Directed Acyclic Graph.