I say, you have it right and your coworkers are less so. Encourage your coworkers to be secure in their work. Show your struggles, false starts, mistakes, typo

I say, you have it right and your coworkers are less so. Encourage your coworkers to be secure in their work. Show your struggles, false starts, mistakes, typo fixes. Embrace the messy history! My last few teams' workflows and projects were such that commit history wasn't really a big deal. I'm skeptical that it matters if the dev-to-production process is smooth. These tips are habits we have: Keep commit message first line to under 50 characters, use imperative mood, capitalized. If you need more than that to describe what's going on then the commit might be too big. PRs must pass all continuous integration tests + 1 or 2 devs approval. Pretty much always do what a dev suggests in review, even if you disagree. Optionally, squash merge PRs to master, to make reverting easier. I prefer that. If a feature is very complicated, break it down into smaller tasks, merging each to master when completed. Maybe use a feature branch for super complicated inextricably tasks, but doing that too often is a code smell. In that situation, code history isn't really that important. That said, if you're still keen, look up these commands: git commit --fixup {commit id} git reset --soft {something} git rebase -i --autosquash {commit id} Lots of force pushing, will be needed, but never, ever force push to a shared branch unless every one agrees and is aware. Those can straighten out your history right out.