I mean... if it works for you I guess... but I don't think I could disagree with this strategy any more than I do; even if I tried.
Feature branching has been one of the best things we've done to step up our game in years. We have very reliable release process that includes management review of everything that is getting released. We have branches for each environment with builds tied to them. A simple merge to that environment gets the code out for review, QA, and UAT. We have weekly releases; continued improvement.
I am very confused how "resolving conflicts quickly" is useful when you've possibly broken the flow of 5 developers because a sixth pushed something that broke things. that seems insane to me that even if it is fixed quickly it isn't extremely disruptive. Context switching is so damaging to productivity; I cannot see why you'd set yourself and the team up for it to happen frequently inside of your own development process.
Software development branching doesn't translate to your painting example. Of course 5 people working independently on a painting is going to be (most likely) a total mess -- unless they are all working together and discussing what the plan will be. The very element to making no branching work is exactly how you avoid issues in a feature branch scenario: communication. That doesn't change no matter what you do.
Feature toggling is key no matter what branching methodology you subscribe to. It is just a good way to build software; especially if it is a multi-tenant application.
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.
I mean... if it works for you I guess... but I don't think I could disagree with this strategy any more than I do; even if I tried.
Feature branching has been one of the best things we've done to step up our game in years. We have very reliable release process that includes management review of everything that is getting released. We have branches for each environment with builds tied to them. A simple merge to that environment gets the code out for review, QA, and UAT. We have weekly releases; continued improvement.
I am very confused how "resolving conflicts quickly" is useful when you've possibly broken the flow of 5 developers because a sixth pushed something that broke things. that seems insane to me that even if it is fixed quickly it isn't extremely disruptive. Context switching is so damaging to productivity; I cannot see why you'd set yourself and the team up for it to happen frequently inside of your own development process.
Software development branching doesn't translate to your painting example. Of course 5 people working independently on a painting is going to be (most likely) a total mess -- unless they are all working together and discussing what the plan will be. The very element to making no branching work is exactly how you avoid issues in a feature branch scenario: communication. That doesn't change no matter what you do.
Feature toggling is key no matter what branching methodology you subscribe to. It is just a good way to build software; especially if it is a multi-tenant application.