4 ms·

We also work with feature branches and I try to understand which signs will tell if we have to much integration problems because of the feature branches. Right

We also work with feature branches and I try to understand which signs will tell if we have to much integration problems because of the feature branches. Right now we really focus on closing pull requests as fast as possible, but still use feature branches that live for a few weeks. I think the maximum lifetime of a feature branch in our project is 5 weeks. You mentioned very short lived feature branches. What does that mean in your case? A few days or weeks?

alkonaut 3y ago
I do anything from 10 minutes to months depending on the scope. Yes it’s painful to have longer lived branches but when you make a months long branch it’s because the pain of doing it any other way would be greater. Most often the longer lived branches are high cost/risk/reward experiments that may or may not turn out successful. E.g swapping out some component that can’t be done side by side easily (as an example from the real world would be moving from .NET framework to .NET core in a several hundred man-year code base). Most “short” branches I do is 24-48h so typically a half day to a full day of coding then about the same amount of time waiting for reviews and validations.
j4yav 3y ago
A day or two, long enough to implement the change, get feedback, and merge.
JimDabell 3y ago
How long the branches live isn’t the most relevant factor when considering integration problems. How often do you integrate? If you aren’t merging the branch yet, do you at least rebase it daily? If so, you aren’t going to run into integration problems. If you go off on your own and then try to integrate after more than a month of development, then yeah, of course you are going to have diverging work that results in integration problems. That’s why continuous integration explicitly says you should be integrating at least daily. Otherwise it’s not continuous. Of course, you might cause other people problems by dumping more than a month of work in your master branch all at once. That’s why things are easier with short-lived branches. But if you want to avoid integration problems yourself, integrate continuously.

alkonaut 3y ago

I do anything from 10 minutes to months depending on the scope. Yes it’s painful to have longer lived branches but when you make a months long branch it’s because the pain of doing it any other way would be greater. Most often the longer lived branches are high cost/risk/reward experiments that may or may not turn out successful. E.g swapping out some component that can’t be done side by side easily (as an example from the real world would be moving from .NET framework to .NET core in a several hundred man-year code base). Most “short” branches I do is 24-48h so typically a half day to a full day of coding then about the same amount of time waiting for reviews and validations.

j4yav 3y ago

A day or two, long enough to implement the change, get feedback, and merge.

JimDabell 3y ago

How long the branches live isn’t the most relevant factor when considering integration problems. How often do you integrate? If you aren’t merging the branch yet, do you at least rebase it daily? If so, you aren’t going to run into integration problems. If you go off on your own and then try to integrate after more than a month of development, then yeah, of course you are going to have diverging work that results in integration problems. That’s why continuous integration explicitly says you should be integrating at least daily. Otherwise it’s not continuous. Of course, you might cause other people problems by dumping more than a month of work in your master branch all at once. That’s why things are easier with short-lived branches. But if you want to avoid integration problems yourself, integrate continuously.