Git for Real Teams

Merge creates a commit joining two histories, leaving both branches' commits exactly as they were. Rebase replays your commits on top of the target branch, giving them new hashes, which produces a linear history that's easier to read.

The deciding question is whether anyone else has based work on the branch. Rebase rewrites commits, so if a colleague has pulled your branch and built on it, their history no longer matches yours and reconciling it is genuinely painful. So: rebase freely on my own unshared feature branch to stay current with main, merge once a branch is shared, and never rebase main itself. Beyond that safety rule it's largely team convention, and consistency matters more than which convention.

First I read the description to know what it claims to do, then I look at the diff as a three-dot comparison against main, because that's what the branch actually changed. A two-dot diff would also show me main's own recent commits as if the branch had deleted them, which is misleading.

For anything beyond trivial, I run it. Stash my own work, fetch, check out their branch, and ideally create a throwaway branch and merge current main into it, so I'm testing the state that will exist after the merge rather than the branch in isolation. Then run the test suite and exercise the feature by hand. I'm looking for things a diff can't show: does the app still start, does a migration reverse, is a new env var documented, is it fast on realistic data. Then I leave comments labelled by severity so the author knows what actually blocks the merge.

During a rebase, my own commits are "theirs" — which trips up almost everyone. Rebase replays my commits onto the target branch, so from Git's perspective the branch being built on — main — is "ours", and each commit being applied on top, which is mine, is "theirs". It's the opposite of the merge case, where "ours" is the branch I'm sitting on.

Honestly though, I wouldn't rely on the labels. I'll inspect the actual content of both sides out of the index — stage 2 is "ours" and stage 3 is "theirs" — and decide by reading the code. Reading beats remembering on this one, because getting it backwards means discarding real work.

Since nothing's pushed, this is entirely local and safe. I'd create a branch at my current position, which captures the commit on a proper feature branch, then move main back to where the remote has it — switch to main and reset hard to origin/main. The work survives on the new branch and main is clean again.

If it had already been pushed to a shared main, the answer changes completely: then I'd use revert, which adds a new commit undoing the change rather than rewriting history other people have already pulled. Force-pushing main to hide a mistake is how you break everyone else's clone.

Reset moves the branch label backwards, effectively removing commits from that branch's history. Revert leaves history intact and adds a new commit that applies the inverse of an old one. The choice is decided by whether the commit has been shared.

Anything already pushed to a branch other people pull from gets reverted, because rewriting shared history forces everyone else into a messy divergence. Local, unpushed commits can be reset freely. Revert also has the advantage of being an honest record: the log shows that something was introduced and then deliberately undone, which is genuinely useful context later.

Almost certainly not, if it was committed. Git keeps a reflog — a local record of every position HEAD has occupied, including ones no longer reachable from any branch. I'd run git reflog, find the entry from just before the reset, and reset hard back to it, or create a branch at that commit to be safer.

The important caveat is that this only covers work that was committed. Uncommitted edits destroyed by a hard reset are genuinely unrecoverable, since Git never had them. That's the real argument for committing frequently on a feature branch and for reaching for stash rather than reset when you just need a clean tree.

Fetch downloads new commits from the remote and updates my local view of the remote branches, but doesn't touch my working files or my branch at all. It's always safe to run. Pull is fetch followed immediately by integrating those changes into my current branch, which is the part that can produce a conflict.

In practice I fetch first when I want to see what's changed before deciding what to do — comparing my branch against the updated remote to see exactly what each side has. That's particularly useful when a branch shows as diverged, because it lets me look before choosing between merging, rebasing, or asking whoever rewrote it what they intended.

It's routine on my own feature branch after a rebase or an amend, because rewriting a commit changes its hash and the remote can no longer fast-forward. It's not acceptable on main or any shared release branch, where it rewrites history under other people's feet.

The safe form is --force-with-lease, which only overwrites if the remote is still where I last saw it. If someone else pushed to that branch meanwhile, the push is rejected instead of silently destroying their work. Plain --force has no such check. I'd also fetch first, since the lease is only as current as my last fetch, and warn a reviewer before rewriting a branch they're mid-review on.

Usually one of two things. Either I'm looking at a two-dot diff, which compares branch tips and therefore shows main's newer commits as changes my branch made, or my branch was created from a stale main and genuinely hasn't seen recent work.

The fix for the first is comparing with three dots, which diffs against the point where the branches diverged. The fix for the second is merging current main into my branch, after which the phantom changes disappear because my branch now contains them. If files still show up unexpectedly after that, I'd check for something environmental — line-ending settings or a formatter reformatting files on save are the usual culprits.

Mostly by changing the workflow rather than getting better at resolving them. Short lived branches are the biggest factor — a branch open for two days conflicts far less than one open for three weeks. Pulling main into an active branch daily turns one large reconciliation into several trivial ones, in code the author still remembers writing.

Beyond that: keeping PRs small so they merge quickly, splitting large files that everyone edits simultaneously, and agreeing on formatting via an automated formatter so nobody generates conflicts purely from whitespace. And when a conflict does involve someone else's deliberate change, asking them rather than guessing — a conflict is often a signal that two people were solving overlapping problems and should talk.