4 ms·

> Branching strategies like Git Flow popularized this approach, and it's extremely common in open source software, where typically community contributors do not

by mqus 3y ago

> Branching strategies like Git Flow popularized this approach, and it's extremely common in open source software, where typically community contributors do not have mainline access, and so much create branches and make pull requests No? I thought Git flow had feature branches, but those were not supposed to live long, just like in every case. Long-lived feature branches should get long-lived by necessity (someone working a long time on a feature that can't or shouldn't be cut down), not by choice. In open source, feature branches are long-lived because either they don't get reviewed or the contributor lost interest/does not have the time to finish it. They didn't choose to make those branches long-lived. Maybe I just misunderstand what "long-lived" means in this context.

mvdtnz 3y ago
I have found that I need to be specific when I talk to developers about "long lived" branches. In the past I have questioned teams about why they are developing in long-lived branches and they defensively claim they aren't - their branches only last two or three weeks. In my view that's a very long-lived branch.
- throwbadubadu 3y ago
  Lol, I feel that is the average ticket/branch time in my >50 safety critical project, time is relative ;)
  - mvdtnz 3y ago
    I don't work on safety critical systems and I imagine my attitude would change if I did! Interesting perspective.
bunderbunder 3y ago
Oftentimes the argument is made that even work that can't be broken down should still be frequently integrated, and instead you use feature flags to control whether it's active in production. I haven't had enough experience working that way to say whether it's better. But I will say this: the root cause of many of the nastiest regression defects I've had to deal with was surprising outcomes when merging a long-lived feature branch into code that had had a few weeks of time to accumulate behavioral changes since the feature branch's creation.

by mqus 3y ago

mvdtnz 3y ago

I have found that I need to be specific when I talk to developers about "long lived" branches. In the past I have questioned teams about why they are developing in long-lived branches and they defensively claim they aren't - their branches only last two or three weeks. In my view that's a very long-lived branch.

throwbadubadu 3y ago
Lol, I feel that is the average ticket/branch time in my >50 safety critical project, time is relative ;)
- mvdtnz 3y ago
  I don't work on safety critical systems and I imagine my attitude would change if I did! Interesting perspective.

bunderbunder 3y ago

Oftentimes the argument is made that even work that can't be broken down should still be frequently integrated, and instead you use feature flags to control whether it's active in production. I haven't had enough experience working that way to say whether it's better. But I will say this: the root cause of many of the nastiest regression defects I've had to deal with was surprising outcomes when merging a long-lived feature branch into code that had had a few weeks of time to accumulate behavioral changes since the feature branch's creation.