Hacker News Reader

Comment by hashkb | Hacker News Reader

Yes, this is what I think of as CD. Hiding work that isn't ready (or work that may never make it in front of users) behind a flag on prod sounds like extra work for no gain, to me.

View on HN

The gain is early integration. If you have more than one branch going on at the same time, they can diverge quite significantly, and merging can cause bugs, or sometimes more work. If you only ever have one feature branch at a time, you might as well be doing trunk based with manual deploys to prod.

Rebase early and often and this isn't an issue. Some see this as a chore, but I view it as taking advantage of the tool's power. You resolve the same set of conflicts as you would merging, but (as you say) earlier.

Edit: I don't think anyone was trying to imply a single allowed feature branch at a time; we can probably all easily agree that's basically no different than working on master.

Yes, rebase early and often works great. But if your branch includes a major refactor, your going to find yourself editing others code to get your rebase to work. That just increases your own scope. But yes, rebase often is often a very viable strategy. In practice though, I find very few that actually do it because it becomes painful when your branch lives too long simply because business isn't ready to ship something

Rebase is evil.

Can you explain how a repo with dozens of feature flags triggering greatly different code paths, and invisible to the source code management system, is an improvement on feature branching?

How would I use git bisect with a bunch of flags to a composite of build systems?

Reply on news.ycombinator.com