Rebase and History Rewriting
You will learn to rewrite history deliberately: squash, reorder and edit commits with interactive rebase, move work with rebase --onto and cherry-pick, and scrub secrets with git-filter-repo. Interviewers pair it with the consequences — force-push etiquette on shared branches and reflog as the way back.
part ofGitoverview, primer and where to startread it →on this pageshowhide
explore
- How Rebase Replays Commits6 questions
- Interactive Rebase6 questions
- Cherry-Pick and Revert6 questions
- Bulk History Rewriting5 questions
- Force-Push Safety5 questions
- Bisect4 questions
- AI & Data Scientistrole
- AI Engineerrole
- AI Red Teamingrole
- Android Developerrole
- Backend Developerrole
- Blockchain Developerrole
- Data Analystrole
- Data Engineerrole
- DevOps / SRE Engineerrole
- DevSecOps Engineerrole
- Frontend Developerrole
- Full Stack Developerrole
- Game Developerrole
- Git & GitHubskill
- Java Backend Developerrole
- Java SDETrole
- Kotlin Backend Developerrole
- MLOps Engineerrole
- Machine Learning Engineerrole
- Network Engineerrole
- PostgreSQL DBArole
- QA Engineerrole
- Software Architectrole
- iOS Developerrole
questions
page 2 of 2In Git, how do you tell whether a commit was already cherry-picked upstream?
basics
~20 sCompare by patch content, not by SHA. git cherry <upstream> <head> marks each commit - when an equivalent change already exists upstream and + when it does not, using a patch-id — a hash of the diff that ignores line numbers and whitespace context.
How do you drive a Git interactive rebase from a script without an editor?
basics
~10 sSet GIT_SEQUENCE_EDITOR to a command that edits or simply accepts the todo file. GIT_SEQUENCE_EDITOR=: git rebase -i --autosquash <base> accepts the generated plan unchanged, while a sed command can rewrite the verbs programmatically.
showing 31–32 of 32