No, this is just terrible. Your description points to severe disadvantages in this situation.
Your code example points to the critical weakness of this approach. You have two pieces of code in the project doing the same thing. Either they both work and its redundant, or one doesn't and it's broken. I don't see value in either of these states.
The idea that you're committing half-baked features also points to a development flaw. Why would you do this? A limited feature is fine, but something that is admittedly "half-baked" shouldn't be in shipping code.
Having several people spend weeks on major features that will conflict when merged also sounds bad. Just because you're branching doesn't mean individual are working independently. There should still be coordination along interfaces, iteration goals, and more.
Two weeks is a long branch life on an active project. They happen, but they require special care, involving lost of merging from master over that time. This merging from master avoids the isolation. If master is going weeks without any changes then your branches are just too big.
What you're describing about branches sounds like you've failed to create a proper branching strategy. The solution isn't to abandon it, but to fix it.
Branching is one of the cornerstones to proper engineering. One may argue with the strategy, but to argue fundamentally against it is a terrible thing. It does everybody a disservice to imply that a branch-less strategy is a viable option.
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.
No, this is just terrible. Your description points to severe disadvantages in this situation.
Your code example points to the critical weakness of this approach. You have two pieces of code in the project doing the same thing. Either they both work and its redundant, or one doesn't and it's broken. I don't see value in either of these states.
The idea that you're committing half-baked features also points to a development flaw. Why would you do this? A limited feature is fine, but something that is admittedly "half-baked" shouldn't be in shipping code.
Having several people spend weeks on major features that will conflict when merged also sounds bad. Just because you're branching doesn't mean individual are working independently. There should still be coordination along interfaces, iteration goals, and more.
Two weeks is a long branch life on an active project. They happen, but they require special care, involving lost of merging from master over that time. This merging from master avoids the isolation. If master is going weeks without any changes then your branches are just too big.
What you're describing about branches sounds like you've failed to create a proper branching strategy. The solution isn't to abandon it, but to fix it.
Branching is one of the cornerstones to proper engineering. One may argue with the strategy, but to argue fundamentally against it is a terrible thing. It does everybody a disservice to imply that a branch-less strategy is a viable option.