Reshaping history — rebase, stash, tag, cherry-pick
Techniques for editing history you already made. Powerful, and bound by one golden rule you must not break.
- You can tidy your own history with an interactive rebase
- You can shelve work in progress and come back to it
- You can mark a release point with a tag and lift a single commit with cherry-pick
From here on you're editing history you already made. git rebase lifts your commits and replants them on top of another commit, straightening the history into one line. Where merge records what actually happened, rebase arranges it to be read. Add -i and you can squash commits together, reword messages, or reorder them before they go public.
There is exactly one golden rule: never rebase commits you have already shared. Rebase creates new commits and swaps them in, so if someone was building on the originals, their history diverges from yours and untangling it is painful. Use it freely on your own branch right up until you open the pull request, and not after.
git stash puts your unfinished work on a shelf — the command you reach for when an urgent bug lands and you must switch branches right now. git tag pins a name like v1.0.0 to a commit so you can find the exact code you released. git cherry-pick lifts a single commit from another branch into this one. All three are tools for handling a part rather than the whole.
Don't just read them — type them into a real terminal. Your hands have to remember, not your eyes.
git rebase -i HEAD~3- Interactively tidy your last three commits — squash, reword, reorder.
git stash push -m "작업 중"- Shelve your current changes with a note so you can switch branches now.
git tag -a v1.0.0 -m "첫 배포"- Mark this commit as a release point with an annotated tag.
git cherry-pick <commit>- Bring just one commit from another branch into this one.