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

  • Traister101
    3·
    3 months ago

    So the big important part of git is that it’s a collection of commits. A branch is just a labeled commit and each commit is a list of what changed from the parent. Rebasing (the most confusing one for people) is when you fiddle with a commit from underneath yourself. Or in even more simple terms editing a parent commit. Rebasing is extremely powerful but most useful for when you notice a bug you wrote a couple commits ago. Fixing such issues via rebase (or !fixup commits you auto squash at the end) keeps your history clean. It’s as though you never wrote the bug. The other thing you do a lot with rebasing is moving your branch up in the history cause somebody updated the remote.

    • jawa21@lemmy.sdf.orgOP
      2·
      3 months ago

      I mean, this could be useful, but I need a much higher level of understanding. When I was a dev, all we used was basically version control. There was no concept of commit, pulls, etc. I’m having to understand this from a standpoint of no understanding whatsoever. For most devs, they’ve done this for at least a decade with Git. Git is so much more complicated than a simple version control. I understand why it’s necessary for large teams, but I still see it lke this:

      • hades@lemm.ee
        4·
        3 months ago

        You likely have a mental model of Subversion, so what I would suggest is to try to forget as much of it as possible first, as Git is very different.

        Take a tutorial that is aimed at Git beginners, e.g. [1]. This will help you start building a new mental model as well as get first practical experience.

        After that, read the official docs starting wtih the object model[2]. The reason why many people struggle to get into git, especially after using other VCS, is that it was built from the ground up, without much regard of the established conventions and terminology. Linus Torvalds once mentioned that he used his experience designing file systems when developing git.

        So the object model of git is very simple, but also not intuitive. However, once you understand it, everything will start making sense, including the xkcd you’ve linked.

        [1] https://gitimmersion.com/ [2] https://git-scm.com/book/en/v2/Git-Internals-Git-Objects

        • gedhrel@lemmy.world
          2·
          3 months ago

          You’ve linked into it, but I was just going to point at the Git book: https://git-scm.com/book/en/v2

          It’s an afternoon’s reading; it does an excellent job of giving you the right mental model - and a crib aheet of commands to navigate it.