> You can't just "commit" as in subversion, you must understand what are you doing. Further I'd argue the subversion "just commit" model is potentially toxic t

> You can't just "commit" as in subversion, you must understand what are you doing. Further I'd argue the subversion "just commit" model is potentially toxic to the quality of the codebase and SCM logs. It makes the act of sharing code with others overly casual. Users therefore often don't become proficient in the proper use of SCMs in general. They write poor commit messages, or may not have a clear understanding of changes introduced by their commit (this goes double for IDE-integrated SCM plugins that I've generally found to have poor UI and lack good affordances for grokking what's happening at any point). The stage -> commit -> push (often to feature branch) provides multiple checkpoints to find issues in your code before it makes it into master/trunk. While staging (especially if you're using a GUI) you have a chance to view the changes being staged. After committing and before pushing, if you find something else that you missed, you can quickly amend your commit without much harm done. The pull request mechanism added by Github provides an additional code review step for a final sanity check and also allows you to run tests on branches before allowing merges (contrasted with the common practice of allowing everyone trunk privileges in SVN, often with a post-commit code review). Rebasing is a an act of final resort for cleaning up your work before everyone else is burdened with the job of grokking and maintaining it for the remaining lifetime of the system. EDIT: Some of these practices are possible to replicate in SVN (eg. do an svn diff and really review the changes before committing) but there's no chance of amending commits, private or features branches are less frequently adopted and rebasing is equivalent to FTL travel and immortality from an SVN viewpoint.