Git cheat sheets are a dime-a-dozen but I think this one is awfully concise for its scope.

  • Visually covers branching (WITH the commands – rebasing the current branch can be confusing for the unfamiliar)
  • Covers reflog
  • Literally almost identical to how I use git (most sheets are either Too Much or Too Little)
  • nous
    link
    fedilink
    English
    arrow-up
    3
    ·
    edit-2
    2 months ago

    I see nothing in this graphic that isn’t easy to do with a gui.

    I didnt say the GUI was not easy for the common stuff. But I think the CLI is also easy for the common stuff so there is not much advantage other than a bit of a learning curve with the CLI. But the big thing that GUIs make harder is automation of common things. For instance, when I want to create a PR I like to rebase to the latest upstream. In a GUI that is a bunch of button clicks. With the cli I just <CTRL+R>pus and that will autocomplete to git pull --rebase=interactive --autostash && git push && gh pr create --web and I am landed in a web browser ready to review and submit my PR. Doing the same thing in a GUI takes a lot longer with a lot more clicking.

    And that is a very common command for me.

    Like logging and diffing is just so much easier when I can just scroll and click as opposed to having to do a log command, scroll, then remember the hashes, and then write the command.

    Never found that to be a big issue. Most of the time when you want a diff you want to diff local changes or staged changes which is simply git diff and git diff --staged neither of those are hard or any real easier in the GUI (especially with bash history). For diffing specific commits I dont find that hard either just git log --oneline and find the commits (and you can use grep to filter things out easily as well here) - typically does not require scrolling at all. Then git diff <copy paste>..<copy paste>. In the GUIs you are often scrolling through commits you want to select at some point so I dont see how that saves you any real time here. I would not say the CLI or GUI is vastly easier in this case. And even in this case it is rare to need to do. Far more often is just branches which on a decent shell can be tab completed for convenience.

    And sometimes I watch beginners use the gui and I have to bite my tongue because I know it would be faster in the cli.

    This is why I prefer the CLI for common stuff. It is just faster.

    But, especially for a beginner, i strongly recommend a gui.

    And that is where I disagree. I think beginners should spend some time learning the tools they will need to use. IMO the CLI is critical for developers to learn and the sooner the better. So many things a vastly easier with the CLI than GUIs and a lot of stuff is near impossible with GUIs. Automation being a big one. I have not seen a good CI system that is GUI focused that you never need to know the cli for. Or when you have a repetitive task then it is quicker to write a quick script and run that then doing the same thing over and over in the GUI. Repeating actions is also easier in the CLI. All of these apply to more than just git as well.

    I have seen so many beginners start with GUIs that don’t really understand what they are doing in git. And quite often break things and then just delete and recreate the repo and manually make their changes again. I find people that never bother with the CLI always hit a ceiling quite quickly in terms of their ability and productivity.

    The only real thing that makes the CLI worst is that it has a steeper learning curve. Once you are over that hill I find it to be vastly better for more situations or at least not practically any worst than a GUI equivalent. So that hill is one well worth climbing.

    I can always use a GUI if I really needed to. But those that only know the GUI will have a very hard time on the CLI when they need to - which is required far more often than the other way round.