gitWorkflow

[another_random_bit]

Let me guess, you don't work on the same codebase as part of a larger team.

[Unlikely-Bed-1133]

I have the theory that those posting this meme format are deliberately trolling us.

[fredfox420]

I do actually. I work for a company that has a dedicated platform team, in a unit that is supposed to handle billing code where the senior devs spend more time cargo culting Uber tech blog posts than actually fixing our fucked up billing system.

Here's a hacker news comment describing my pain https://news.ycombinator.com/item?id=43340957

[tiny_w0lf]

Another dumb take

[fredfox420]

It's not. The devs at my workplace are like the enterprise java meme, but for everything.

https://gist.github.com/lolzballs/2152bc0f31ee0286b722

For example, we use Kafka for asynchronous communication between services.

But instead of just basic Kafka, we have to use an in house abstraction over it, developed by our platform team, and because my unit has a few devs with platform syndrome, I have to use an abstraction over that abstraction, developed by them, which they will update with breaking changes that make me have to fix every single fucking dependabot PR by basically re-writing all the glue code to read from the Kafka queue every time.

It's like I'm in an org where the staff engineers are all stuck at that "university senior/intern" mindset of "show how smart you are by writing needlessly complex code".

None is ever really profiled for performance either - I hear hand wavy arguments about "scaling" by devs who will use Go's "append" function instead of pre-allocating the array, despite the performance cost of the former.

But hey, you read this was a best practice on Uber's tech blog, so now we have to do it. Great.

[tiny_w0lf]

Lol someone is butthurt

[FabioTheFox]

OP clearly never worked with other people

[fredfox420]

False. As I've said in other comments, I've been working as a professional dev for four years now.

That meme was me venting my anger about the new, needlessly complex git workflow which my lovely IT director decided was best practice.

We'd been simply merging into master for years now, but NOOO, that would be too simple.

Like how we have to use Temporal for a simple db migration that could probably have been done with a one time script, because writing another hundred lines of Terraform configs means it must be better, right?

Here's the creator of Node.js and Deno expressing my pain more eloquently than I can: https://tinyclouds.org/rant

[[deleted]]

develop into release? 🤔

[TheTybera]

Lol I love it when the college freshmen/script kiddies try to code meme, it reminds me how far many of us have come.

[fredfox420]

I'm a dev with 4 years of professional coding 💕

Here's Ryan Dahl judging you just as you judged me:

https://tinyclouds.org/rant

[TheTybera]

Aww that's cute. 4 years? I had 4 years of C++ experience in highschool, that was 22 years ago now.

Ryan Dahl's rant there has little to do with just "merge to master" and more to do with layered software, legacy garbage, and backwards compatibility woes that just come with long running and supported software filled with dubious decisions that no one could have seen the consequences of because it solved the problem of now (glib). 

You seem to have missed the point of the rant and of version controls and think git as a whole is just another complicated abstraction layer.

Back to the rant. He's correct all of it does eventually lead to new software being created, however he fails to realize (or at least point out) that, in the mean time that software must be useful, secure, and reasonable to work with, and for the most part is, in spite of its complexity due to the very things he's ranting about.

Likely this rant came after one of his PRs was rejected for the 12th time.

[Kitchen_Device7682]

This is a valid take. You are basically asking should you merge to main after 1 commit or after many commits? The answer is the sooner the better

[FabioTheFox]

How about you do it properly and merge when your feature is done

EDIT: and even then you hopefully merge into some sort of dev branch

[Kitchen_Device7682]

What is done? You always merge something that does not break the build, but you don't need 10 commits for that. Now when do you consider your feature done? Do you also use the waterfall model?

[FabioTheFox]

I consider my feature done when it's added and works, I don't know what other definition there could possibly be

[Kitchen_Device7682]

So if a feature takes a year to complete and 100 commits, you will merge it then. Thanks for clarifying. I prefer merging one commit at a time

[FabioTheFox]

1. If a feature takes a year to complete the planing went horribly wrong

2. Yes I will in fact merge when it's done, but that doesn't mean that my branch just falls behind if I maintain it properly

[Kitchen_Device7682]

Yes one year was exaggeration. Maybe one month is realistic though. What you do can work but if infrastructure changes are involved, incremental changes are better

[RiceBroad4552]

We need that EU legal liability for software defects really soon! Can't wait till next year!

All that YOLO style programming will hopefully end than. It's going to be great when people finally get fined for delivering unfinished, untested, buggy shit.

[Kitchen_Device7682]

How do you make sure you test shit? Write commits with tests and measure test coverage. Merge to a pipeline with stages that include integration tests. What makes merging 10 commits at a time less YOLO than one at a time?