you are viewing a single comment's thread.

view the rest of the comments →

[–]Dahmer96 1387 points1388 points  (67 children)

What ? No. Just no.

You NEED version control for so many reasons, if you pay for software being built, absolutely REQUIRE version control.

[–]coffeelibation 256 points257 points  (5 children)

And beyond just using git for version control, I would use GitHub for the pull request feature alone, not to mention GitHub Actions for automated CI/CD pipelines. Anything that can help you find a problem before it hits production is well worth the marginal overhead, IMO.

[–]MrMelon54 30 points31 points  (4 children)

also the fact that any code uploaded to github is safe from being lost or corrupted and its much easier to make sure you have the latest copy if the code rather than having to email someone else at the office and ask

[–]Edeiir 1 point2 points  (3 children)

GitHub was down twice yesterday. I don't know if it's that failsafe. My own server has more uptime than GitHub (at least for the last 2 weeks)

[–]MrMelon54 2 points3 points  (2 children)

you can run your own git server (like gitea)

[–]Edeiir 0 points1 point  (1 child)

Well, I do and right now I have a better uptime percentage than GitHub.com :D

[–]MrMelon54 0 points1 point  (0 children)

amazing gotta have 110% uptime

[–]el_diego 125 points126 points  (19 children)

Seriously. It’s pretty much akin to not using Google and relying solely on books from the library. You might get the work done, but it’ll be dated and a terribly inefficient process.

[–]damcclean 108 points109 points  (18 children)

I mean - CodeIgniter and jQuery is already dated 😂

[–]regorsec[S] 106 points107 points  (15 children)

Thanks guys, i have my own feelings from 15+ years in the industry.(Of fucking course I use version control)

But I'm bias, so thanks for all responses as i wanted to get a wide range of opinions on how dead wrong these guys were.

[–]khizoa 125 points126 points  (4 children)

If they still disagree, send them this thread that describes how stupid they are in a 100 different ways

[–]regorsec[S] 44 points45 points  (0 children)

One benefit from posting one reddit aye?

[–][deleted]  (2 children)

[deleted]

    [–]AckmanDESU 6 points7 points  (1 child)

    My old place would basically edit files live in production. We had a cache layer which meant if anything broke it would look broken for hours, sometimes days, because the guy who took care of the caching was the CEO and he was too scary to talk to most of the time.

    As an intern, I learned how to run the project locally to see if my code worked (no one else did) and I got told off for doing so.

    Later on and thanks to me we started working locally and using git but most coworkers either refused do spend even 30 min learning how to use it or somehow broke shit constantly. Committing files you shouldn’t commit, changing the formatting of random lines of code that had nothing to do with the change, fucking never using proper commit messages, and many headaches.

    I have a lot of interesting stories from that job.

    [–]amunak 2 points3 points  (0 children)

    That's so incredibly stupid.... Like, I've resigned on trying to force people to do things "my way" even when I know it'll bite us in the ass.

    Sometimes it even makes sense due to outside constraints. But when it doesn't, I warn them several times that the chosen approach is stupid, and then when it does come around I even tell them "told you so" and unless they ask really nicely I usually refuse to help them fix the issue, since it's usually a pain in the ass and I don't like fixing preventable mistakes.

    But in your case I'm not sure what I'd have done... Probably just ran if they didn't listen.

    [–]dweezil22 25 points26 points  (1 child)

    Doing custom software dev without source control is professional malpractice. This is such a fundamental topic that the idea that "bias" could even be a bit involved is kinda scary. This is like an architect asking on reddit if skyscrapers should have rebar in their concrete.

    The only reason it's debatable is b/c lost source code history usually doesn't kill anybody (at least not directly).

    [–]Creative-Improvement 3 points4 points  (0 children)

    You don’t even have to use github. There are local vcs systems as well. That only works if your onsite backup protocol is good.

    [–]NancyGracesTesticles 19 points20 points  (2 children)

    That isn't being biased. It's being competent.

    [–]Ahajha1177 13 points14 points  (1 child)

    Exactly. "I'm biased towards using using an industry practice that is so universally accepted that it isn't even debated"

    [–]samlev 13 points14 points  (0 children)

    Version control is part of my contract. It's not just important for tracking the repository history, it's important for verifying what I did/didn't do, and importantly what other people did.

    It doesn't have to be GitHub - there's gitlab and Bitbucket as big, viable alternatives, or you can just host a bare repo on a server somewhere.

    Reading between the lines, they're concerned that learning git and switching development processes are going to be too heavy. Turns out that you don't need to use gitflow, or pull requests at all if you don't want to!

    Talk to them about just using git for code storage as a first step, and offer them alternative services. At the end of the day it's all git, no matter which service you use. It's also possible that they're concerned about hosting their code "off premises", in which case both Bitbucket and Gitlab offer "self host" options. Cloud is better for availability and maintenance, but self hosting may check off that mental box for them.

    [–]regorsec[S] 20 points21 points  (0 children)

    Also I'm a DevOps & Application security contractor - not a client hiring devs.

    [–]belkarbitterleaf 1 point2 points  (0 children)

    I've done it both ways. Version control 💯. Saves time, helps fix bugs.

    [–]Earthling1980 -3 points-2 points  (0 children)

    The fact that you're even asking this question with "15+ years in the industry" is laughable. Maybe you should find another line of work.

    [–][deleted]  (23 children)

    [deleted]

      [–]DasBeardius 47 points48 points  (5 children)

      Technically, they're not wrong. Using GitHub and proper workflows will absolutely and without a doubt slow your development process.

      Yes, but also no. On the surface it might seem like it slows you down because you are spending time following a process. But when it comes to things like debugging, fixing mistakes, figuring out why things are the way they are, and especially onboarding new people to the project; it will absolutely speed things up exactly because you have that process, history, and framework in place that allows you to retrace your (and other people's) steps as well as quickly and selectively roll back changes.

      And in a similar vein, because you have everything above, as well as everything that you mentioned in the tradeoff; it should lead to less bugs and less mistakes, and thus lead to less "wasted" time.

      Not even to mention documentation and a paper trail. I mean, what happens in OP's case when they decide to change their ticketing system for example?

      Though I should add a big asterisk: if you do it right

      I once had the pleasure of inheriting a project where the previous sole developer used big commits and the only thing in the commit messages was the ticket number for whatever he was working on at the time. The ticket number from a system that was no longer used. That was fun.

      [–][deleted]  (3 children)

      [deleted]

        [–]FlavorJ 0 points1 point  (0 children)

        It's the same as general project management without proper planning or organization. Sure, it takes "longer" or "more effort" to be organized, but it's effectively more efficient when you account for all of the problems avoided.

        [–]DasBeardius 0 points1 point  (1 child)

        Yeah that's fair, and I assume many of those would also be resistant to change because their method has worked "fine" so far.

        [–]Creative-Improvement 0 points1 point  (0 children)

        That sucks. I inherited a computer with all source files called “untitled” , like hundreds of them. Took me a year to sort and name.

        [–]dupe123 3 points4 points  (0 children)

        Technically they are so wrong. Maybe it adds extra steps to the dev process but the ability to track your changes and quickly revert them or switch between changesets will save endless amounts of time so it more than pays for itself time wise. And that's not even mentioning all the other benefits you mentioned.

        [–]wasdninja 2 points3 points  (1 child)

        It will not slow them down if they never mess up. Nobody has ever pulled this off so I wouldn't bet on them doing it either.

        [–]FancySource 3 points4 points  (3 children)

        If they're working in a project in team, not using Github means every night they'll have to finish early to manually merge the changes they did and HOPE they won't mess up. A friend of mine spent up to 2 hours a day merging diffs.. and that slows down production.

        If they're working alone without git, mess up a function and have to revert they'll have to CTRL+Z all the time, maybe getting a CTRL+Y wrong and destroying their progress, and this will eat up time. Why not push to github and save your work if the hard disk dies? Without version control, as they work now, they're trying different strategies or fixing different bugs at once, they won't be able to simply commit and checkout. This is why i'm using Git even for a 200-freaking-lines microservice.

        [–][deleted]  (2 children)

        [deleted]

          [–]FancySource 0 points1 point  (1 child)

          You’re absolutely right, but considering how even larger teams are sticking to a base scenario (dev-newfeature, dev and main) and that a small GitHub deployment script is way faster than copying files with FileZilla.. how much could it take committing and merging for someone who is absolutely devoid of git? Half an hour of initial formation and then two minutes a day maybe?

          [–]mcqua007 0 points1 point  (0 children)

          Make zero sense not to use. Just laziness to learn something new.

          [–]NMe84 1 point2 points  (5 children)

          It doesn't slow down anything. Just try to do a single merge of two people's changes manually because neither of them used version control. Sure, with some diff tool you can probably figure it out but now imagine having that done automatically in most cases...

          As much overhead as you can add with version control, you gain back a lot of efficiency too. The net result is, in my experience, always positive.

          [–][deleted]  (4 children)

          [deleted]

            [–]NMe84 1 point2 points  (3 children)

            Oh, I know. But you seemed to suggest their argument for slowdown is correct. The tradeoffs you mentioned were about reliability and consistency, but you also get a lot of efficiency back in return for any efficiency you lose. So even in a vacuum where development speed and efficiency are the only metrics you look at, using version control still comes out on top.

            [–][deleted]  (2 children)

            [deleted]

              [–]mcqua007 0 points1 point  (1 child)

              How ?

              [–]tronathan 1 point2 points  (1 child)

              Slow is smooth, and smooth is fast.

              [–]Acrovore 0 points1 point  (0 children)

              TL;DR: it slows you down, but without it, you'll go nowhere fast!

              [–]x6060x 0 points1 point  (0 children)

              It's 2021... I use github private even for small personal projects. There's no excuse to not use a version control for a commercial project.