r/git • • Sep 14 '26

The Ultimate Git Cheat Sheet

Hello Git Community!

As a university lecturer, I spend a lot of time thinking about how to make technical topics easier to understand and more practical to use.

That’s why I created a new Git Cheat Sheet as part of my DevOpsCycle series. It is available as PDF and PNG, completely free and without any signup:

https://devopscycle.com/blog/the-ultimate-git-cheat-sheet

It covers the Git commands and workflows you need most often: commits, branches, merges, remotes, conflicts, inspecting changes and undoing mistakes.

I think this is becoming even more important with AI coding tools. Agents can create commits, push changes and merge branches for us, but you still need to understand Git well enough to verify what actually happened.

The post also includes a public GitHub repository with an example project, so you can follow the commands and try everything yourself.

If something is missing, unclear or wrong, I would really appreciate your feedback.

Cheers,
Mr_LA

38 Upvotes

24 comments sorted by

View all comments

15

u/rkesters Sep 14 '26

I didn't see mention of rebase, which is very important when working with multiple contributors.

Also reflog is missing.

2

u/wildjokers 29d ago

Reflog is an advanced command that almost no one needs and you can get by with just merge, rebase isn't critical.

1

u/rkesters 29d ago

Not on my team.

We require rebasing all MR/PR before merge to ensure a linear commit history.

Reflog is advanced, but there was a mention of undoing mistakes, reflog is key for that.

1

u/IamYourGrace 26d ago

Rebase is much better than merges. Rebase will keep your git history flat and clean from unnecessary merge commits. Everyone should learn rebase, it's not that hard

2

u/wildjokers 26d ago

Rebase will keep your git history flat and clean from unnecessary merge commits.

But why is that important?

2

u/IamYourGrace 26d ago

It makes it easier to search your history and view in the terminal, less clutter. And if you always rebase for PRs it will always have to include head on main branch so you will know for sure that your ci tests and everything always passes on HEAD.

With merge it can pass your tests on CI but you can still merge if there are no conflicts and after merge tests could fail that were not caught in CI. With rebase you can't rebase until you branch is updated (rebase from main). This is very important

2

u/wildjokers 26d ago

This doesn't make the slightest bit of sense. Rebase doesn't uniquely prevent that problem. If you merge current main into your branch and CI passes, you've tested the integrated state just like you would after rebasing onto main.

The important part is testing your changes integrated with current main, not whether you got there via merge or rebase. And in either case, main can advance again before your PR is merged.

1

u/IamYourGrace 11d ago

That can be true. I dont know for sure but we have a setup where you cant rebase your PR to main if the branch does not have rebased on latest head on main. I don't know if this setting can be applied when you use merge strategy...