Branching and merginghard5-8 years
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?
--force-with-lease compares against the developer's own remote-tracking ref — the branch state recorded the last time they fetched — not against whatever the remote actually holds right now. If anything refreshed that remote-tracking ref in the background after the colleague's push but before the force-push — a background git fetch, an IDE that polls periodically, a CI integration — the lease silently updates to match the colleague's new commit, and the force-push then sees "the remote matches what I last saw" and proceeds, overwriting the colleague's work anyway. The lease is a real safety check, but it's checking against a snapshot that can go stale without the developer doing anything themselves — it's a seatbelt, not a guarantee.
PreviousA service compiles cleanly, but throws `NoSuchMethodError` in production on a code path that calls into a third-party library the team never directly wrote a version for. Where would you look first, and what's the actual mechanism that produces this?Next A project imports the Spring Boot BOM, and a developer bumps just the Spring Security version by hand to pick up a patch, leaving the rest of the BOM's versions alone. Soon after, the app fails to start with a confusing bean-wiring error. What did the BOM actually provide, and what did overriding one version break?
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?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?