21–30 of 108 posts
I think that good tooling is a necessity to do trunk based development well - not just CI/CD and testing on PRs, but also being able to have stacks of commits in multiple PRs before landing as a whole (from ghstack, Sapling, or Graphite). Having worked at Facebook before where managing stacks of diffs was far better than GitHub, I wish that more of the improvements to the developer workflow could be open sourced beyo…
Google and Facebook both use trunk based development for nearly all code at both companies. This guide advises you to consider trunk based development if your release cycles are less than ~4 weeks. I'd suggest doing it no matter what. The only place where I've run into problems with this was managing very long term hold outs where we wanted to avoid changing user visible behavior. Instead of branches, we maintained l…
I am amazed at how much “process” developers these days have to adhere to, including complicated branching strategies plus a whole lot more. So much time wasted doing busy work. I have always been happiest in a trunk-based dev model, but in many orgs it is heresy to even mention it.
Wait so no develop branch? The utility gained by having “what’s in production” and “what we’re working on” as separated feels hard to part with.
Your local repo is the equivalent of the development branch. Yes, that means you don't collaborate with others on development branches, or go for weeks committing only to a branch. If you save up a bunch of work, dump it on the main branch, then start a new development branch that lets you escape from the integration pain of your big merge, then trunk becomes a dumping ground that nobody wants to (or can) work on.
[flagged]
So people don't merge branches to main branch, but tag releases from it. ok. But they still need to merge their changes to main first, right?
Same fucking thing, wrapped in execucrap.
Earlier quoted context omitted.
if that's the only reason for the branch, you can just as easily determine which commit is on which environment with tags
I've been working on my product for over 8 years, sometimes alone, sometimes with a tiny team. I have a mono-repo with one master branch - that auto-deploys to test - and one release branch that auto-deploys to staging. I can hot-swap my staging and production environment with the click of a button. Simple, and it allows us to deploy a hotfix of needed, and we've done some major work on master that needs to be valida…
but you have to be so so careful when you're missing up history, when it comes to db migrations and api compatibility
[flagged]
Nice to see this getting some treatment. It's been my preferred source control strategy at several places now -- both small and large, though nothing so large as Facebook. It has its limitations, but for the the 90+% of places that aren't operating at Facebook scale, it's probably the right choice. It doesn't eliminate merge hell, but it does localize it, making it a lot easier to resolve conflicts without accidental…