Hacker News Reader

Comment by ivraatiems | Hacker News Reader

I'm confused by this. I've never worked in an organization where "commit directly to main" would get you anything but in a ton of trouble.

Is that a normal/common practice for anyone here?

View on HN

Pretty common if you ask me. Especially, if you work in companies where pair programming is a thing, you do TDD (or at least write tests), have feature toggles, and a CI/CD pipeline in place.

Btw, if you want to know more about trunk-based development: https://trunkbaseddevelopment.com/

Super common. I’m not sure how that’s any different than teams who create a PR, beg someone to review it, they glance it for 3 sounds and leave a “LGTM!” approval so you can finally merge to main.

Same result, whole lot less performative bullshit.

We use branches and reviews for large changes. Small scope changes go directly to main. If it breaks, we rollback and tell that person to stop breaking things.

What if a pr was actual code review and not performative bullshit?

That doesn't mean you have to block the merge to main. You can do code reviews on the trunk, you can do it on already merged PRs and you can block on the PR until the code review is done. The latter brings a lot of downsides, which we as developers seem to be taking for granted. It looks like developers can't even imagine not working with Github style pull requests.

It depends on your project, but i prefer having a coherent view on all changes on one branch, instead of 20 branches and one outdated trunk.

It only breaks in staging, right? I hope you're not running anything in the physical world like Uber or Tesla.

`lgtm` is a legit typical outcome. biasing to approving, in many companies & software setups, is a great default. ex: we might `lgtm`, or make comments that are suggestions for follow-on PRs without blocking the current.

However... it's also incredibly hard to self-edit and accurately `lgtm` yourself

4 eye principle brings a lot of redundancy. Even if someone just goes lgtm, it prevents people from pushing a change that no other person has seen which means if the original engineer is on holiday you still have someone who is somewhat familiar with the code.

So you don't do pair programming and you don't have some testing/quality assurance process in place?

It works fine for a small team (probably three people or fewer), especially when you're still building the product and don't have it deployed yet. Breaking things isn't a major concern at that point. After people have started using your code, or if you hire a bunch of developers, then you probably want to be more careful.

Actually, it works really fine with 30 developers as well. Even from different companies. Did that a couple of times and it was always way better then having a lot of long living branches. I'd say branches don't scale with team size.

In the end it's a matter of your project and trust. If you're doing an in house project it's great.

I find it strange how many people can't even imagine working like that, when it does work so well. It's probably a thing you have to experience to see.

I've seen this approach on smaller teams working at private companies in less-regulated industries. Think a team of 3-5 devs working at a small company.

At publicly traded companies or in regulated industries, yeah, your compliance will require you to disable merging without at least one approval.

If you serve clients of any size, you probably need to have merge approval

Yes, in loads of shops. See trunk based development.

Trunk based development involves creating short lived feature branches, not committing directly to master. At least I haven't seen it done that way.