title: Reasons not to commit to master
body: <p>In each manual and documentation about Git you can find the following recommendation: Do not commit to master, if you need to make some changes to master, you need to create a new branch first and then merge it. So, I'm interested to know why? What benefits does this approach offer? ‌Because as far as I understand, you don't need separate branches if you want to, for example, to revert a change - you can simply do that by using previous commit's hash.</p>
  <p>Here I found one reason - if you have many commits, it will be easier to merge branch with master then push commits one after another
  <a href="http://waterstreetgm.org/git-why-you-should-never-commit-directly-to-master/" rel="nofollow noreferrer">http://waterstreetgm.org/git-why-you-should-never-commit-directly-to-master/</a></p>
  <p>But what if your workflow is divided into many small tasks and each of these tasks fits into the one commit. So, each branch contains one commit. What are the reasons not to commit to master in this case?</p>