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)
  • GBU_28@lemm.eeEnglish
    26·
    3 months ago

    My ideal workflow: make the smallest, fastest possible PRs so there’s no tomfoolery.

    • CCMan1701A@startrek.website
      3·
      3 months ago

      This is my take as well, and yet I have an 70+ file PR still pending a complete review… But to be fair that pr required me to change half the code base to change to a new network stackm.

    • EatATaco@lemm.eeEnglish
      145·
      3 months ago

      Why not just use a gui? I don’t need something hanging on my wall because it’s all just easy clicking around. And when I do want to use the cli, it’s very easy to bring up.

      • xmunk@sh.itjust.works
        7·
        3 months ago

        I use an excellent GUI that opens a terminal to run the commands you execute in it so that you can review the precise command in case you need to modify it.

      • fool@programming.devOP
        81·
        3 months ago

        aesthetic. need i say more?

        Alternatively, the Git CLI is pretty flexible and inertia makes me stick to CLI-only lmao. Plus, PowerShell git completion is meh.

        (Not that GUI is bad. GitHub Desktop diffing is pretty.)

        • EatATaco@lemm.eeEnglish
          61·
          3 months ago

          I guess to each their own because having to hang a cheat sheet on my wall with got commands seems like the exact opposite of good aesthetics to me.

          • fool@programming.devOP
            3·
            3 months ago

            That’s fair. I’d probably wouldn’t hang up a Git cheatsheet myself either. It still looks pretty though – it’s a dark-background Kool Knowledge poster, what’s not to love? Like this evolution of Euler’s formula one.

            (Which I haven’t acquired either :|)

      • nous@programming.devEnglish
        71·
        3 months ago

        GUIs tend to only cover the common/basic usage. Which is easy to remember without a cheat sheet. When you need more advanced stuff then GUIs tend to become more of a sticking point I find. And with common workflows it is far easier to automate with the CLI then with a GUI.

        • Cyno@programming.dev
          7·
          3 months ago

          When you need more advanced stuff then GUIs tend to become more of a sticking point I find

          What’s stopping you just opening the terminal in those rare cases? For 99% of my daily needs I’m good with a good GUI

          • nous@programming.devEnglish
            1·
            3 months ago

            Typically because you have been leaning on the GUI for ages and don’t know the CLI well enough to do the easy stuff quickly let alone the advanced stuff at all. Or are even aware of what you can do with the CLI. And if you do know the CLI well enough you tend to find it just faster to work with and easier to automate things.

            • Cyno@programming.dev
              2·
              3 months ago

              How will manually retyping git pull or checkout 30+ times a day, or using the terminal log instead of a nice GUI with VSCode integration, teach me to solve other complicated issues? I just don’t really see the benefit of struggling for most of the time for something that might or might not happen later

              • nous@programming.devEnglish
                1·
                3 months ago

                You should not be struggling most of the time when using the CLI. Basic uses is just as easy as any GUI. Learning the commands might be a bit more involved and you need to be a bit more proactive about it. Anything you need to do 30+ times a day you should be over the learning curve of and can just execute them just as quickly if not quicker than using GUI. Especially when you look at tab competition and the reverse history search.

                But what using the CLI more often does teach you is how to lessen that initial learning curve. Making you quicker at finding the new commands you need and how they work slowly building up your tool belt of knowledge about the commands you do look up.

        • drathvedro@lemm.ee
          4·
          3 months ago

          Any half-decent GUI should cover everything shown in this cheatsheet. You’d have to do quite some voodoo witchcraft to need CLI these days. It’s actually the reverse sometimes, when my terminal bretheren complain that I do too much witchcraft when I’m just tidying stuff up with a GUI.

        • EatATaco@lemm.eeEnglish
          4·
          3 months ago

          Other than untracking tracked files, I see nothing in this graphic that isn’t easy to do with a gui. That might even be easy to do but it is something I do in the cli. Can I get some examples?

          I would also argue that the common/basic stuff is 99% of what I do with git. And for this I can’t fathom why people would think the cli is better. 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. This is something instantly available to me in a gui.

          Don’t get me wrong, if the cli is better for you more power to you. We moved from p4 to git and I did this almost exclusively in the cli so I could use scripts more easily. 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.

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

          • fool@programming.devOP
            4·
            3 months ago

            Click to view diffs is super ergonomic; on the other hand, I actually have a story about the Git CLI trumping the GUI (spoiler: reflog).

            In high school we had gotten the funding to build a robot, and one of the adults in charge – guy was brilliant – was using GitHub Desktop to conduct a feature merge with the student who served as team lead. The thing was, he was used to older codebases, so all of his experience was with CVS instead of Git – so when the two slightly messed up the git merge, they discussed recloning everything instead of wasting time plumbing the error (relevant xkcd).

            That was one of the earliest times I had the cajones to walk up to a superior and say “No, you’re doing this totally wrong. You don’t have to do that.”

            He looked at me and nodded. “What would you do instead?”

            “Reflog.”

            “Reflog? I’ve never heard of it before. Can you show us?”

            I hopped onto the laptop and clicked around GitHub Desktop, but couldn’t manage to find any buttons related to reflog… so I went straight to cmd.exe instead.

            git reflog
git reset --hard "HEAD@{7}"

            “Done. We can continue rebasing.”

            And after that, the advisor complimented me for using the command line tool!

            “Lots of GUI apps are just limited frontends to the real meat and potatoes, the command line. Nice job!”

            I felt like a wizard! And so I became the team’s Git-inator.

            edit: pruned story

          • expr@programming.dev
            4·
            3 months ago

            Interactive rebase? There’s no GUI that actually does that well, if at all. And it’s a massive part of my daily workflow.

            The CLI is far, far more powerful and has many features that GUIs do not.

            It’s also scriptable. For example, I often like to see just the commits I’ve made that diverge from master, along with the files changed in each. This can be accomplished with git log --oneline --stat --name-status origin/master..HEAD. What’s more, since this is just a CLI command, I can very easily make a keybind in vim to execute the command and stick it’s output into a split window. This lets me use git as a navigation tool as I can then very quickly jump to files that I’ve changed in some recent commit.

            This is all using a standard, uniform interface without mucking around with IDE plugin settings (if they even can do such a thing). I have many, many other examples of scripting with it, such as loading side-by-side diffs for all files in the worktree against some particular commit (defaulting to master) in vim in a tabpage-per-file, which I often use to review all of my changes before making a commit.

            • robinm@programming.dev
              1·
              3 months ago

              There are cases where instead of origin/master..HEAD you may want to use @{upstream}..HEAD instead to compare with the upstream of your current branch. It’s unfortunately quite unknown.

          • nous@programming.devEnglish
            3·
            3 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.

  • Modern_medicine_isnt@lemmy.world
    16·
    3 months ago

    Missing the “oh shit need to fix this other thing but I am in the middle of a big change,” flow. I use git stash, but I wish I could include files that haven’t been added and I wish it could be tied to the branch

    • nik9000@programming.dev
      5·
      3 months ago

      I’ve stopped using stash and mostly just commit to my working branch. I can squah that commit away if I want later. But we squash before merge so it doesn’t tend to be worth it.

      It’s just less things to remember.

  • nous@programming.devEnglish
    111·
    3 months ago

    The only time I see a rebase fail is due to a conflict. Which can be aborted with git rebase --abort no need for reflogs unless you really mess things up.

      • expr@programming.dev
        3·
        3 months ago

        It can be nice when you successfully do a rebase (after resolving conflicts), but change your mind about the resolution and want to redo it.

        Doesn’t come up that much, but it’s been handy once or twice, for me. It’s also just nice security: no matter how I edit commits, I can always go back if I need to.

      • nous@programming.devEnglish
        3·
        3 months ago

        Not sure I would say that is a rebase failing - just you messing things up. Can happen with any merge. But yeah that is a place where reflog would be useful. But I dont see why it would be on the cheat sheet instead of a git rebase --abort or be rebase specific.

  • FourThirteen@lemmy.world
    111·
    3 months ago

    I went from GUI to terminal and I’ll never go back. Especially with interactive add, git add -i

  • Phoenix3875@lemmy.world
    6·
    3 months ago

    In recent git versions (>2.23), git restore and git restore --staged are the preferred ways to discard changes in the working tree (git checkout -- .) and staged changes (git reset --) respectively.

    • fool@programming.devOP
      3·
      3 months ago

      Huh, TIL.

      To be fair, git switch was also derived from the features of git checkout in >2.23, but like git restore, the manual page warns that behavior may change, and neither are in my muscle memory (lmao).

      I’ll probably keep using checkout since it takes less kb in my head. Besides, we still have to use checkout for checking out a previous commit, even if I learn the more ergonomically appropriate switch and restore. No deprecation here so…

      edit: maybe I got that java 8 mindset

      edit 2: Correction – git switch --detach checks out previous commits. Git checkout may only be there for old scripts’ sake, since all of its features have been split off into those two new functions… so there’s nothing really keeping me from switch.

      • bradboimler@lemmy.worldEnglish
        2·
        3 months ago

        Besides, we still have to use checkout for checking out a previous commit

        git switch works on commits too. I don’t think you have to use checkout anymore.

  • dream_weasel@sh.itjust.works
    5·
    3 months ago

    One missing point:

    git stash $NAME lets you name a stash, and then you also can pop with that name to restore.

    Super useful if you’re doing something with plotting or presenting data and you want to try a few easy variants to see what you like most. I don’t use it all the time but it’s good to know.

    • fool@programming.devOP
      3·
      3 months ago

      According to tab autocomplete…

      $ git
zsh: do you wish to see all 141 possibilities (141 lines)?

      But what about the sub options?

      $ git clone https://github.com/git/git
$ cd git/builtin
# looking through source, options seem to be declared by OPT
# except for if statements, OPT_END, bug checks, etc.
$ grep -R OPT_ | grep --invert-match --count -E \
"OPT_END|BUG_ON_OPT|if |PARSE_OPT|;$|struct|#define"
1517

      Maybe 1500 or so?

      edit: Indeed, maybe this number is too low. git show has a huge amount of possibilities on its own, though some may be duplicates and rewords of others.

      $ git show --
zsh: do you wish to see all 489 possibilities (163 lines)?
$ man git-show | col -b | grep -E "^       -" --count
98

      An attempt at naively parsing the manpages gives a larger number.

      $ man $(find /usr/share/man -name "git*") \
| col -b | grep -E "^       -" -c 
1849

      Numbers all over the place. I dunno.

  • Valmond@lemmy.world
    2·
    3 months ago

    I use like 4 git commands in prod (make a branch, rebase, rebase interactive, push) plus git gui & gitk.

  • Sebeck0401@feddit.nl
    79·
    3 months ago

    The lengths Ppl will go to in order to not use a GUI… I haven’t written a git command in a terminal in years.

    Learnt how it works, played around with it then used different GUI tools for it.

    • PushButton@lemmy.world
      132·
      3 months ago

      My personal experience is most people who are using git with a GUI are the same people who are asking my help to git-fu their git-problems…

      Most GUIs only offer a subset of the git functionalities and hide what’s really going on by obscuring gitshell with “their workflow”.

      In all cases, use what you like; some people like the shell. Cheatsheets are normally only for learning purposes and usually don’t stick for long, it’s not an end game thing…

      • Kissaki@programming.devEnglish
        2·
        3 months ago

        I’ve been using TortoiseGit since the beginning, and it covers everything I need. Including advanced use cases. I can access almost all functionality from the log view, which is very nice.

        I’ve tried a few other GUIs, but they were never able to reach parity to that for me. As you say, most offer only a subset of functionalities. Most of the time I even found the main advantage of GUIs in general, a visual log, inferior to TortoiseGit.

        GitButler looks interesting for its new set of functionalities, new approaches. Unfortunately, it doesn’t integrate well on Windows yet. Asking for my key password on every fetch and push is not an acceptable workflow to me.

      • Fades@lemmy.world
        68·
        3 months ago

        GUI users = low skill ✅

        Majority GUI a weak subset and of little use ✅

        Elitism ✅

        Of course, this is all couched in “use what you like”, and top it off with a general sentiment of how this post is all but useless.

        If someone has to ask you for your git fu help the problem isn’t GUI use it’s the incompetence and/or inability to solve it yourself. Implying a strong correlation of the two is where I take issue.

        My personal experience? A built in GUI saves you so much time like the one in JetBrains IntelliJ, if I need something more use case oriented that is more than the core fn (intelliJ’s does not simply include fetch/push/pull, but much more including everything in the graphic) then I click terminal tab and do what I need. Similarly the git tree provides an immediate view and context of the branches, changes, tags etc.

        It’s almost like filtering people into GUI and CLI boxes doesn’t really work.

        • PushButton@lemmy.world
          62·
          3 months ago

          I think you’re making a lot of misinterpretation; but that’s up to you…

          But, just so that I can understand correctly… When you’re saying: “if I need something more […] I click terminal tab”

          That “terminal tab” of yours, it’s a CLI isn’t it?

          • fool@programming.devOP
            31·
            3 months ago

            It probably is, but I think their main point is the protest against the age-old delineation into “GUI vs CLI” camps. I’m not saying that you’re elitist, even if your statement might be interpreted as such (it’s hard to communicate tone online but the quotations around “their workflow” could appear mocking), but regarding the structure of your statement, I had a “Windows users are all button-presser noobs” phase and would’ve typed something similar about the Git CLI if time was decently rewound (sans the kindness of a “use what you like” statement). They could be interpreting your statement as a propagation of the anti-GUI stereotyping.

            Evidently they prefer GUI but can effectively use the CLI – no one disagrees that the CLI is more functional.

    • rsuri@lemmy.world
      9·
      3 months ago

      I like the terminal because:

      1. It’s the same everywhere. You don’t lose knowledge by switching to a company that has a different git client.
      2. You know what’s going on, mostly. Most clients will assume you want to do things one way and do it that way for you, especially when it comes to fetching/pulling/merging. I’d rather go through all the steps in the terminal myself so I can assure myself that I won’t be reliving various past broken merge traumas.
      3. If you like the terminal generally, you’re probably also doing other stuff there anyway. So you can get used to running whatever commands to test, lint, push, etc. without switching windows or even taking your hands off the keyboard and it becomes muscle memory.