Merge conflicts
-
We use main now
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.
-
We use main now
I'm glad I'm not part of "we"
-
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?
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”
-
We use main now
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.
-
This post did not contain any content.
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
mainbranch. 🫠 -
I'm glad I'm not part of "we"
Why do you care
-
This post did not contain any content.
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 offdeployed -
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?
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.
-
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.
wrote on last edited by [email protected]similarly, I use
masterandstable, it helps that PRs default tomaster, making changes tostablemore intentional. -
Why do you care
Because this whole discussion is fucking stupid. There was no good reason for a change.
-
Oh god please tell me this isn't a real thing
I could. But I'd prefer not to lie
-
Oh god please tell me this isn't a real thing
Still in school?
-
This post did not contain any content.
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..."
-
Still in school?
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!
-
Because this whole discussion is fucking stupid. There was no good reason for a change.
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
-
Because this whole discussion is fucking stupid. There was no good reason for a change.
You doth protest too much. Wonder why
-
This post did not contain any content.
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.
-
This post did not contain any content.
Main* branch.
Don't want to sound racist
-
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 offdeployedWe 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.
-
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.
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
