612
If "Master/Slave" terminology in computing sounds bad now, why not change it to "Dom/Sub"?
(lemmy.dbzer0.com)
this post was submitted on 20 Aug 2024
612 points (88.6% liked)
Showerthoughts
29528 readers
768 users here now
A "Showerthought" is a simple term used to describe the thoughts that pop into your head while you're doing everyday things like taking a shower, driving, or just daydreaming. The best ones are thoughts that many people can relate to and they find something funny or interesting in regular stuff.
Rules
- All posts must be showerthoughts
- The entire showerthought must be in the title
- Posts must be original/unique
- Be good to others - no bigotry - including racism, sexism, ableism, homophobia, transphobia, or xenophobia
- Adhere to Lemmy's Code of Conduct
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Is it not the main working branch? Git is a system of change not just recording change. When you start a new project, do you open a new branch or create a whole new repository? That's not rhetorical I'm genuinely curious.
No it is not. On large distributed projects for which git was designed, you typically don't directly work on main/master but you create a working branch to do your changes, and when they are ready you merge them to main/master.
There are many types of git workflows, but main/master usually contains the code that is deployed to production or the latest stable release and not some work in progress.
You have to define "project" for that.
Ah we develop the same way. There's testing then staging then prod is final review and is then finally merged to Main after documentation. Main branch is protected and merges are gated by review. There's no need for master terminology there.
Wait huge? Shouldn't Prod be the last place any changes go ?
In our environment Prod is only a holding area, the change/feature/bugfix is already approved for production, once the change is documented then the merge happens into main and Prod is consumed.
Our "working" branches are ephemeral.
Seems like what we use “RC” for (Release Candidate)
Yeah, we're trying to avoid a lot of hanging branches with no documentation so we try to prune as much as possible. So we built pruning and documentation into the workflow of the pipeline.
Great! The best I’ve been able to do is document a best practice to default to deleting the source branch on merge. I actually just now finished writing a script to list all repos with various details including the setting about deleting source branches on merge. I’ll talk to a few teams about it, then see if I can get management approval to set it for all repos (you can click to override in the merge request so it seems harmless)