Rebase, Interactive Rebase, Cherry-Pick, Amend, and Safe History Editing: Configuration, Design Choices, and Tradeoffs

1. Rewrite configuration is behavior policy

A setting that makes rebase convenient also changes what ordinary commands may do. For that reason, this chapter treats configuration as an explicit operating decision rather than a list of preferences to copy globally.

2. rebase.autoSquash — convenient for private cleanup

git config --local rebase.autoSquash true
git config --show-origin --show-scope --get rebase.autoSquash

When enabled, interactive rebase automatically recognizes commits created with --fixup/--squash markers and rearranges their todo actions. It does not itself decide whether rewriting the branch is socially safe. A repository-local setting is easier to reason about while learning than a global rewrite preference applied to every project.

3. pull.rebase changes the integration step of pull

git pull fetches and then integrates. Depending on command-line options and configuration, that integration may merge or rebase. Current Git recognizes rebase modes including ordinary rebase, rebase-merges, and interactive rebase.

git config --show-origin --show-scope --get pull.rebase
git config --local pull.rebase false
# Or make the choice explicit per invocation:
git pull --rebase
git pull --no-rebase

Branch-specific branch.<name>.rebase can also shape pull behavior for one branch. Prefer explicit repository/branch policy over an invisible machine-wide surprise.

4. rebase.updateRefs can move more refs than the current branch

Current Git's --update-refs behavior can force-update other local branch refs that point to commits being rebased, except branches that are checked out in another worktree. This helps stacked-branch workflows, but it expands the set of refs a rewrite changes.

git config --show-origin --get rebase.updateRefs
git rebase --no-update-refs trunk

For beginner labs, --no-update-refs is often the clearest choice when you want exactly one topic branch to move. Teams that deliberately use stacked branches can evaluate --update-refs after verifying their Git version and worktree conventions.

5. rebase.missingCommitsCheck turns accidental todo deletion into evidence

git config --local rebase.missingCommitsCheck error

With error, Git can stop when commits disappear because todo lines were removed. If you truly intend to remove a commit, use drop. This is a useful local safety setting for interactive cleanup because intent becomes machine-checkable.

6. Sequence-editor configuration is separate from the message editor

Interactive rebase needs an editor for the todo sequence. Current Git resolves it in this order: GIT_SEQUENCE_EDITOR, then sequence.editor, then the normal Git editor.

git var GIT_EDITOR
git config --show-origin --get sequence.editor
git config --local sequence.editor "code --wait"

Only configure an editor that is actually installed and blocks until the file is saved. On a headless CI runner, interactive rebase is usually the wrong automation primitive; deterministic scripts should avoid requiring a human editor.

7. A force-with-lease rule needs an explicit coordination contract

Replacing a published topic ref after rebase is a non-fast-forward update. Plain --force disables important safety checks and can overwrite someone else's remote update. --force-with-lease adds an expectation about the current remote ref.

EXPECTED=$(git ls-remote origin refs/heads/topic | awk '{print $1}')
# Rewrite only after policy permits it...
git push --force-with-lease=refs/heads/topic:$EXPECTED origin topic:topic

This still does not know whether a human reviewer or downstream build consumed the old commits. A valid lease is a ref-state check, not proof that rewriting is organizationally acceptable.

8. Merge versus rebase: topology and provenance tradeoffs

9. Recreated commits and signatures

A signed commit's signature is part of the commit object. Rebase/amend creates different commit objects; old signatures do not magically authenticate the replacement series. If a project requires signed rewritten commits, the rewrite process must create/sign the new commits according to policy. Chapter 21 treats signer trust and verification fully.

10. Scope and precedence: inspect the effective value

git config --list --show-origin --show-scope | grep -E '^(.*rebase|.*pull\.rebase|.*sequence\.editor)'

System, global, local, worktree, environment, and command-line inputs can all affect behavior. The narrowest explicit command-line choice is easiest to audit for a one-off rewrite. Repository-local configuration is usually safer than global rewrite defaults when projects have different policies.

11. Core Git policy versus server governance

A hosting platform may prohibit non-fast-forward updates, require reviews after force-updating, dismiss approvals when commit IDs change, or protect release branches. Those are server policies layered around Git. Core Git's --force-with-lease cannot override a server rule that refuses the update, and client configuration cannot guarantee organization-wide governance.

12. Worked scenario — choose the least costly history policy

13. Knowledge check

14. Summary

Rewrite defaults are policy. Autosquash can reduce cleanup friction, missing-commit checks protect interactive intent, update-refs expands rewrite scope, sequence-editor configuration controls the todo UI, and pull rebase/force-with-lease choices must match collaboration rules rather than personal preference alone.

Authoritative references

• git-rebase configuration and options
• git-pull
• git-push / force-with-lease
• git-var / editor variables