DEV Community

Discussion on: Why you should not use (long-lived) feature branches

Collapse
 
krzysztow profile image
Krzysztof

Hi, thanks for the article.

In my opinion, there is a huge advantage to the feature branches - and that's the visibility in the history. There are reasons to look in the history (like a year ago) of the cvs, when trying to explain why something is implemented that way or the other. And then, if you see the work on a branch, you know the whole context.

Also, if you're worried about the changes on the trunk that might affect the feature branch work, just pull the develop branch and rebase on top of it - as frequently, as you're suggesting to merge. I'm of the opinion that on your branch you can modify that history however you want.

Moreover, if you think you're able to commit every time unfinished work to the develop - maybe the scope of the "features" is just too large. What about splitting it up, and then calling these chunks a feature?

Thanks again,
Krzysiek.

Collapse
 
lirantal profile image
Liran Tal

and that's the visibility in the history.

If you're not using something like GitHub where this is no notion of pull requests then I completely agree that this is a valid point that need addressing. If you're using GH however, you have the complete history of the branch in a Pull Request.

I suggest taking a look at slides.com/lirantal/effective-git-... to see if you get convinced with trunk based development :)