A little background: Through my teens in the 90’s I did a lot of the things you may expect. I was a script kiddie on mIRC, made a tank game in Unreal Engine, and did some Quake modding. From 2002-2004 I landed a job doing Java web dev, SQL, and overall database administration because my father’s friend needed someone that could do that. I was ok at the job, but not great. Being young, my hobby that turned into a 9-5 made me want to stab my eyes out and I quit.

With that said, I can understand a lot of what’s going on, but it doesn’t “click” anymore. I spent 20 years as a career machinist, but I physically can’t do that anymore. Here’s the rub - my twin brother is a brittle diabetic and can’t work (lots of other stuff going on as well), and our mother is getting old (father passed this year). The only reasonable way forward that I can see in order to be able to support my brother is trying to get back into development.

When I stopped, subversion was what we used. I’m trying to understand Git, but it’s a giant conceptual leap. I guess, what I’d like to hear from you all is a way to jump back in as quickly as possible in such a way that it may be a career.

Thanks

  • talkingpumpkin@lemmy.world
    link
    fedilink
    arrow-up
    8
    ·
    10 days ago

    Best of luck to you!

    I’m trying to understand Git, but it’s a giant conceptual leap.

    Git is not that different from svn (I mean, the biggest hurdle is going from a shared folder to any version control system)… I’d say the main difference is that branches live in a different namespace than files (ie. you don’t have trunk/src/whatever but just src/whatever in the main branch). On top of that there’s that commit and push are two different things (and the same with fetch and checkout) and that merges are way easier than in svn (where you had to merge stuff manually).

    If you create a repo locally and clone it twice in two different directories, you can easily simulate what would happen when you and a coworker collaborate via a centralized repo (say, github) - do a few experiments and you’ll see it’s not as complicated as it seems (I’d recommend using the CLI instead of some GUI client: it’s way easier to figure things out without the overhead of learning to differentiate between git concepts and how the GUI tries to help).

    • Brosplosion@lemm.ee
      link
      fedilink
      arrow-up
      2
      arrow-down
      1
      ·
      10 days ago

      To piggyback, the true main difference is svn stores commits as snapshots and git commits are deltas from previous. This is why git is depicted as a tree since it’s inherently a node-based structure.

      • ericjmorey@programming.dev
        link
        fedilink
        arrow-up
        3
        ·
        edit-2
        10 days ago

        A git commit is a snapshot. The node-based tree structure is an artifact of recording pointers to other snapshots and labeling snapshots with a branch name.

        • Brosplosion@lemm.ee
          link
          fedilink
          arrow-up
          3
          ·
          10 days ago

          You are correct. Technically a snapshot, but unmodified files are not duplicated from the previous. Imho that is one of the key things to understand about how git works ( and why rebasing and branch manipulation works so well)