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.

[–] zorro@lemmy.world 1 points 4 days ago

All merges to main auto deploy to staging. Tagged merges to main also go to production.

[–] zarkanian@sh.itjust.works 13 points 1 week ago (1 children)

What are the maverick git workflows? When I had a web developer job, it all seemed pretty straightforward and I can't imagine doing it some other way and it being a good idea.

[–] dejected_warp_core@lemmy.world 13 points 1 week ago (1 children)

What are the maverick git workflows?

Okay, but be advised: this is how we start fights. Depending on where you're coming from, everyone else is doing it wrong. Keep that in mind. That said, I want to have a discussion with you and others, if possible.

If we assume that a GitHub PR, or GitLab MR, workflow is "typical", then the oddballs I know of are:

Geritt - It endorses a unit of review/work that is always exactly one commit. I have some strong opinions about why this is a thing, why it's not great, why you shouldn't if you're not Google, and how Google got here, but that's a whole other discussion. It's a super-polarizing approach to Git in general.
Gitflow - takes the usual branching strategy of MR/PR work and dials it up to 11. This too is polarizing, as the added complexity can be a bit much for some folks.

IMO, a lot of the trouble we run into with Git is largely due to training problems. Also, one has to architect the git space to fit the company, culture, and engineering needs at hand. This means planning out what repositories you need, how you're going to solve CI/CD, what bar for code review is needed, how to achieve release stability, and how to keep the rate of change steady and predictable. To do any of that, everyone needs to learn a bevy of git commands to do this well, and not enough companies bother to teach them.

[–] squaresinger@lemmy.world 3 points 1 week ago* (last edited 1 week ago)

Gitflow is the usual branching strategy. It's not dialed up to 11, it only specifies precisely what to merge to where and from where.

The real mavericky thing is when someone uses cherrypicking in combination with squash merges thus breaking branch compatibility.

I have been the git specialist in the last few teams, and thus I'm the one who has to clean that up every time. Not because it's hard, but because nobody can be bothered to actually learn git.

Edit: The other thing is to use rebases instead of merges. Yes, they make for a much nicer git history, but they also tend to break everything in the process when the rebase is sufficiently large.

[–] bier@feddit.nl 10 points 1 week ago

I can see that working well especially in a project where you can push to production fairly often, our project only has 2 moments every year where new features can be pushed to production. The exception is major bugs and security patches.

Anyways our main branch is always ahead of production. New features are branched of main, and can only be merged when the entire test suite passes, this is unit tests, integration tests and automated functional tests take about 5 hours (this project has been live since 2010).

We make release branches so we can always use them for bugfixes etc.

I think it kind of depends on a project what works best. For us a main branch that is only updated twice a year wouldn't be the best way, I think.

[–] spongebue@lemmy.world 5 points 1 week ago

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

Pretty sure that's me at my job, but I take your approach too.

I just have lousy coworkers who keep a bunch of stale branches open with no real maintenance plan. Thankfully I kind of work in my own bubble and generally avoid that jungle

[–] potoo22@programming.dev 76 points 1 week ago (4 children)

We have a deployed branch. It doesn't get merged into master until it gets reviewed... the technical debt got too big so it never gets reviewed and we just keep branching off deployed

[–] rainwall@piefed.social 71 points 1 week ago* (last edited 1 week ago) (1 children)

Yes, we've had first master branch, but what about second master branch?

[–] mic_check_one_two@lemmy.dbzer0.com 9 points 1 week ago* (last edited 1 week ago)

Ah yes, by the end of the week we will have achieved full apotheosis: master-final-v3-deployed-2025_08_01-usethisone

[–] Quill7513@slrpnk.net 42 points 1 week ago (1 children)

jesus

[–] SeductiveTortoise@piefed.social 33 points 1 week ago (1 children)

He can't help you. Y'all need Linus.

[–] TunaLobster@lemmy.world 12 points 1 week ago (1 children)

What's he going to do? Drop commits? /s

[–] silasmariner@programming.dev 8 points 1 week ago

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.

[–] marcos@lemmy.world 17 points 1 week ago

Well, when you said "we have a deployed branch", you could just have stopped there. All the rest is just what happens after you decide to rename your master branch.

[–] ArchAengelus@lemmy.dbzer0.com 7 points 1 week ago (2 children)

We build off develop and only update master once a year or so. Our company also pays 4 V&V engineers, compared to 9 software devs.

After a release cycle, we update master. Master has never, never been built by itself.

[–] vrek@programming.dev 9 points 1 week ago

Depends on the field you're in. At my previous company to release a new system for internal use only I had to go through 19 validations(each one 50-100 pages of manual tests). None of it had real source control except uploading final zip of files(no source code, just the enable files).

I wrote all the files, wrote all the test cases, wrote all the documentation, executed everything and wrote most of the reports. They just fired me last week so hope they have fun when they need to update something....

[–] mobotsar@sh.itjust.works 8 points 1 week ago* (last edited 1 week ago) (1 children)

I'm a software engineer, and I don't even know what a v&v engineer is.

[–] Yoddel_Hickory@lemmy.ca 5 points 1 week ago

Verification & validation

[–] theunknownmuncher@lemmy.world 52 points 1 week ago (2 children)

Oh god please tell me this isn't a real thing

[–] SkaveRat@discuss.tchncs.de 32 points 1 week ago

I could. But I'd prefer not to lie

[–] SpaceNoodle@lemmy.world 14 points 1 week ago (1 children)

Still in school?

[–] locuester@lemmy.zip 23 points 1 week ago (1 children)

I’ve been a dev at 8 places over 28 years and have never heard of this level of incompetence since git came along. Prior to git, with cvs, svn, tfs, vss - yeah, lots of incompetence because the tools sucked. Git solves all those problems tho!

[–] SpaceNoodle@lemmy.world 11 points 1 week ago

The real problem is stupid/lazy people, which no amount of tooling can address.

[–] gibson@sopuli.xyz 25 points 1 week ago (18 children)

We use main now

[–] Dave@lemmy.nz 52 points 1 week ago (1 children)

Can we get a meme about calling it main, effectively master but not granting it the title of master? That's where I thought this one was going.

[–] BatmanAoD@programming.dev 11 points 1 week ago

Same

[–] thejml@sh.itjust.works 5 points 1 week ago (1 children)

Same here. Though it makes sense as we also cut a “release” branch that aid what goes to production and it’s behind protections against rogue PRs/commits so devs can’t just push there, the process must be followed. “Main” is for devs. “Release” is for prod. “Master” didn’t really jive with that layout so it’s gone.

[–] eager_eagle@lemmy.world 7 points 1 week ago* (last edited 1 week ago)

similarly, I use master and stable, it helps that PRs default to master, making changes to stable more intentional.

load more comments (16 replies)

[–] Ephera@lemmy.ml 13 points 1 week ago

I currently have to do a deployment at $DAYJOB and recently, I made a larger change which is completely broken, but also it's slightly less broken than before, I think, so we do actually have that on the main branch. 🫠

[–] sirico@feddit.uk 12 points 1 week ago* (last edited 1 week ago)

We use main this has been reported to hr

[–] marcos@lemmy.world 10 points 1 week ago (3 children)

I mean... Yeah, if it's in production just merge with its data. What sense does it make to even put another branch in prod?

[–] Gullible@sh.itjust.works 7 points 1 week ago

Might just be a workflow thing with a small group or singular dev. Sense is largely irrelevant in the face of “I’ve been doing it this way since 15 years before github came online”

[–] oce@jlai.lu 4 points 1 week ago

It could be a temporary hot fix to pass some issue in production, but could break other things if left longer. So better to revert it after the big issue had passed and take more time to work on a proper solution.

load more comments (1 replies)

[–] NigelFrobisher@aussie.zone 4 points 1 week ago

Just do TBD.

[–] sgibson5150@lemmy.dbzer0.com 3 points 1 week ago

Seals are Good has ruined me. I read all this in that channel's voices."The Twi'lek thinker Thom Ashobbes outlined that the first priority of government..." 😄

load more comments