I work at a place that has a few very large code bases, we use trunk-based. I will never go back, "what is your git workflow?" Is a question on my list of things to ask potential employers now and the only good answer is "trunk". So much mental load is wasted on these other strategies.
Google and Facebook both use trunk based development for nearly all code at both companies.<p>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 literal copies of all the files for multiple years. I don't think revision control is the right place to solve that problem though, because there were no clear service boundaries to decide what things to pin, we just did it in an adhoc way.
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).<p>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 beyond Sapling now that Phabricator is no longer supported.
TFA advocates strongly against long-lived branches, which I understand and agree with, but with one exception: major/LTS versions should have their own <i>branch,</i> so that hotfixes can be cherry-picked from <i>main</i> (or, rarely, applied directly to the major version branch.
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.<p>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 <i>eliminate</i> merge hell, but it does localize it, making it a lot easier to resolve conflicts without accidentally undoing somebody else's work.<p>It's especially well-suited for any projects that are in constant-iteration mode, where there's a steady stream of bugfixes and new developments getting deployed daily (or even multiple times a day).<p>You can even manage longer-lived branches after a fashion: the cleanest pattern seems to be to capture your changes into a patch, revert your branch to the commit immediately before your changes, merge/rebase main, then apply your patch on top. This is bad and lame because it rewrites history and requires a force push to get it into the remote, but it's also nice because it keeps your changes at the tip of the branch and makes review a bit easier in e.g. GitLab.<p>Every small shop I've worked with that has tried to use more complex branching models eventually hoses the repo and ends up burning a lot of dev hours one day trying to make sense of a git log that looks like a diagram of network sorting.
I've been pushing and using trunk for years. To think someone looked at the graph for git-flow and said "yes please" is madness.<p>That said, trunk-based is probably not great if you actually do need to support multiple versions of a piece of software simultaneously.
Could use a (2015) - according to the front-matter on the repo (in the master branch, natch). It's been posted here a number of times, it was particularly popular the first posted time in 2017[0] (199 points, 208 comments).<p>[0]: <a href="https://news.ycombinator.com/item?id=13514289">https://news.ycombinator.com/item?id=13514289</a>
I’ve been pretty happy with trunk-based development in my job. It’s simple and reliable. I don’t miss alternatives in any way.<p>A significant amount of Git-isms are based around Linux kernel needs. Which is great. But closed source and typical open source needs are pretty different, and much simpler.
This site has developed a lot of content without seeming to directly address the major concerns anyone coming from git flow will have. For example, their code review page does not really address how github and gitlab are both set up to support branch based review, and trunk based review is a lot harder when using those tools. Similarly, I poked around and figured out what they recommend for hotfixes, which is just fix it on trunk and cherry-pick the commit. That works sometimes, but anywhere with infrequent releases (like regulated environments or shipped software) may find that pretty painful. I suspect I could raise more issues if I put more energy into it, but it's hard to want to, given how the content is presented.<p>Overall, this site reads like someone who's so convinced they're right that they don't bother to take other viewpoints seriously enough to actually refute them.
I like TBD. I've always found the difficulty was in getting people to use feature flags, and then also managing those flags.<p><a href="https://trunkbaseddevelopment.com/feature-flags/" rel="nofollow">https://trunkbaseddevelopment.com/feature-flags/</a>
We’re considering this at my org. We’ve got a distributed backend with about 2 dozen repos, with a big web of dependencies between them.<p>When you need to make a breaking change to one that is depended on by a lot of the other repos, it can be incredibly tedious to fix all the downstream effects.<p>Using trunk would resolve it, but would also of course introduce other issues.
How does this look like when you have multiple active versions of an application? In some cases there are apps deployed in different environments (or to different clients) in different versions and having a single place to make all commits is not feasible.<p>How do things that have LTS versions in parallel with "regular" versions organize?
There's a workflow where you commit to each release branch?<p>I genuinely did not know that. I thought working on individual branches, merging to master, and then cutting the release branch from there (to merge back into master if any changes were found during testing) was the only major way people actually did things.
No thanks.<p>I've worked on teams using trunk based development before and I ended up being the one having to fix other people's messes, deal with them losing work, and the absolute hell of trying to find where a bug was introduced.<p>The only people I really want on my team are those that understand Git. And even when there are team members that don't understand Git, I sure do and can pretty easily un-eff any situation someone gets themselves into.<p>Seriously, Git is actually simple and it should be a fundamental CS class taught at all universities.
It's the same fucking thing. You just painted each track different color and thickness.<p>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?<p>Same fucking thing, wrapped in execucrap.