the way i look at it is this: we actually use git for at least two different but related things - a public change history (e.g. commit history of master, dev-1

the way i look at it is this: we actually use git for at least two different but related things - a public change history (e.g. commit history of master, dev-1.0, whatever) - a personal change history, especially useful when prototyping a fix or feature on some independent branch. you might even call this independent branch "master" but it's your personal version of master in a clone on your laptop. it's a time machine, you can go backward/forward. you can make a change and then reverse course. you can commit every work-in-progress that compiles as you work get it running or passing tests. whatever you like. you can pull or merge or rebase as you wish. when submitting it to the public "master" branch, you are effectively saying "i want to commit this package of changes on top of the master branch. do you really want to see "fhgiry pulled from master into fix-splork-feature on date x" and https://xkcd.com/1597/ https://xkcd.com/1597/ in your public history of master? every branch you merged from or rebased on and every failed attempt and spelling mistake and WIP and addressing of review comments? or do we want to see a series of commits that just record the end result in a series of nice little patches that simply add a finished changes like: "splork: fix canoe paddle explosion issue by decreasing default gamma" the common ubiquitous guidance to "never rewrite history" is nearly always valid for the public history. converting a messy personal history into a neat series of patches/changes/commits that apply cleanly onto the latest public master should not fall under that same guidance. i'd say it's closer to "never rewrite public history"