Reasons not to commit to master

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.

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 http://waterstreetgm.org/git-why-you-should-never-commit-directly-to-master/

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?

Solution

Those who said 'never' or 'always' (like in the accepted answer!?!) are often (always!?! 😅 ) wrong...

⚠ Like you will discover once you understand git, there are often multiple ways to do the same things and your choices will mostly be team choices.

There is absolutely no rule that prevents to commit on master. There are advantages and disadvantages to the 2 ways of doing.

For example, the post you linked is more a problem that the writer didn't master git enough than something else...

In less than 5 minutes, he could have created its new branch and reset its local master to the remote ref and pushed one commit on master branch.

Here is a list that is not exhaustive...

Using feature branches (also known as GitHub flow) :

👍 Pros:

you could see clearly where the features are introduced in the software (when the branch is merged)
that makes code review easier (just before merging or during all the development if you made a pull request early, which is a good practice)
easily reverted if needed (just have to revert the merge commit)
easily do proof of concept (but hard to reintroduce in master)
only working workflow when doing remote or opensource development that require code review or CI results before merging commits (but should not necessarily be used in companies because it is successful in open source world)

👎 Cons:

git history could be difficult to read (for that, a rebase just before the merge could make the history easier to read)
devs could easily enter in a tunnel effect without synchronization with the master (preferably made with a rebase instead of sync merges) and end up with a merge hell in the end

Using "trunk Based development" (and feature toggles. Real good development practice that you should have a look) :

👍 Pros:

real continuous integration (with all its benefits like discovering bugs sooner)
prevent merge hells
less cumbersome and easier to master in git
perfectly fine when you are the only developer
a prerequisite when you want to do continuous deployment / delivery (each commit is a small step that minimize the risk of introducing a big bug hard to find the cause in the lot of lines of code changed)
A good Infoq article telling that it's needed to continuous delivery (a DevOps practice): Trunk Based Development as a Cornerstone for Continuous Delivery
Someone made a very exhaustive website on the subject: https://trunkbaseddevelopment.com/

👎 Cons:

not a clear moment when a feature is introduced (should have a look to the feature toggle enabled)
require to have good development practices like writing unit tests (but could also be seen as a pros)
need (sometimes) mastering branching by abstraction (a good explanation by Martin Fowler ). That reduces risks but take more time.

Choose the one that suits your team and stick to it most of the time and apply the other when you think it makes more sense and solve a new problem you encountered...

A very good, long and complete article on the subject by Martin Fowler: https://martinfowler.com/articles/branching-patterns.html (§ Comparing Feature Branching and Continuous Integration. But you will have to read nearly all to get it well...)