To throw in my $0.02, I'd say it entirely depends on what works best for the project and the team - and it won't necessarily be the same if the team changes or the project changes. Hell, it might not even be as productive one feature to the next.
The most important thing - regardless of branching strategy or even VCS - is team communication. Full stop. If the team can't communicate well enough - and that's also arbitrary on a per-team basis - the project will fail. If the team coordinates and communicates great, then you can throw the code on a shared network drive and it'll still go decently.
Yes, a build server is a great thing, but it still needs code to build, and in my experience it gets that from a repo. My company uses Bamboo, which I know can build branches. I'm sure Bamboo is not special on that front. It runs a build on every branch (don't have to pre-configure it, it picks them up on its own), passes or fails, life goes on as it needs to.
We're trying to move towards continuous delivery, so we're trying to go with small stories that can be finished in a day or two. It's be cool if we could do away with branches altogether, but we need PR's and it's nice to keep stuff out of the main line if it's not ready for prime time yet.
Most importantly though, it sounds like you've just had crappy luck for teams. You need to call people on it - diplomatically of course - if they aren't communicating well. Go out of your way to talk to people about what they're working on. If someone isn't paying attention in stand up, find a way to get them to - ask if they have a suggestion on what you're working on or something. If anyone has a problem with it, that's their problem. If management has a problem with it, that's their own fault for not doing their job.
And maybe you need to find another company. I don't know what the market is like where you're at, but in my area - and a lot of places - the only reason to stay at a company doing dev work is normally because you like (or can at least tolerate) the company. You're knowledgeable enough to make a pointed argument on this subject, so you have some reasonable amount of experience coding. You should be able to find a job with people who communicate at a level you can excel with.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
To throw in my $0.02, I'd say it entirely depends on what works best for the project and the team - and it won't necessarily be the same if the team changes or the project changes. Hell, it might not even be as productive one feature to the next.
The most important thing - regardless of branching strategy or even VCS - is team communication. Full stop. If the team can't communicate well enough - and that's also arbitrary on a per-team basis - the project will fail. If the team coordinates and communicates great, then you can throw the code on a shared network drive and it'll still go decently.
Yes, a build server is a great thing, but it still needs code to build, and in my experience it gets that from a repo. My company uses Bamboo, which I know can build branches. I'm sure Bamboo is not special on that front. It runs a build on every branch (don't have to pre-configure it, it picks them up on its own), passes or fails, life goes on as it needs to.
We're trying to move towards continuous delivery, so we're trying to go with small stories that can be finished in a day or two. It's be cool if we could do away with branches altogether, but we need PR's and it's nice to keep stuff out of the main line if it's not ready for prime time yet.
Most importantly though, it sounds like you've just had crappy luck for teams. You need to call people on it - diplomatically of course - if they aren't communicating well. Go out of your way to talk to people about what they're working on. If someone isn't paying attention in stand up, find a way to get them to - ask if they have a suggestion on what you're working on or something. If anyone has a problem with it, that's their problem. If management has a problem with it, that's their own fault for not doing their job.
And maybe you need to find another company. I don't know what the market is like where you're at, but in my area - and a lot of places - the only reason to stay at a company doing dev work is normally because you like (or can at least tolerate) the company. You're knowledgeable enough to make a pointed argument on this subject, so you have some reasonable amount of experience coding. You should be able to find a job with people who communicate at a level you can excel with.