Merge conflicts
-
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.
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.
-
We use main now
This is the way.
-
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 offdeployedWell, 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.
-
Because this whole discussion is fucking stupid. There was no good reason for a change.
The good reason was that it bothered some people. "Main" is two fewer letters, so it's even more convenient to type. So what's the problem?
-
I like the actual look of the word "main" more than I do the word "master". I think it's because it looks like a neat semi-circle
It also makes more sense.
-
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.
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....
-
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 offdeployedwrote on last edited by [email protected]Yes, we've had first
masterbranch, but what about secondmasterbranch? -
Because the argument is stupid. Much like pointers not being a good term to use because it’s rude to point. Or man pages being sexist.
wrote on last edited by [email protected]I've never heard that pointer bullshit at all. Can you link it?
"Man" for "manual" is just an antiquated term kept around by Unix curmudgeons. "Help" is much better as it requires no explanation and conveniently is automatically abbreviated to its full name. It's the common term used in most other systems that aren't linux.
'Man" isn't sexist, it just sucks.
-
The good reason was that it bothered some people. "Main" is two fewer letters, so it's even more convenient to type. So what's the problem?
European here. I'm a supporter of civil rights and against racism and so on, but that controversy with master vs main for me is just a silly us american controversy, as master has more meanings that just owner of a slave (and in this context, it's not even related to that master-slave thing as used to be in hardware naming).
The issue is that kind of (in my pov, unnecessary) change caused an outage in my company as some k8s objects changed its label because of this kind of controversy, and some of our selectors were not ready for that change, as iirc this happened in a minor version upgrade. We also had to invest development hours to update internal tooling to support that change too (and I bet, a lot of companies did the same).
-
"Trunk" is nice because it fits with "branch" in the tree metaphor, but "main" does have fewer letters.
Yep, the metaphor would be good if git was a tree but kt isn't. It's very rare to have a real tree branch merge back into the trunk. Would it even still be called a branch after merging?
-
Because the argument is stupid. Much like pointers not being a good term to use because it’s rude to point. Or man pages being sexist.
What's stupid is that people like you argue about a branch name instead of just cede the point as if it costs anyone anything to
-
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.
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.
-
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.
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.
-
Yep, the metaphor would be good if git was a tree but kt isn't. It's very rare to have a real tree branch merge back into the trunk. Would it even still be called a branch after merging?
If it's not a tree, why call it a branch? Maybe branch doesn't make any sense either. Maybe none of this makes any sense! Oh my God, what are we even doing here?!?! Ahhhhhhhhhhhh!
-
European here. I'm a supporter of civil rights and against racism and so on, but that controversy with master vs main for me is just a silly us american controversy, as master has more meanings that just owner of a slave (and in this context, it's not even related to that master-slave thing as used to be in hardware naming).
The issue is that kind of (in my pov, unnecessary) change caused an outage in my company as some k8s objects changed its label because of this kind of controversy, and some of our selectors were not ready for that change, as iirc this happened in a minor version upgrade. We also had to invest development hours to update internal tooling to support that change too (and I bet, a lot of companies did the same).
Agree with this. Never changed from master as it would cost the business money to do so (and involve a ton of headaches) for no reason. Thankfully the whole dept agreed on that.
-
What's stupid is that people like you argue about a branch name instead of just cede the point as if it costs anyone anything to
Actually this cost a lot of time and money. Even today I have to take an extra step to see if master or main is use . Before it was standard.
Curse this
-
Actually this cost a lot of time and money. Even today I have to take an extra step to see if master or main is use . Before it was standard.
Curse this
If this was hard for your company to change, you did things wrong. I work with git everyday and I've no idea what extra step you mean. Git software of all stripes will show you front and center what branches exist and what's default. People pissed about this just wanna whine and they can downvote me a million times if they want
-
Yes, we've had first
masterbranch, but what about secondmasterbranch?wrote on last edited by [email protected]Ah yes, by the end of the week we will have achieved full apotheosis:
master-final-v3-deployed-2025_08_01-usethisone -
I'll never understand why we didn't just go back to saying "trunk".
Elephants are an endangered species!
-
Because this whole discussion is fucking stupid. There was no good reason for a change.
It's shorter. Also "master" is especially egregious as as it requires the last 5 letters to be typed with the same hand, while "main" makes better use of bimanual parallelism.
