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.
It gets even worse — convoluted GitHub action templates that no one can debug, attempting to impose on every newly created repository.
The projects at my company that use the complicated actions with gitflow are slower and less efficient.
When I release a service at my company I just do trunk based ,but I have to redo the GitHub actions initially to save it from itself. Over the long run it saves me a lot of time.
Trunk based development fits well with well defined sprints and continuous integration but I'm not sure that not committing into a release branch is the best strategy when the releases are kept small and the development continues with full force after the release is formed. In my experience it makes sense to fix found bugs in the release branch and then merge them back - expectation is that these fixes are really minor as the release is not created before mainline development has been validated and is ready for the release. No new features should be added into the release branch, only bug fixes. In such case merging back small release branch changes has not proven to be any pain at all.
I'm not really sure what the mental load is but having gone to Trunk felt like a mistake, I don't know if it was just designed wrong at the last place I worked at, but we have to do more than normal per release, and I'm not a fan of squashing commits, it means I can't just go back to a branch and merge the development branch back into it, I have to check out a brand new branch. I also preferred having "master / main" and "development" because if QA claims there's a bug introduced during the development phase, you can figure out if it's already in the main production branch or if it truly was introduced during development. Which is something you can't really do with "trunk based development" it's like all these people who praise it should just switch to SVN instead?
If you deploy your main branch on every commit, there is no "development phase". You should deploy more frequently and work on smaller changes. So when your QA (or a user, or a monitoring alert) finds a bug, you are pretty sure that the bug was introduced recently.
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 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 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.
Imho this is an emergent property from the fact that most folks don't understand what they're doing. If they did, then every time Mr Dilbert pointy head dude comes up with some nonsense process, they'd explain why it isn't beneficial. Instead most of the time everyone nods. Lawyers don't have crazy people telling them how to write contracts. Doctors don't have people telling them how to saw off legs. Teachers kind of do have dumb people telling them how to teach though.
Someone on HN loudly proclaimed that requiring a code review before merging was antithetical to "trunk based development." He shared the link in OP a dozen times as "proof", but I couldn't find anything in there suggesting such a thing. I also know both Google and FB require code reviews.
Was the guy just totally full of it? Because honestly I wouldn't touch any "strategy" with a 10 foot pole that discourages pre-merge reviews.
There didn't use to be any mention of pre-merge reviews in that website. In fact, the text in the website used to be pretty emphatic against any branching whatsoever.
I have known and worked with Steve Smith (the only "friends" mentioned in the website [0] - hi Steve! :D ) for years and we had many discussions about the merits of short-lived branches for peer review. Myself and a few others have argued that you can have pretty much all the benefits they were looking for with TBD without the draconian "always push to trunk" rule. It just takes a bit of discipline and communication, but to be honest I think the draconian one needs even more of those if it is to succeed.
I'm happy that the website has been updated since (it's been at least a few months, maybe even a couple years) to acknowledge and "allow" that strategy.
Post-merge reviews obviously help with the same goal of having very little work stuck in WIP. But it's a 80/20 kind of goal, not all or nothing. Post-merge reviews are probably only worth it when you can trust the developers to not screw up too much and to broadly agree on quality standards.
I think their point is more that the usable scale of teams/codebases is not limited by trunk based development. Which that is pretty ample evidence of.
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 beyond Sapling now that Phabricator is no longer supported.
I agree with what you said but I'd further refine it by saying not just having testing and CI but actually having "high" test coverage and tests that actually test the code.
Which of those three tools works best on GitHub? Ideally without paying (not that I mind paying but it’s impossible to get the approval for some niche tool like this)
TFA advocates strongly against long-lived branches, which I understand and agree with, but with one exception: major/LTS versions should have their own branch, so that hotfixes can be cherry-picked from main (or, rarely, applied directly to the major version branch.
That's right. It's important to be able to reproduce released builds with minor patches, and branches are the right tool for that job. But resist the temptation to fix that CVE on the release branch and then upstream it, because then you're once again doing branch development, treating trunk like a garbage can.
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 accidentally undoing somebody else's work.
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).
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.
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.
A lot of the rebase/merge hell I've seen has been more or less resolved with the introduction of a merge queue. Granted, there are other issues that crop up (notably, flaky tests go from being an annoyance to life-threatening) but at least bigger changes don't get blocked and stay blocked.
I'm not sure if any branching strategy helps supporting multiple software versions simultaneously. There is a reason why "rolling releases" are the default now.
For a short while it may work to just merge bugfixes to older versions. But after a while the changes to older versions need to be done independently. Implementing a fix for three versions will just take three times longer than for one version very soon.
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).
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.
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.
Readit News
The projects at my company that use the complicated actions with gitflow are slower and less efficient.
When I release a service at my company I just do trunk based ,but I have to redo the GitHub actions initially to save it from itself. Over the long run it saves me a lot of time.
Same if I say "I'm not doing TDD, because I think it's bad". I've seen so many people claiming to do TDD, but none of them ever actually did.
Trunk-based development also doesn't mean that you are not allowed to create branches.
And you can still check out an older version.
And if QA finds something, there's nothing preventing testing another release to figure out where the issue is. Git bisect is useful there too.
There are plenty of issues with git, but trunk development isn't really one of them.
Deleted Comment
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 have always been happiest in a trunk-based dev model, but in many orgs it is heresy to even mention it.
Was the guy just totally full of it? Because honestly I wouldn't touch any "strategy" with a 10 foot pole that discourages pre-merge reviews.
I have known and worked with Steve Smith (the only "friends" mentioned in the website [0] - hi Steve! :D ) for years and we had many discussions about the merits of short-lived branches for peer review. Myself and a few others have argued that you can have pretty much all the benefits they were looking for with TBD without the draconian "always push to trunk" rule. It just takes a bit of discipline and communication, but to be honest I think the draconian one needs even more of those if it is to succeed.
I'm happy that the website has been updated since (it's been at least a few months, maybe even a couple years) to acknowledge and "allow" that strategy.
[0] https://trunkbaseddevelopment.com/contributions/
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.
They both have extensions for vscode as well that makes it easier to manage stacks.
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 accidentally undoing somebody else's work.
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).
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.
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.
That said, trunk-based is probably not great if you actually do need to support multiple versions of a piece of software simultaneously.
For a short while it may work to just merge bugfixes to older versions. But after a while the changes to older versions need to be done independently. Implementing a fix for three versions will just take three times longer than for one version very soon.
[0]: https://news.ycombinator.com/item?id=13514289
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.