We all have been there… For the beginner it’s easy to mess things up. What are your horror stories with Git?

Link to xkcd

  • @[email protected]
    link
    fedilink
    English
    411 year ago

    Those first couple months learning git… yeah, it is weird, but once it clicks… you’ll be surprised how truly simple it is.

    The programming world would be awful without it

    • @mookulator
      link
      English
      161 year ago

      Learning git was like every other cool tech thing for me (including the fediverse). People explain it in such a convoluted way. It’s like they think you want to understand the deep theory of it before you get up and running!

      Yes, git is more than just a “save box”, but really, new users should absolutely just think about it as a save box. Learn the fancy shit later.

      • @[email protected]
        link
        fedilink
        English
        41 year ago

        Honestly this is me. At this point I really should know better but I dont, and every tuorial seems to be speaking a whole new language. Any tips for where to learn this?

          • @[email protected]
            link
            fedilink
            English
            41 year ago

            Thank you! I will read this in detail next week once I’m back on the clock and work is paying me to read it 😁😋

        • @mookulator
          link
          English
          3
          edit-2
          1 year ago

          It’s ridiculous isn’t it? You shouldn’t have to feel like you’re learning some cryptic new language to use version control software.

          Just do a really simple work flow:

          1. “Clone” the code repository from the internet onto your computer (“clone” = “copy”). You only do this once.
          2. Edit code like normal
          3. When you feel happy with some changes you’ve made, “commit” them (“commit” = “save”)
          4. When you’ve committed a few changes, “push” them back to the original repository so your coworkers can see your changes (“push” = “publish”) Repeat

          There are a few good practices:

          • “Pull” often. I.e. update your local copy of the repository with your coworkers’ changes
          • Write an intelligible message with every commit so you and your coworkers can understand what you changed
          • If you’re going to take on a big project, make a “branch” and work there. A branch is like a copy within a copy of the repository so you don’t mess with code that’s already working. When you’re happy with a bunch of commits/pushes in a branch, you “merge” it back into the main repository.

          Everything else is just details!

    • The Cuuuuube
      link
      fedilink
      English
      131 year ago

      It was awful. The fact that SVN is still used terrifies me. People are actively choosing to live their lives like that

      • @[email protected]
        link
        fedilink
        English
        31 year ago

        Git was just released while I was in college, and I was in a group project that required us to use SVN. First job was a TFS shop. When git finally matured to the point that it couldn’t be ignored anymore, life became much much more sane.

      • JackbyDev
        link
        fedilink
        English
        11 year ago

        Subversion has some features git lacks or lacked for a very long time (I think it has most now). The biggest being able to easily clone and work with a subset of the repository. That’s Subversion’s entire thing! Don’t misunderstand, I prefer git and think it is better.

    • @emptyother
      link
      English
      51 year ago

      Yeah, remember the giant merge conflicts I had to deal with because of our lack of experience with git. One really learns how useful it is to split stuff into files with git. Also the headache of line breaks and case-sensitive paths.

      No horror stories to tell, though. We all got through our first git learning experience without any major accidents. Once we had to re-up the remote repository from a dev machine, that was it.

    • @[email protected]
      link
      fedilink
      English
      3
      edit-2
      1 year ago

      I’ve recently worked on a project that was using Plastic SCM for version control, and omg the QoL is so insane on that one. It’s such a shame that Unity are greedy as fuck and tend to ruin everything they acquire, the licensing costs for Plastic are awful.

      For example - I really low how it tracks what was merged from where, so merges aren’t just a single commits, and if you for example pull something into a feature branch you are working on, and then merge the branch into master, all of the files that come from your branch are listed as changes in the commit, but files that were merged into your branch are marked as “merged from XXX”.

      Having PRs (code reviews) integrated into the client is also nice, since you can just link changes with change requests directly, and since it was made for Unity projects it also pretty nicely handles large files.

      It’s a shame that Unity acquired it, though. My last experience with their business model was when I was looking for a streamed remote play solution for a Unity game - which was exactly what Parsec offered as a free open source SDK for years. Until Unity bought them and close-sourced it (or rather - changed to "contact us for access to the SDK)), and when I contancted them for the SDK for our small student’s game, they were willing to cooperate and give us an access - if we pay them 1 000 000USD for it. Which they had the balls to ask for even though I’ve specificly mentioned in the email that we are a bunch of students who work on a small game in our free time, which I find really baffling :D