4 ms·
Well, the OP clearly lays out the case when long-lived feature branches are better. They are great for enabling you to do things you should not do. They are goo
by jeffbee 3y ago
Well, the OP clearly lays out the case when long-lived feature branches are better. They are great for enabling you to do things you should not do. They are good for landing huge, un-reviewable changes, or working in code bases with no tests.
Every argument I have ever seen in favor of feature branch development, and frankly 90% of the arguments in favor of git, take the form of "It makes it easier for me to [[terrible idea]]."
- miked85 3y agoYeah, I'm not saying there is never a need for a long-lived feature branch, there are use cases. I would say it's fairly rare in practice for it to be preferable, at least in my experience.
- bonzini 3y agoWhat terrible ideas?
- hinkley 3y agoAnd here's the thing about refactoring: If you know what the fuck you're doing, you can sneak new features in just as easily as with a feature branch. Maybe even moreso. So if you are working for an organization that is actively attempting to self-destruct, to the point where you feel like there needs to be a conspiracy to keep the wheels on, even then feature branches don't help. And in fact they make things worse because your coworkers who defect are busy breaking things on their feature branches, undoing all of your carefully laid plans to unfuck the code and thereby the organization. Learn to refactor code that has unnecessary constraints into code that doesn't. Then those features you can't get out of the backlog become 3 weeks instead of 3 months, and you can actually work on them, because you've already made the change easy.