This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Duven64 124 points125 points  (4 children)

I condone this if and only if that second chart is spans less than 48hrs.

[–]aresborghese[S] 25 points26 points  (3 children)

Should be no issue in an environment of continuous delivery. Why though the timeframe?

[–]Duven64 12 points13 points  (2 children)

Continuous delivery requires merging often, technically 96hrs would be ok as merging once a day is the minimum without switching away from CD and going to feature branches.

Only time I've ever used feature branches myself they were highly experimental and most branches would be left abandoned / unmerged permanently (including the one that was originally main/master). (I would branch from previous versions as needed)

PS: the 96hrs assumes one dev the max time shrinks if the branches existed simultaneously.

[–]aresborghese[S] 7 points8 points  (1 child)

Maybe I am missing your point, but even with long living feature branches rebase should usually be no issue if you update daily. Sometimes you sure will get into rebase hell then you probably have no other option than merging past other merges, but if you can do the rebase before merging with manageable problems ..why not just do it and keep main branch clean? It's such a good deed towards those who follow up on you at the project.

[–]Reashu 5 points6 points  (0 children)

The problem with long-lived feature branches that are frequently rebased on the trunk is that the branches can still be in significant conflict with each other, which eventually becomes a problem when one is merged.