5 ms·
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 abso
by hasenj 9y ago
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.
- gardnr 9y agoYour 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-316929931 https://github.com/yarnpkg/yarn/issues/1136#issuecomment-316...
- w4tson 9y agoHe'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 9y agoWait, 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 9y agoCome 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 9y agogit 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.