I’m a purist. The stable and persistent main branch, regardless of what you want to call it, should always and only ever be exactly the same as the code that’s currently deployed to the production server. Generally the only exception is for the short duration between a push and deployment under normal circumstances.
But every job I’ve ever had, there’s at least one maverick who knows git way better than anybody else and is super advanced, so they do their own thing which is totally better in a million different ways but essentially fucks everybody else over. And I’m not even here to say they aren’t smarter than the rest of us and I’m sure that somehow their process is better than what we currently do. But with version control, my anecdotal experience has been that the most important things for running smoothly are: consistency and having everybody on the same page. Process doesn’t need to be perfect, maximally efficient, bleeding edge, etc to achieve that.
We have a
deployedbranch. It doesn’t get merged intomasteruntil it gets reviewed… the technical debt got too big so it never gets reviewed and we just keep branching offdeployedjesus
He can’t help you. Y’all need Linus.
What’s he going to do? Drop commits? /s
He drops commits but keeps on forgetting
What he wrote down, CI goes so loud
He tags the release but it won’t go out
E2es choking now, pipeline’ jokin’ now
Clock’s run out, time’s up, over, blaow.
Yes, we’ve had first
masterbranch, but what about secondmasterbranch?Ah yes, by the end of the week we will have achieved full apotheosis:
master-final-v3-deployed-2025_08_01-usethisone




