11–20 of 45 posts
Someone forgot about continuously merging master to feature branch to keep the merge simple.
kennethh posted a link that explains this well: https://martinfowler.com/bliki/FeatureBranch.html
This allow to have code reviews before something is actually in master (something you might or might not want depending on your worflow or criticity of the sw you are working on)
Rebasing (and squashing) allow to keep a linear and clean history.
Rebasing and squashing also have downsides, you lose the finer day to day commits, in exchange of ideal history, but at least it should be mentioned in a 2019 post about having too much feature branches in git...
> Why you should not use feature branches
> Keep reading, all the objections you can think of are wrong.
The tone of the title and some parts of articles suggests that trunk-based development is objectively better than feature branches. I feel that it's rather a matter of opinion. You might want to try it out, it might work better for you than feature branches. But I don't think saying "feature branches are wrong approach" or "your objections are not valid" is true for everyone.
One example are code reviews.
> If the code review culture is strong in your team then it can very well be done on the commit to the main branch.
Personally I find this inconvenient. Reviewing a single commit does not show me the bigger picture. Let's say I refactor some code before adding a new feature. Refactoring is in a single commit, but to see whether this refactoring makes sense, it's better if the reviewer sees the next step, then they can understand better why I refactored it in this particular way.
> The main thing to improve here is probably not the branching model, but the code review process.
Maybe this is true. Maybe my way of thinking about code reviews is wrong. However, again, I feel it's a matter of preference. I tried both ways and I certainly prefer reviewing the whole feature than single commits.
One more problem I find with trunk-based development: it happened to me before that a developer did something completely wrong. They misunderstood the requirement, they misunderstood the code - it happens, the world's not perfect. With feature branch I'll just ask developer to start from scratch. `git branch -D` and that code is gone. With trunk-based development the code is already in the master branch, and while it obviously can be changed or reverted, it's already there, people already have pulled this code, they modify this code, they look at it and try to understand it, they try to figure out why it's there.
Again, I'm not saying here that trunk-based development is a bad idea. It might be working for you, it might not, everyone's different. I believe the article explains the benefits of trunk-based development pretty well, I wish though it wasn't presented as an objectively superior alternative to feature branches.
We use short-life topic branches for each feature, each bug fix, each infrastructure-as-code change, each documentation update, etc.
We prefer short-life topic branches vs. committing to the `master` branch (or equivalent `develop` branch) because of multiple reasons:
1. A topic branch gives good code isolation for distributed development: I can share a topic branch with you, directly, without needing to merge to master.
2. A topic branch makes it really easy to do many kinds of popular git workflows; this includes many popular CI servers, git automation scripts, git aliases, etc.
3. A topic branch is great for integrating early and often into code reviews, and also with master. For example, we use a feature branch that uses feature toggles, and we can do CI/CD to propose changes to master as often as we want, and we can rebase the topic branch as often as we want. We can choose whether a repo will prefer merge, or rebase, or rebase with preserve, and between elided linear history or real graph history.
4. We favor automatic integration, meaning when we push a topic branch, and the reviews are all good, and the tests are all green, then the CI/CD does an automatic integration process, including an automatic deploy. When the topic is integrated, then the topic branch is deletable.
5. Finally, I've tried the "TBD just merge to master" approach with multiple teams, and inevitably it turns out to be significantly harder and more complex to coordinate, especially at speed, scale, and with more stakeholders.
If you're interested in git, you can see some of the git alias topic branch commands that we use:
https://github.com/GitAlias/gitalias/blob/master/gitalias.tx...
The advantage of trunk based development would be that the feature gets potentially more testing. Same goes for interactions with the main line code - if feature development breaks the core in subtle ways, it will be noticed earlier using trunk based development.
A "feature branch" means something much different to my teams. A feature branch for us is a short-life topic branch, and typically for one use case, kanban card, etc. We use short-life topic branches for each feature, each bug fix, each infrastructure-as-code change, each documentation update, etc. We prefer short-life topic branches vs. committing to the `master` branch (or equivalent `develop` branch) because of mu…
All teams I've worked for in the last few years basically did this.
Although we never distinguished between features/topics explicitly, the proces would be the same.
Having one branch per story is just very simple from a management perspective; it aligns user requirements, graphics design, development, code review and deployment into one trackable unit.
Stories are never too large so in practice code branches don't exist for too long, a couple of days usually. If two or more developers work on the same story they'll use the same branch. If two stories are code-wise interdependent they'll reuse each other's branches as they see fit.
The same thing happens if you have someone who just "disappears" for a day or two and effectively has a feature branch. You need to have discipline on your team to push often (I like to push at least every 20 minutes).
I also tend to think that continuous deployment with TBD is risky. It depends on how good your automated acceptance tests are, but I tend to like to do a manual sanity check before deployment. It's a lot easier when you are not working on a moving target.
Finally, sometimes you just have to break something in order to change its direction. This forces you into a feature branch if you are doing continuous deployment.
We've occasionally experimented with having an "integration branch" that acts like trunk but isn't deployed. You can then time your trunk deployments, potentially cherry picking from the integration branch. It seems like a good solution, but I've found it to be more trouble than its worth most of the time.
Having said all that, my preference would be to abandon continuous deployment and instead have regular deployment (say once a week or once every 2 weeks) with a mechanism for hot patches. Then force everyone to work mostly core hours and have continuous integration (with commits coming in every 5 minutes or so). In my experience this has produced dramatically better results than feature branches.
However... On my team it is impossible (not least because I'm 9 time zones away from the majority of my team mates). So feature branches are an acceptable second best.
I like TBD -- a lot. However there are a couple of problems with it. If your team is not collocated in a time zone then you'll one one guy (me, for instance) who will push 8 hours of development into trunk without anyone else getting a chance to look at it. The same thing happens if you have someone who just "disappears" for a day or two and effectively has a feature branch. You need to have discipline on your team t…
That sounds extreme to me. What kind of development do you do that makes this possible? I rarely finish something within 20 minutes. Often, I'm thinking about the right way to do something for a day or longer before I decide to push some results. (UPDATE, before I even start to write some code!)
I guess the main advantage of feature branches is that you can easily drop them if it turns out the feature was a bad idea or too hard to implement. The advantage of trunk based development would be that the feature gets potentially more testing. Same goes for interactions with the main line code - if feature development breaks the core in subtle ways, it will be noticed earlier using trunk based development.
When you do checkpoint regular releases done often, you get a chance to smoketest and block a release. Automated smoke tests only go so far in fixing this - if you could cheaply, reliably and completely fully automate testing, everyone would already do that.
About the only way to do continuous deployment is to not deploy into production but use lagged deployment practice...
Someone forgot about continuously merging master to feature branch to keep the merge simple.
If everyone is working in a feature branch and only bug fixes are done in master, then most of the merges will be simple. However, when a feature is done and merged to master, all the feature branches need to merge the work and that merge will be disproportionately difficult. kennethh posted a link that explains this well: https://martinfowler.com/bliki/FeatureBranch.html
With a big merge, others have time to inspect and know of breaking changes. with million tiny merges (or working on trunk, same) you either freeze change due to risk of breakage or end up with broken master regularly.