Without branching you can't have pull requests. Without pull requests code reviews are very difficult. I work on shared repos with as many as 10 other devs working on feature PRs at a time and this simple model just won't work for us.
If you think about it branches are just "groups" of commits. Being able to break big features down into small commits and group them is actually something that helps avoid conflicts and increase communication in my experience.
The only time not branching ever worked for me was back when I first started using GIT and was basically just a single developer that used source control as a giant undo history.
In my personal experience PRs are almost useless unless all your team knows how to do them well. In my opinion PRs cannot beat a well configured Sonar + CI Server.
You have an amazing Sonar + CI Server if it can give warnings for inappropriate architectural approaches, business requirement issues, or rolling your own libraries when those already exist in the codebase or in existing dependencies.
"PRs are useless".
I'm seriously more and more horrified I would accidentally one day work for that team. I'm sure I'll see a nightmare tonight. Dude you need a good mentor who can show you how it's done. No offense, try to work with people having worked abroad and have a wide experience in leading teams. You have many misconceptions and dogmas.
Then you have no idea what you're talking about. You can configure PRs such that if the code is not building, or passing tests, it will never be possible to merge that code to the main branch. With your approach, this is not possible and who knows if you even pay attention to failing tests at the moment. Because when you're not FORCED to solve these issues, sooner or later somebody will say to leave it to later, because now you're busy with other stuff.
Also, you still didn't answer how you conduct code reviews. I'm guessing you don't. But even if you do, the result is that code pushed to main development branch is messy.
In some other comment you mentioned that developers changed architecture in their feature branches. Well, with code reviews, you'd see that and comment on that and tell the developers to not change the architecture, or resolve the situation before it gets to main development branch.
I'm thinking maybe you just never worked in a technically mature team and you never conducted proper code reviews and that's why you have these opinions.
Without branching you can't have pull requests. Without pull requests code reviews are very difficult. I work on shared repos with as many as 10 other devs working on feature PRs at a time and this simple model just won't work for us.
If you think about it branches are just "groups" of commits. Being able to break big features down into small commits and group them is actually something that helps avoid conflicts and increase communication in my experience.
The only time not branching ever worked for me was back when I first started using GIT and was basically just a single developer that used source control as a giant undo history.
In my personal experience PRs are almost useless unless all your team knows how to do them well. In my opinion PRs cannot beat a well configured Sonar + CI Server.
You have an amazing Sonar + CI Server if it can give warnings for inappropriate architectural approaches, business requirement issues, or rolling your own libraries when those already exist in the codebase or in existing dependencies.
"PRs are useless".
I'm seriously more and more horrified I would accidentally one day work for that team. I'm sure I'll see a nightmare tonight. Dude you need a good mentor who can show you how it's done. No offense, try to work with people having worked abroad and have a wide experience in leading teams. You have many misconceptions and dogmas.
Then you have no idea what you're talking about. You can configure PRs such that if the code is not building, or passing tests, it will never be possible to merge that code to the main branch. With your approach, this is not possible and who knows if you even pay attention to failing tests at the moment. Because when you're not FORCED to solve these issues, sooner or later somebody will say to leave it to later, because now you're busy with other stuff.
Also, you still didn't answer how you conduct code reviews. I'm guessing you don't. But even if you do, the result is that code pushed to main development branch is messy.
In some other comment you mentioned that developers changed architecture in their feature branches. Well, with code reviews, you'd see that and comment on that and tell the developers to not change the architecture, or resolve the situation before it gets to main development branch.
I'm thinking maybe you just never worked in a technically mature team and you never conducted proper code reviews and that's why you have these opinions.
There is no race between those. Those are supposed to work together.