So much of this comes down to how a particular team uses git and the handling and organization of commits. The only thing you can really "do wrong" with git is

So much of this comes down to how a particular team uses git and the handling and organization of commits. The only thing you can really "do wrong" with git is push prematurely. Before that, you always have a chance to fix things or tidy things up. git allows you to package commits up with the interactive rebase before you push them upward to the source. What you commit now isn't necessarily what gets pushed upward. It doesn't matter if you broke the compile with the commit, you still have a chance to fix it before a push. If it hasn't been pushed, no one will necessarily ever know or see it. The whole point of git is that you can break the crap out of your local repo/branch and still have a chance to fix it before the changes ripple outward and become permanent. It also sounds like you're describing a workflow that entails working off master instead of using feature branches, which is going to create a lot more pain than there needs to be.