Earlier quoted context omitted.
Nope. Gitflow is not trunk based development.
Then what's different other than the names of the branches?
15 years later, Microsoft morged my diagram
341–350 of 427 posts
Re: 15 years later, Microsoft morged my diagram
#342LinkedIn is also a great example of this stuff at the moment. Every day I see posts where someone clearly took a slide or a diagram from somewhere, then had ChatGPT "make it better" and write text for them to post along with it. Words get mangled, charts no longer make sense, but these people clearly aren't reading anything they're posting. It's not like LinkedIn was great before, but the business-influencer incentiv…
And LinkedIn is Microsoft as well...
IMO Microsoft is right at the nexus of opportunity for solving some of the the large _problems_ that AI introduces.
Employers and job seekers both need a way to verify that they are talking to real identified people that are willing to put in some effort beyond spamming AI or wasting your time on AI run filters. LinkedIn could help them.
Programmers need access to real human-verified code and projects they can trust, not low-effort slop that could be backdoored at any moment by people with unclear motives and provenance. Github could help.
etc. etc. for Office, Outlook ...
But instead they've decided to ride the slop waves, throw QA to the wind, and call every bird and stone "copilot".
Re: 15 years later, Microsoft morged my diagram
#343Earlier quoted context omitted.
> YouTube must be absolutely flooded with this stuff. I don't know what the current upload rate to YT is, but this seems unlikely. Despite the reckless and insane energy consumption associated with generative visual and audio art forms, there's no way there's enough power available for generative stuff to overwhelm the "actually recorded digital video" uploads. Are there some niches on YT where this is true? Seems po…
If my toilet overflows and starts leaking raw sewage into my bathroom, I don't tend to then go "well, at least the rest of my house is fine proportionally". Most of these kind of videos aren't fully SORA level AI anyway, they just use ChatGPT to make up a fake story and script they would otherwise have to make up themselves, which is much faster, and increases the chances one of them gets picked up by the algorithm a…
> If my toilet overflows and starts leaking raw sewage into my bathroom, I don't tend to then go "well, at least the rest of my house is fine proportionally".
Sure. But if you live in a multi-apartment complex and someone's toilet on the far side of the complex is overflowing, you don't say "my apartment is flowing with raw sewage".
Maybe your part of the complex (YT) is drowning in raw sewage, mine is not, and I'm vaguely confident that the complex (YT) is large enough that at this point in time, most parts of it are still functioning "as intended".
Re: 15 years later, Microsoft morged my diagram
#344Microsoft employee (VP of something or other, for whatever Microsoft uses "VP" to mean) doing damage control on Bluesky: https://bsky.app/profile/scott.hanselman.com/post/3mez4yxty2... > looks like a vendor, and we have a group now doing a post-mortem trying to figure out how it happened. It'll be removed ASAFP > Understood. Not trying to sweep under rugs, but I also want to point out that everything is moving very f…
LOL, calling Scott Hanselman a 'VP of something' is funny. Been listening to his stuff for years, even when I despised MS. Always seems genuinely nice. Probably one of the main reasons I these days have a more positive image of Microsoft.
Scott is definitely one of the good guys.
Re: 15 years later, Microsoft morged my diagram
#345Earlier quoted context omitted.
YouTube must be absolutely flooded with this stuff. I clicked on one about Henry the 8th, which is a story Ive heard heard 100 times but whatever. It started out normal enough, then claimed he started carrying around a staff with a human skull on the top near the end. Made up artifacts and paintings. The most egregious has to be the "World War II mechanic fixes entire allied plane arsenal with piece of wire" category…
> YouTube must be absolutely flooded with this stuff. I don't know what the current upload rate to YT is, but this seems unlikely. Despite the reckless and insane energy consumption associated with generative visual and audio art forms, there's no way there's enough power available for generative stuff to overwhelm the "actually recorded digital video" uploads. Are there some niches on YT where this is true? Seems po…
I think YT Shorts IS overwhelmed with complete garbage. There are lots of great channels I watch that don’t have issue.
But YT shorts is the one place on YT that tries to frequently show you new uploads and stuff outside of your normal algorithm, and there is so much AI on there.
Re: 15 years later, Microsoft morged my diagram
#346Earlier quoted context omitted.
> Yup, there would have been much less Git buy-in if it weren't for git flow I don't buy this. I've never used git-flow in life. No team I've worked for has ever used git-flow. Yet all of us have been using Git for ages. Git has been hugely successfully independently and different teams follow different Git workflows. Its success has got very little to do with git-flow.
>I don't buy this. It's not really debatable. Git flow came about because of SVN / CVS practices and was the first and for many still is THE branching model they use. >Yet all of us have been using Git for ages You say "all of us" but then you completely ignore the primary branching model the vast, vast majority of people use on Git. Just for the record, this isn't being stated in support of git-flow it's just a hist…
> the primary branching model the vast, vast majority of people use on Git.
> it's just a historical fact that's not really debatable.
Over my last 15 years of software dev, I have _never_ heard of anyone actually using Gitflow in their codebase.
I'm not saying you're wrong. My experience is anecdotal. But I don't know why you say it's a "fact". Was there surveys or anything?
Re: 15 years later, Microsoft morged my diagram
#347> This isn't a case ... It's the opposite of that. It's taking something that ...
"Its not this its that" is the new em-dash.
Re: 15 years later, Microsoft morged my diagram
#348This is hilarious actually. I am starting to lean into "AI-dangerous" camp, but not because the chatbot will ever become sentient. Its precisely because of increasingly widespread adoption of un-reliable tools by the incompetent but self-confident Office Worker (R).
I don't think it's a matter of competence or confidence. It's more about indifference. AI supercharged the bullshit jobs ot should have displaced.
When over half the population have bullshit jobs putting them all out of work seems inadvisable. Doubly so given the current political powder-keg we currently exist in.
Re: 15 years later, Microsoft morged my diagram
#349Earlier quoted context omitted.
having a main branch allows a casual observer(management) to browse your project in the gui and see what is currently live. I like the opportunity to force a second set of testing, and code review. Especially if the team is big enough that you can have different people doing code review for each branch. You can also have your CI/CD do longer more thorough testing while merging to main vs development. If it's a projec…
> having a main branch allows a casual observer(management) to browse your project in the gui and see what is currently live. I never found this very compelling. What is main in that world is not the source of truth, and it's rare to have a system atomically in one state or the other - but normally there are progressive rollouts. And if you ever need to rollback in production, I assume no one is changing where main i…
I never found this very compelling. What is main in that world is not the source of truth, and it's rare to have a system atomically in one state or the other - but normally there are progressive rollouts. And if you ever need to rollback in production, I assume no one is changing where main is.
In the scenarios I am thinking of, the only way to rollback production is to update the main branch and redeploy.
But still, it's just the niceness of having the default branch match production or the current release. Even if you're not going through the extra code review or testing, and all you did was automatically point main to the same commit as the latest release tag, it's still nice. Of course, you could have a production branch or whatever, set that as your default, and leave main for development, but the point is the same.
To be explicit for code review, do you mean there is (1) main, (1) development, and then a bunch feature branches - and that there is review when merging into development and main? Having a two-tiered review process seems extremely difficult to do - versus just having more reviewers on the first merge - especially dealing with merge conflicts and needing to merge again into development.
Yes, but merge conflicts are not an issue at all if you don't squash commits on merge, atleast not between development and main. The way we used to do it, was each part of the project had owners with one required to review all changes before merging to development, then any other senior developer could review the merge to main. Though, we would encourage the whole team to review every PR if they had time.
In practice, this was really just a chance to see all the changes going in on this next release.
I think it's worth maintaining the flexibility of how many releases come from a repo. Needing to fork repos just because you want another deployable release in the future seems painful to me.
When the development team is also the operations team it's easier to keep them together and just update the deployment to go to multiple places, which would effectively still be a single deployment.
If they're separate teams, then I would be inclined to give operations it's own repo where they can manage their specific things. With a pipeline that pulls down the artifacts from the development team.
Re: 15 years later, Microsoft morged my diagram
#350Earlier quoted context omitted.
I am working with main/master for years now, and there's one problem you don't have with develop: Whenever you merge something into master, it kind of blocks the next release until its (non-continuous) QA is done. If your changes are somewhat independent, you can cherry-pick them from develop into master in an arbitrary order and call that a release whenever you want to.
I worked at a place that had Gitlab review apps set up. Where the QA people could just click a button and it would create an instance of the app with just that PR on it. Then they could test, approve, and kill the instance. Then you can merge to master and it's immediately ready to go.
Yeah same. The idea that you'd be merging code to `main` that isn't ready to deploy is crazy to me, but that doesn't mean you need a `develop` and `prod` branch. The main + 1-layer of branches has generally been totally sufficient. We either deploy to branch-preview environment or we just test it locally.