Branching and mergingmedium3-5 years
During an interactive rebase, a developer hits a conflict, looks at the `<<<<<<< HEAD` block, and — out of habit from resolving merge conflicts — keeps that side every time. The result quietly discards their own work. What went wrong?
HEAD means opposite things in a merge and a rebase, and "keep HEAD" is a habit that's only safe in one of them. During a normal merge, you're on your own branch and HEAD is your side of the conflict. During a rebase, Git detaches and checks out the target branch first, then replays your commits onto it one at a time — so while resolving a rebase conflict, HEAD is the branch being rebased onto (typically main), and your own change is the bottom half of the markers, labelled with a commit hash instead of a branch name. Reflexively keeping HEAD during a rebase means keeping main's version and discarding your own — exactly backwards from what the developer intended.
PreviousA pull request that's been open for three weeks suddenly has conflicts across six files, even though the author only touched two of them. A teammate says "just rebase and force-push, that'll clear it up." What's the actual mechanism behind conflicts growing over time, and why does rebasing onto main help?Next A developer runs `git reset --hard HEAD~1` on the wrong branch, wiping out a commit they needed. `git log` no longer shows it. Is the commit actually gone, and how would you get it back?
A merge fails with `CONFLICT (content): Merge conflict in config.txt`, and the file has three lines. A developer assumes the whole file is now in question and starts rewriting it from scratch. What does Git actually mean by a conflict here, and what's the right way to read the markers?A pull request that's been open for three weeks suddenly has conflicts across six files, even though the author only touched two of them. A teammate says "just rebase and force-push, that'll clear it up." What's the actual mechanism behind conflicts growing over time, and why does rebasing onto main help?A developer rebases their own feature branch and pushes with `git push --force-with-lease`, expecting it to refuse if a colleague pushed to the same branch in the meantime. It doesn't refuse, and the colleague's commit is gone from the remote. What went wrong with the safety it's supposed to provide?