41–50 of 108 posts
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.
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.
[flagged]
As of February 2016, references to "slave" in documentation began to be replaced with "agent": https://issues.jenkins.io/browse/JENKINS-27268 The comment I'd make is that this appears to have been settled nearly eight years ago in this particular context, and that maybe you should give it a rest.
The good news is that "master vs mainline" was so embarrassing that even the people who push this stuff realized they overreached and have settled down since.
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…
Earlier quoted context omitted.
Seems strange. Sometimes we’ll have feature branches that are made up of different parts, with different devs collaborating to build those parts out. For this I don’t see a way around having some staging branch with two devs sending PRs to before you work out all kinks and merge the staging branch back into main
This is the hardest part about trunk based development - changing your way of thinking. Everything needs to be decomposed into much smaller changes, and you need to think about the impact of each of them being deployed into production (since that will happen). New features should exist behind some kind of feature gating or dial-up capability, or a new API version with restricted access, etc. That seems painful but it…
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. 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. Using trunk would resolve it, but would also of course introduce other issues.
When splitting up a product into multiple repositories a lot of new problems are created. Every sub-project needs to be testable completely independently and then in a later stage integrated with the other components and tested again.
With multi-repository it's much harder to isolate a change over multiple components into one PR and test those changes together. Instead they develop separately and after some time many of those changes are tested together. It's just making the feedback loop longer without any added value.
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.
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"…
Trunk-based development also doesn't mean that you are not allowed to create branches.
And you can still check out an older version.
[flagged]
[flagged]