As a Git user, it seems Very Hard to accidentally force push: you need to add a command line parameter, and I was simply taught &quot;Don&#x27;t Do That&quot;.  I&#x27;ve certainly never done it.<p>e.g.:<p><pre><code>  # yes!
  git push origin my-feature-branch
  git push origin master

  # no!
  git push --force origin master
</code></pre>
nsfyn55 makes a good point about protection from others, though. Maintaining my own fork, and using pull requests to the central repo, seems to help avoid others clobbering master, but that seems to be more of a reflection of my organization&#x27;s Git workflow.<p>If your team treats Git the way we used to use Mercurial, where each developer will merge their changes into master and then push it, you&#x27;re going to be in a WORLD of hurt.  (It&#x27;s likely we were doing it wrong there, too. I didn&#x27;t really grok distributed source control until we moved to Git.)<p>If you use the Github Flow [0], the merging is done in the UI of your Github (or Gitlab&#x2F;etc) instance, rather than directly with `git`.  (I believe Atlassian&#x27;s stash has a similar but slightly different recommended workflow.)  The keys for us are:<p><pre><code>  - One team repo is the &quot;official&quot; repo. (e.g., UI&#x2F;foo-widget)
  - Each dev forks the repo, and pushes their branches on that fork 
    (e.g. gknoy&#x2F;foo-widget:gk-feature)
  - Pull Requests are made from the dev&#x27;s repo __to the official one__ 
    (e.g. from gknoy&#x2F;foo-widget&#x27;s gk-feature branch 
          to UI&#x2F;foo-widget&#x27;s master branch)
</code></pre>
Some teams instead opt to have each dev make branches on the same (official) repo.  I prefer the extra safety net of maintaining my own fork.  If I were to mistakenly commit something (or merge something, or rebase something) incorrectly, and totally fubar my repo&#x27;s master branch, and then push that up to my origin before noticing it, I can recover it easily (rename branches, checkout the commit that should be the head, re-push).    Worst case, I can delete my fork and re-fork it. ;)  If I were to do that on a repo that I have shared access to, I&#x27;d have much more anxiety.<p>Incidentally, I&#x27;ve made exactly that mistake (merged or committed something onto my local master, and then pushed it to my origin) TWICE, and caught when others have when doing code reviews.  The first time, I panicked and deleted&#x2F;re-created my forked repo.  The second time, I fixed it by juggling branches, and it was substantially easier.  (Slower: it took me ~20 minutes I think?)  In neither case did my mistakes affect anyone else, though, since the repo I messed up was my own.)<p>This is, of course, based heavily on Github&#x27;s suggested practices, since we use Github Enterprise at work.  Were I using Stash or GitLab, there would likely be some changes, but I think the team workflow really benefits when you dive all-in on Git&#x27;s distributed nature.<p>0: <a href="https:&#x2F;&#x2F;guides.github.com&#x2F;introduction&#x2F;flow&#x2F;" rel="nofollow">https:&#x2F;&#x2F;guides.github.com&#x2F;introduction&#x2F;flow&#x2F;</a>