Well, first, one of the points of branches is "don't break the build" since you always know that master is an appropriately tested version of the code. Branches give you feature isolation.
Suppose that while developing a feature, you realize that a piece of code is buggy. In your view of the world, where everything is linear, either you drop everything you're doing and fix that bug, or file a bug with the tracker, deferring it until someone has time to fix it.
But morally, the second one is just a branch--time in this case isn't linear. You (or someone else) will have to change contexts at some point and fix the bug. If it's after your feature has been committed, then you have to do it on code which may have churned quite a bit since you filed the bug.
So if you used branches, you would just create branch for the fix. If it gets committed into master before your feature, you could obtain upstream changes. If it gets committed after your feature, you can use rebasing to replay that work on top of the significantly changed code.
If you need to do big arch changes, you still do them in bits such that every build isn't broken. You just do them in a branch, so that nobody else sees them until they are completely ready.
Note also that, with git's powerful tools, you have the option (which is usually taken, these days) to rebase your branches into master, not merge them. So, when you published your changes to the world (git branches are local, nobody else can see them) you could still show the world a linear line of development if you so pleased.
So it may not be a "this is better than this" mentality, but you definitely do lose a significant amount of expressiveness and flexibility for no reason. Branches are painless (in git) and certainly not a waste of time (in that they actually streamline the development process). Can you describe the situation in which you thought that was the case?
As I say, I've worked in a team where branching was tried. It was a hinderance and slowed down development. I've never seen the point of branching for my own personal use.
Others may have different experiences, especially if they work on large teams.
The only reason I can see to "branch" is when you deploy code, make a copy of it in the repos, so that you can fix any bugs off it quickly.
As I say, branching is not something that a "team" does. Branches in git are not something that are published, in nearly every case. Branches are not something like "the dev branch" and "the stable branch". If you are referring to that, in your vague and nonspecifc way, then we are talking about different things.
Branches are feature isolation. For every different feature you add or bug you fix, you, personally and locally, create a branch to do so. If you think that is a lot of branches, you simply don't have the appropriate mental model. If you continue to think of a branch as "making a copy of it in the repos" (what does that even mean??) then, it's... just not the appropriate way to think about it.
Anyway, I'm not going to continue to have this conversation, since it's just not worth it. I just hope I don't have to work for a company that thinks that "branching is bad", but at least if I do they will never know that I am actually using features of my version control system (gasp!).
Suppose that while developing a feature, you realize that a piece of code is buggy. In your view of the world, where everything is linear, either you drop everything you're doing and fix that bug, or file a bug with the tracker, deferring it until someone has time to fix it.
But morally, the second one is just a branch--time in this case isn't linear. You (or someone else) will have to change contexts at some point and fix the bug. If it's after your feature has been committed, then you have to do it on code which may have churned quite a bit since you filed the bug.
So if you used branches, you would just create branch for the fix. If it gets committed into master before your feature, you could obtain upstream changes. If it gets committed after your feature, you can use rebasing to replay that work on top of the significantly changed code.
If you need to do big arch changes, you still do them in bits such that every build isn't broken. You just do them in a branch, so that nobody else sees them until they are completely ready.
Note also that, with git's powerful tools, you have the option (which is usually taken, these days) to rebase your branches into master, not merge them. So, when you published your changes to the world (git branches are local, nobody else can see them) you could still show the world a linear line of development if you so pleased.
So it may not be a "this is better than this" mentality, but you definitely do lose a significant amount of expressiveness and flexibility for no reason. Branches are painless (in git) and certainly not a waste of time (in that they actually streamline the development process). Can you describe the situation in which you thought that was the case?