Merge conflicts
-
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 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.
-
This post did not contain any content.wrote last edited by [email protected]
We use main this has been reported to hr
-
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?
It's very rare to have a real tree branch merge back into the trunk.
Not rare, but uncommon. Not sure if there's a Lemmy equivalent but r/treessuckingonthings shows trunks absorbing all sorts of things including branches
-
This post did not contain any content.
Just do TBD.
-
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.
wrote last edited by [email protected]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.
-
It's very rare to have a real tree branch merge back into the trunk.
Not rare, but uncommon. Not sure if there's a Lemmy equivalent but r/treessuckingonthings shows trunks absorbing all sorts of things including branches
wrote last edited by [email protected]Yes, this is why I chose not to say that it was impossible.
Perhaps the mathematical definition of a tree is wrong in stating there should be not loops, or should change to another metaphor.
Hairs can split but never merges back again. Perhaps a split hair instead of a branch? We still trim or prune the
leavesends. What do you call the "trunk" of a hair?Edit: formatting
-
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.
All merges to main auto deploy to staging. Tagged merges to main also go to production.
