Why is Git so hard?

I'm working on an ebook for new learners of Git. I was basing it off of my experiences when I first started learning Git and the struggles I had. I never quite understood rebasing and merging for the longest time, I learned very quickly I need visuals for Git.

I want to know what makes it difficult for you to pick up? Are there any specific commands that are hard to understand? Let me know c:

  1. 7

    Git is a blessing from heaven.

    If you complain about Git is because you never had to use Subversion. That was a nightmare!

    1. 4

      If you complain about Subversion, it's because you never had to use SourceSafe.

      Someone could check out a file for write access, go on vacation or die, and nobody would be able to write to it ever again without specialized ($$$) tools and Domain Administrator access.

      Goooood times.

      1. 1

        Or, something just as pathetic: perforce. It's what nightmares are made of.

        1. 1

          That's interesting - I've not had direct experience, but my impression was that Perforce was supposed to be really powerful, especially for managing large assets (like in game development, for example).

          I guess the grass is always greener...

          1. 1

            Oh wow, please if you're thinking of using perforce, simply stop!
            To call perforce a nightmare, is an insult to nightmares.

            Their tactic seems to be to sell to clueless managers, and they're clearly using all the buzzwords. Other than that, it's more or less a glorified sourcesafe. They've been trying for years to more or less do something decentralized like git, but it's more of a joke. I've had to use the command line for years, because some of their UI is still from the middle ages.

            And don't get me started on their fucking stupid definition of workspaces, depots, and other crap. If you're used to git, you'll wanna kill yourself.

            1. 1

              Wow! Thank you. I had no idea.

              1. 1

                Yeah, perforce is one of those things I passionately hate (along with the likes for Jira, and Microsoft :D )

    2. 1

      To go with the theme: If you think git is good it's because you've never used mercurial. I do ALL of my git manipulate inside mercurial with hg-git and it is a blessing. interactive rebasing, rebasing, cherry picking, etc, are all significantly more pleasant experiences (to me) in mercurial.

    3. 1

      I remember thinking Subversion was a godsend because it was so much better than CSV. But I remember branching still being kind of a pain. Then someone showed me how easy branching was in Git and I was sold. So much better.

  2. 5

    Part of what made git hard to pick up is the typical mental model of how version control might work doesn't map to the commands available.

    For example, how would you go back to the previous change? git rollback? git previous? No, it's git checkout HEAD~1

    How do you create a new branch? git create branch [branchname]? No, it's git checkout -b [branchname].

    The a-ha moment for me was when I realized that git is literally a data structure you manipulate from the command line. Once I learned what that data structure was, the operations started to make sense. So now, instead of thinking in terms of a mental model about version control, I was thinking about manipulating the data structure.

    Of course, visualizing the current state of the data structure also helps. It's often much easier to know how and what to merge and rebase when you can see the history. I use gitx, but you can use gitk, or any other visualizers out there.

    So for your eBook, I'd focus on establishing the right mental model for your readers, so that mapping operations to the data structure makes more sense.

    1. 1

      This is the key thing for me, and that is missing from almost every Git tutorial I've seen - the mental model.

      As someone who came from the Subversion (and briefly Bazaar) VCS camps, it took me a long while to re-learn the difference in what a 'commit' meant in Git - it was very different from the other systems I knew.

  3. 4

    The reflog changed everything for me. I could make mistakes and always go back if I messed things up.

    Not enough people know how to undo with the reflog.

    1. 3

      Similarly, not a lot people know you can stash multiple times on the same branch. I makes multiple implementations so much easier to track and showcase

    2. 1

      Yeah, this is so true. Once I learned how to get stuff back out of the reflog, I started feeling really safe with Git. Before knowing about the reflog, I felt like there were a lot of ways to shoot yourself in the foot with Git. But almost every thing you do with Git is tracked in the reflog. You can use it to recover in most situations.

  4. 4

    I think git is super hard for newcomers because you need to keep a lot of stuff in your head, plan next few steps ahead (I'll rebase and then I can push) and sometimes an unexpected thing happens (like a merge conflict) and you get lost where you were. The worst situation is when you think you're somewhere else state that git actually is (like if you have a merge conflict and you do a full checkout to a commit you don't have any changes but you still have the ongoing merge conflict state, so you cannot start a new merge before you abort the old one, which then flings you back to the commit where you started from).
    One thing I always recommend to people starting up with git is the branching game.

    1. 3

      Conflicts are probably the break the keyboard time for many
      And its common for people to redo Thier changes 100% manually on a fresh copy....
      (And at times fail and do it multiple times)

      P.s. / advance There is a non default config to save conflict resultions

    2. 3

      Yea I hate the naming with current and incoming never making sense to me, who did what.. which side of the coin am I on? And it's worse if I'm both or neither needing split personality

      1. 1

        It took me 3 years to realize the merging and rebasing should be done by the person that pushed/merged first... really unintuitive 😒 It did clear up the ours/current (person that merged first) and theirs/incoming (person that didn't merge first)

      2. 1

        Yeah, --ours and --theirs flags are very oddly named too 😄

  5. 2

    I think you should ask yourself a question before diving into writing a book about git:
    In all the time you struggled with git, did you ever pick up a book about git to better understand it?

    When I first started using git, it had some learning curve to it - that’s true. After some time using it (a period far shorter than the time it takes to read a book about git) - I felt git is great and I know what I need about it.

    I think that anyone interested in git can much faster pick it up by using it a little and by reading a couple of blog posts about it than reading a book about it (and there are already a handful of those).

    1. 1

      You're right, I never picked up a book. My default was SO or the Atlassian guide, and with time it's became very natural to think of git. As for the ebook, similar to git, reading about how to create and provide a product can only teach you so much, so this is my attempt at learning the process firsthand ☺️

  6. 1

    git is about version control, in nutshell its just check in and check out. It becomes more difficult than it sounds is because people want to do things in different ways and do not want to be clear about the purpose.

  7. 1

    My 2 cents: git is an insanely awesome tool, but life is too short to learn the command line.
    Just use a GUI and be done with.

    I wish you the best with your ebook - just make sure you'll have an audience for it.

    1. 1

      GUIs for git are great, but I don't think it's a substitute for knowing how git works.

      It's not uncommon for rebases to go wrong, or branches to end up in odd states, because somebody didn't totally understand what the GUI tool was about to do. Those mistakes can take a long time to fix.

      I'm usually against those that say that you shouldn't use an abstraction until you know how the thing works underneath. I think git is an exception though.

      1. 1

        What seems to me that you're saying is you haven't met the right GUI for git.
        Understanding the git concepts - I agree that is a good thing to have.
        But using the command line -- I'm sure you can find better uses for your brain then constantly memorizing those great command line args.

  8. 1

    It's a bit dense, but I just tell people to read through https://git-scm.com/book/en/v2 and do what it says. I don't find Git very hard, but then again, I may have survivorship bias as I've been a dev for 19 years now

  9. 1

    You'll git it eventually.

  10. 1

    I remember thinking the same when I started with Git. Sometimes I think I should take a course on it but there are only a handful of commands I use. You might want to check out the interactive rebase if rebasing is difficult for you. It offers somewhat of a visual component. For merge conflicts I usually accept both changes to better see what is happening and then ctrl + z and select the one I really want. Merging is easy if you use PRs and the UI in github instead of the command tool, hope this helps.

  11. 1

    I wouldn't suggest making a tutorial on something you struggle with, but I mean, if you're good then go ahead. Git for me is something I just use. I don't learn everything but only what I need to. If I need to make a heroku application, I'll just use git to a certain extent--only what I need.

  12. 1

    There was someone around making a git teaching tool that wrapped git with"simpler" commands

  13. 1

    P.s. one of the most useful and actually easy to use features few use is
    Git bisect
    (For finding when an issue was introduced)
    You only need to know start, good, bad

    1. 1

      This sounds amazing!! I've literally needed exactly this for 2 PROD issues at work... wish I had known about it

  14. 1

    I often find if hard to figure the context of Git actions, for example pull and push. It's not clear from where to where I'm pushing or pulling.

    1. 1

      Actually that should be easy once you learn
      Git remote
      (Which is common for git issues, there is one more level to learn that explains it all..)
      Your always taking an action against a remote (usually a default one, commonly the repo server, unless advance setup)

      1. 2

        Well, it's easy once you learn it.

        1. 2

          Agreed, I want to target my teachings to a very fresh audience. It usually takes a lot of practice before you can visualize git in your mind, but what if you just had a visual/animated guide for the fundamentals. I think it makes ramping up on this amazing tool even easier.

Trending on Indie Hackers
Songbox breaks £1000mrr ($1378) 36 comments One tweet. 750K impressions. +1800 Followers in two days...😱 14 comments Product Hunt Launch After 6 Months of Work! 12 comments Racket - easy short form podcasting 8 comments What am I'm doing wrong (trying to get initial teams onboarded for a team-focused remote job board)? 7 comments Validate your product: 19 market testing and market validation tactics (plus 7 tools for validating) 6 comments