First, the analogy of splitting the canvas into 5 doesn't work. Even though you're working on a single feature, you can see the whole canvas and (one would assume) you're communicating to make sure that the changes are harmonious.
Second, feature toggles are a bad idea in my opinion. They basically translate to increasing the cyclomatic complexity because someone can't decide whether a feature should be on or off. The real problem isn't branching, it's indecision and poor planning. I could very easily see four or five half baked features becoming a testing and maintenance nightmare. If you do this for any length of time, your "bitfield" of features will be a lot more than 4 or 5. Good luck changing things when you realize a half baked feature needs a design change in order to complete and you have a few other half baked features to deal with.
Branches are good for a reason. They follow the UNIX philosophy of "Do one thing and do it well". Nothing will replace good planning and prioritisation.
While feature toggles might seem good in the short term, you're essentially building up more technical debt than you need to and are accelerating paralysis due to it in the long term.
Finally, I'd say if branching on Git is actually wrong, then why is it the cornerstone of so many CI/CD workflows? These workflows have been designed by extremely smart and experienced people and have been proven to work. So either you're missing something or the rest of the world has. Which do you think is more likely?
First, the analogy of splitting the canvas into 5 doesn't work. Even though you're working on a single feature, you can see the whole canvas and (one would assume) you're communicating to make sure that the changes are harmonious.
That is the idea of each project, then reality comes and some people don't even listen on the daily standup much less take a look at slack or whatever they just want to be left alone and code.
Second, feature toggles are a bad idea in my opinion. They basically translate to increasing the cyclomatic complexity because someone can't decide whether a feature should be on or off.
If the feature is marked as delivered then it should be on unless it creates a critical bug on production.
The real problem isn't branching, it's indecision and poor planning.
You will have those you want it or not therefore I prefer a system more resistant to it.
I could very easily see four or five half baked features becoming a testing and maintenance nightmare. If you do this for any length of time, your "bitfield" of features will be a lot more than 4 or 5. Good luck changing things when you realize a half baked feature needs a design change in order to complete and you have a few other half baked features to deal with.
Don't bite more than you can chew. Why start 5 new features if your team can only handle 2 per sprint?
Based on personal experience, I would say, don't give in. Instead push for change, hard. Sometimes you will hit a brick wall and will have to move on. But then you find a team (and a manager) that's a joy to work with and work becomes a pleasure.
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.
First, the analogy of splitting the canvas into 5 doesn't work. Even though you're working on a single feature, you can see the whole canvas and (one would assume) you're communicating to make sure that the changes are harmonious.
Second, feature toggles are a bad idea in my opinion. They basically translate to increasing the cyclomatic complexity because someone can't decide whether a feature should be on or off. The real problem isn't branching, it's indecision and poor planning. I could very easily see four or five half baked features becoming a testing and maintenance nightmare. If you do this for any length of time, your "bitfield" of features will be a lot more than 4 or 5. Good luck changing things when you realize a half baked feature needs a design change in order to complete and you have a few other half baked features to deal with.
Branches are good for a reason. They follow the UNIX philosophy of "Do one thing and do it well". Nothing will replace good planning and prioritisation.
While feature toggles might seem good in the short term, you're essentially building up more technical debt than you need to and are accelerating paralysis due to it in the long term.
Finally, I'd say if branching on Git is actually wrong, then why is it the cornerstone of so many CI/CD workflows? These workflows have been designed by extremely smart and experienced people and have been proven to work. So either you're missing something or the rest of the world has. Which do you think is more likely?
That is the idea of each project, then reality comes and some people don't even listen on the daily standup much less take a look at slack or whatever they just want to be left alone and code.
If the feature is marked as delivered then it should be on unless it creates a critical bug on production.
You will have those you want it or not therefore I prefer a system more resistant to it.
Don't bite more than you can chew. Why start 5 new features if your team can only handle 2 per sprint?
It sounds like the problem you're experiencing is lack of communication and agreement. Code isn't going to fix a human problem.
I suggest you tackle the problem at the layer it manifests instead of trying to reinvent a square wheel at a lower layer.
After years of working on several companies and projects the only thing I saw in common were two:
If you have some suggestions on the communication part please tell.
Based on personal experience, I would say, don't give in. Instead push for change, hard. Sometimes you will hit a brick wall and will have to move on. But then you find a team (and a manager) that's a joy to work with and work becomes a pleasure.