31–40 of 108 posts
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.
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.
[flagged]
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.
[flagged]
Also, for what it's worth, Jenkins changed their terminology to use "agent" instead of slave in 2020 [0]. These efforts might seem futile in isolation, but they add up over time.
[0] https://www.jenkins.io/blog/2020/06/18/terminology-update/
Earlier quoted context omitted.
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…
Some recent discussion: https://news.ycombinator.com/item?id=34733805
Earlier quoted context omitted.
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.
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
That seems painful but it's less painful than merge hell or deploying a change with a massive delta to production and needing to roll it back and unpick what went wrong.
[flagged]
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.
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.
[flagged]