8 ms·

https://trunkbaseddevelopment.com https://trunkbaseddevelopment.com is probably a good resource to look at. Long lived feature branches have never worked well i

https://trunkbaseddevelopment.com https://trunkbaseddevelopment.com is probably a good resource to look at. Long lived feature branches have never worked well in my experience.

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 ago
  Yeah, 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 ago
  What terrible ideas?
- hinkley 3y ago
  And 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.
hinkley 3y ago
Once someone pointed out to me that these dynamics are the bargaining phase of loss, I couldn't unsee it. All this rationalizing is people not wanting to admit that merging is hard (most of the people who really want feature branches are also the people I categorically and empirically cannot trust to do merges properly.) They are trying to avoid dealing with their problem by making it everybody's problem.

https://trunkbaseddevelopment.com https://trunkbaseddevelopment.com is probably a good resource to look at. Long lived feature branches have never worked well in my experience.

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 ago
Yeah, 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 ago
What terrible ideas?
hinkley 3y ago
And 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.

hinkley 3y ago

Once someone pointed out to me that these dynamics are the bargaining phase of loss, I couldn't unsee it. All this rationalizing is people not wanting to admit that merging is hard (most of the people who really want feature branches are also the people I categorically and empirically cannot trust to do merges properly.) They are trying to avoid dealing with their problem by making it everybody's problem.