Git & Version Control Vocabulary

git merge integrates branches by creating a new merge commit that joins two histories — preserving full context. git rebase moves (replays) your commits onto the tip of another branch, rewriting history for a cleaner, linear log. Rule of thumb: rebase local feature branches before merging; avoid rebasing shared/public branches as it rewrites commit hashes.

git cherry-pick <commit-hash> applies a specific commit from one branch onto another. Useful for backporting a bug fix to an older release branch, or grabbing a single feature commit without pulling everything else. It creates a new commit with a different hash but the same changes.

git bisect performs a binary search: you tell it a known good commit and a known bad commit, then git checks out the midpoint. You mark each as good or bad until it identifies the exact commit that introduced the regression. Very efficient — O(log n) steps through hundreds of commits.

Normally HEAD points to a branch name (e.g. ref: refs/heads/main). In a detached HEAD state, HEAD points directly to a commit hash. This happens when you git checkout <hash> or git checkout <tag>. New commits made here are reachable only by their hash — create a new branch with git branch <name> if you want to keep them.

git rebase -i HEAD~N opens an editor listing the last N commits with commands: pick (keep), squash/fixup (combine with previous), reword (change message), drop (delete), edit (amend). Used to clean up "WIP" and "fix typo" commits into meaningful, atomic commits before merging a PR. Only do this on commits that haven't been pushed to shared branches.