[hasenj]

This guy is espousing cargo cult version control.

> This is how the Kernel team does it, so everyone should do it that way

99% of the time, your team has absolutely nothing in common with the Kernel team and it's foolish to adopt processes from other teams without knowing why.

If anything, I would say the right way to use git in a small team is to always merge and never rebase.

Whatever you decide to do, make sure to think about your problem first, then use the tools to solve your problem.

[w4tson]

He's also forgotten that git was invented before continuous delivery and the idea of releasing often from one stable master branch.

That said it can be useful sometimes to push changes out of band straight to a colleague. I have used this a few times to great effect but don't often come across the need

[sarnowski]

Wait, what?

> git was invented before continuous delivery

git was invented 2005. So you mean when people used the term Continuous Delivery more frequently? Because using CI and automatically deploy is not "new" and was surely done before git - I remember doing that even with CVS and SVN.

[w4tson]

Come off it. There's a lot more to continuous delivery than ci + deploy.

It's goes hand in hand with BDD and automated testing. I reckon there's a lot less people doing this stuff today in the wild than you'd think.

Sure there's the Netflix's n googles of the world. It was only a few years ago I would consult on projects that would have no CI. It happens.

The same thing is happening today, just because you read about kubernetes or swarm simply does not mean anything like the majority of the people out there are using it in production. Just go to a conference and and watch people stick their hands in the air.

Sure SOMEONE might have been doing continuous delivery back in 2005, it certainly wasn't me. I was too busy learning about data access objects vs ORMs and releases were 3 months away if you were lucky.

[forgottenpass]

git was invented before continuous delivery

Maybe before the word was invented, we just called it "developing in the production environment" before "continous delivery" was trendy. (And yes, we used the derisive name even if it took a couple spins on a developer workstation before getting rushed to prod.)

releasing often from one stable master branch

Subversion has serverside hooks. It was common to use them to push trunk to production after checkins. I know this because I was there writing some of those scripts.

[gardnr]

Your comment made me actually read the article so I could be properly outraged.

The article has a valid argument with a vapid premise.

> This difference might initially seem rather insignificant, but it affects the whole software engineering culture.

Totally incorrect. I was a late git adopter and would describe myself as a fatigue whiner[1].

The main things that encouraged me to adopt git were the rebase and bisect capabilities. The decentralized aspects had absolutely nothing to do with my adoption of git. The author of the post is basically claiming that I have no idea what I am doing because I do not agree with them. Fuck that. This trash article doesn't belong on HN. It doesn't even promote good critical conversation.

[1] https://github.com/yarnpkg/yarn/issues/1136#issuecomment-316...

[gardnr]

We found the yarn supporter!

[mosselman]

Were you so eager to use this phrase that you decided to use it on your own comment? ;)