4 ms·

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/com

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?

lijok 3y ago
Yes, in loads of shops. See trunk based development.
- perryizgr8 3y ago
  Trunk based development involves creating short lived feature branches, not committing directly to master. At least I haven't seen it done that way.
  - lijok 3y ago
    You’re describing scaled trunk based development TBD works on main, or “trunk” as described in the spec
    - izacus 3y ago
      Can you list some shops that follow this.... "spec"?
      - lijok 3y ago
        Scaled TBD or TBD?
  - DLion 3y ago
    You are describing scaled trunk-based development, not trunk-based development See https://trunkbaseddevelopment.com/ https://trunkbaseddevelopment.com/ to know more about it
hipadev23 3y ago
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.
- StreetChief 3y ago
  What if a pr was actual code review and not performative bullshit?
  - buster 3y ago
    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.
- esafak 3y ago
  It only breaks in staging, right? I hope you're not running anything in the physical world like Uber or Tesla.
- lmeyerov 3y ago
  `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
- bootsmann 3y ago
  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.
dharmab 3y ago
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.
- SkyPuncher 3y ago
  If you serve clients of any size, you probably need to have merge approval
DLion 3y ago
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/ https://trunkbaseddevelopment.com/
Tommah 3y ago
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.
- buster 3y ago
  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'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?

lijok 3y ago

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

perryizgr8 3y ago
Trunk based development involves creating short lived feature branches, not committing directly to master. At least I haven't seen it done that way.
- lijok 3y ago
  You’re describing scaled trunk based development TBD works on main, or “trunk” as described in the spec
  - izacus 3y ago
    Can you list some shops that follow this.... "spec"?
    - lijok 3y ago
      Scaled TBD or TBD?
- DLion 3y ago
  You are describing scaled trunk-based development, not trunk-based development See https://trunkbaseddevelopment.com/ https://trunkbaseddevelopment.com/ to know more about it

hipadev23 3y ago

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.

StreetChief 3y ago
What if a pr was actual code review and not performative bullshit?
- buster 3y ago
  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.
esafak 3y ago
It only breaks in staging, right? I hope you're not running anything in the physical world like Uber or Tesla.
lmeyerov 3y ago
`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
bootsmann 3y ago
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.

dharmab 3y ago

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.

SkyPuncher 3y ago
If you serve clients of any size, you probably need to have merge approval

DLion 3y ago

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/ https://trunkbaseddevelopment.com/

Tommah 3y ago

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.

buster 3y ago
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.