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)
18 points

I need this poster or canvas printed so I can hang it on my office wall…

permalink
report
reply
11 points

but in light mode, right? … right?

screams in ink spill

permalink
report
parent
reply
4 points

Yeah, for some reason I find this hard to read. I think it might be the lack of contrast between the fonts? Could be fixable by adjusting the weight instead of totally changing the font, though. (I would change the handwritten-looking one just because I find it kind of ugly.)

permalink
report
parent
reply
7 points
*

Oh, I color-inverted it…(;・.・)

The original is here, which is indeed light mode.

edit: see palor’s comment :P

permalink
report
parent
reply
25 points

Looks like the original was “light mode”. The image is a colour-reversed image of the free PDF version which is on the creator’s site at the bottom of the page.

Direct PDF link: https://wizardzines.com/git-cheat-sheet.pdf

@CluelessLemmyng@lemmy.sdf.org @rand_alpha19@moist.catsweat.com

permalink
report
parent
reply
9 points

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.

permalink
report
parent
reply
7 points

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.

permalink
report
parent
reply
2 points

Don’t leave us hanging!

permalink
report
parent
reply
7 points

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.)

permalink
report
parent
reply
5 points

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.

permalink
report
parent
reply
6 points

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.

permalink
report
parent
reply
4 points

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.

permalink
report
parent
reply
7 points
*

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

permalink
report
parent
reply
4 points
*

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.

permalink
report
parent
reply
26 points

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

permalink
report
reply
3 points

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.

permalink
report
parent
reply
28 points

Damn she has a ton of these helpful tech guides on her site under “Comics”.

permalink
report
reply
10 points

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.

permalink
report
reply
3 points

Maybe you resolved the conflict in the wrong way and want to restart after finishing the rebase.

permalink
report
parent
reply
3 points

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.

permalink
report
parent
reply
4 points

I’ll admit that in 10 years using git, I don’t think I’ve ever used reflog once.

permalink
report
parent
reply
3 points

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.

permalink
report
parent
reply
-2 points

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.

permalink
report
reply
11 points

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…

permalink
report
parent
reply
-2 points
*

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.

permalink
report
parent
reply
4 points

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?

permalink
report
parent
reply
2 points
*

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.

permalink
report
parent
reply
9 points

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.
permalink
report
parent
reply

Programming

!programming@programming.dev

Create post

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



Community stats

  • 3.8K

    Monthly active users

  • 800

    Posts

  • 6.5K

    Comments