Rebase and History Rewriting

A forced push overwrites the remote branch pointer even when the new tip is not a descendant of the old one, so commits other people pushed can stop being reachable and everyone who already fetched the branch now has a history that diverges from it.

Git opens an editor holding a todo list of the three commits after HEAD~3, oldest first, each on a pick line. You edit the verbs and the order, save, and Git replays the commits as scripted, creating new commit IDs.

Merging adds a new commit that joins both histories and leaves your existing commits untouched. Rebasing re-creates your commits on top of main's tip as new commits with new hashes, producing a straight line with no merge commit.

A Git commit only adds a new snapshot. Every earlier commit still references the blob holding that file, so the content stays reachable and clonable until history itself is rewritten and the old objects are pruned.

git bisect run <cmd> runs your test at each step and answers for you: exit 0 means good, 1 to 127 except 125 means bad, 125 means untestable so the commit is skipped, and 128 or above aborts the bisect.

git revert adds a new commit whose diff is the inverse of the target commit, leaving history intact and forward-only. git reset --hard moves the branch pointer backwards so the commits are no longer on the branch, rewriting what the branch contains.

It makes the forced update conditional: the push succeeds only if the remote branch still points where your remote-tracking ref says it does. If someone else pushed in between, the update is rejected instead of silently discarding their commits.

Both fold a commit into the one on the line above it. Squash opens an editor with both commit messages so you can write a combined one; fixup keeps the earlier commit's message and throws the folded commit's message away, with no editor prompt.

After you stage a resolution, git rebase --continue records that commit and resumes the replay. git rebase --skip discards the commit being replayed entirely and moves on. git rebase --abort ends the whole operation and returns the branch to its pre-rebase tip.

A commit's hash is computed over its whole content, which includes its parent, its message, and both author and committer identity and timestamp. Rebase re-creates each commit with a different parent and a fresh committer timestamp, so the hash must differ.

Run git filter-repo on a fresh clone with a path filter: git filter-repo --path secrets/ --invert-paths keeps everything except that path. It rewrites every commit, so all downstream SHAs change and the result must be force-pushed.

A merge commit has two parents, so "the change it introduced" is ambiguous — it differs depending on which parent you compare against. -m <parent-number> names the mainline parent to treat as the branch you kept, and Git undoes the change relative to that one.

Fetch, then find the branch's old upstream tip in your reflog and replay only your own commits onto the new tip with git rebase --onto. Never merge or pull, because that reconciles two parallel histories and drags the discarded commits back.

Treat the credential as compromised and invalidate it first — a history rewrite cannot un-leak it. Then purge it with git filter-repo --replace-text on a fresh clone, force-push every rewritten ref, and have everyone re-clone.

git bisect binary-searches history. Run git bisect start, mark a broken commit bad and an older working one good, test each commit Git checks out and answer good or bad, then git bisect reset.

Bisect's answer resolution is one commit. Small commits mean the first bad commit is a diff you can read; a huge squashed commit only tells you the bug is somewhere in a week of work, and unbuildable commits force skips.

git cherry-pick -x appends a line to the copied commit's message recording the id of the commit it came from, in the form (cherry picked from commit <sha>). It documents provenance; it changes nothing about the content applied.

With --autosquash, git rebase -i scans commit subjects for the fixup! and squash! prefixes, moves each such commit directly below the commit it names, and pre-sets its todo verb to fixup or squash — so the plan arrives already arranged.

Mark the commit edit in the git rebase -i todo list. When the rebase stops there, run git reset HEAD^ to undo the commit but keep its changes in the working tree, commit the pieces separately with git add -p, then run git rebase --continue.

It replays the commits reachable from feature-b but not from feature-a onto main, then moves feature-b to the result. You need it when the commits you want to move and the base you want to cut them from are different things.

git filter-branch forks a shell per commit, so it is extremely slow, and its defaults are unsafe: it leaves refs/original backups, keeps empty commits, and ignores tags and other refs unless told otherwise. Git's own docs now point at git filter-repo.

Use git bisect skip when a candidate commit cannot be judged, typically because it does not build. Git then tests a neighbour, and if only skipped commits remain it reports a set of possible first bad commits instead of one.

The revert removed the content but left the merge commit in place, so the branch's commits are still ancestors. A second merge finds nothing new to bring in — Git decides what to merge from ancestry, not from what the files currently contain.

Its lease is checked against your remote-tracking ref, which any background fetch updates. If something fetched a teammate's push without you looking at it, the lease matches and the forced update discards their work. --force-if-includes closes that gap.

Use git rebase -i --exec "make test" <base>. Git inserts an exec line after every commit in the todo list and runs that command as each commit is created; a non-zero exit stops the rebase at that commit so you can fix it and continue.

When branches point at intermediate commits in a stack, rebasing the top branch normally leaves those refs on the old, pre-rebase copies. The --update-refs option moves them to the corresponding replayed commits so the whole stack stays consistent.

Measure with git count-objects -vH, then list the biggest objects by piping git rev-list --objects --all through git cat-file --batch-check. Purge them with git filter-repo --strip-blobs-bigger-than or a path filter, then re-measure; every downstream SHA changes.

Allow rewriting on short-lived branches with a single owner, forbid it on anything others build on or that is deployed from. Enforce it at the receiving repository — receive.denyNonFastForwards and a pre-receive hook — because client-side flags are only courtesy.

A linear history buys readable logs and simpler bisecting, but every rebase copies commits: conflicts are re-resolved per commit and per rebase, shared branches need coordinated force-pushes, intermediate commits are combinations that were never tested, and old hashes recorded elsewhere stop resolving.