Prevent creating branches other than main
2 years ago by Drew to c/programmingcirclejerk
This is obviously crazy talk, but so is keeping feature branches alive over extended periods of time. Depending on the development tempo of your project and the number of people involved, you should figure out a way to land things into main (in pieces if needed) within a few days.
Or never killing branches... I've been on projects with over 100 branches.
I had created a feature branch before leaving my previous company, completed the feature and uploaded a build for testing, after which it was supposed to be merged.
Months passed and it has still been neither merged nor rejected.
That hurts my soul.
Any CVS and SVN lovers in chat? Those were the days, eh? Got and mercurial were a mistake. Bring back the good old days 😭😭😭
/s
Back during the master/main debate I proposed going back to “trunk”, but there were too few of us old farts to make it stick.
That said, I didn’t miss subversion and CVS even a bit. They were rough compared to modern source control. I did like both hg and bazaar better than git though.
What is even the motivation for this? How do you make PRs?
That's the neat part: you don't
A joke presumably? Kind of hard to tell!
It's called "trunk based development". Look it up and watch videos about it. I swear they are stuck in the 90s yearning for CVS and SVN.
Trust me, people still call it trunk based development. Just like "agile" has many forms, trunk based development does too.
Managers will often read about some process, tech, or strategy and tout it as the solution to their problems without understanding context nor wanting to invest in what's actually required for a successful implementation. For example trunk based development should have automated testing, a deployment and a fallback strategy. And if you're working on something with hefty features that you can't slice, feature flags or something similar are probably required. Not giving the team time to develop a strategy to implement that is a great way to mess up a product.
I dunno about NostraDavid, but I don't object to main as a name. It's an obviously better name (let's be honest Git is terrible at naming). If it had been the name from the start it would have been fine.
The problems are a) changing the name was - and continues to be - a persistent minor pain, and b) it was changed for really really stupid reasons! Mainly the latter. It's painful when people are being idiots even if it doesn't directly affect you.
It's kind of like my objection to religion (at least Christianity in the UK). It's not really doing any harm, but it's just so stupid. (I don't blame Christians; I was raised one so I know first hand how it tricks you into belief.)
@programming.dev
Community to talk about enlightened programming takes
Rules:
- read and follow the programming.dev code of conduct
- no flamewars
- mark your unjerks
- only programming related content allowed
- link to the original source
- do not mention this community in places like hackernews, lobste.rs, or the general programming communities on Lemmy where we source jerk material from.
go to feed...
@programming.dev
Community to talk about enlightened programming takes
Rules:
- read and follow the programming.dev code of conduct
- no flamewars
- mark your unjerks
- only programming related content allowed
- link to the original source
- do not mention this community in places like hackernews, lobste.rs, or the general programming communities on Lemmy where we source jerk material from.
go to feed...
From the comments:
That's ... literally what one of my colleagues is unironically advocating for over a decade. Despite us trying to explain to him that this might work for team of 2-3 people but is really a bad idea for team of 10+ developers, 5 or so testers, POs needing guarantee that they can deploy at any time and tools like Gitlab/Github. Thankfully we overruled him few years ago
save