> 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.
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
> 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.
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.
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.
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...