Git cheat sheet [pdf]

It's not needlessly complex. The workflow it was created to support is inordinately complex, and the target market for that is highly technical, so its complexity was not the issue. Kernel developers needed to communicate to other kernel developers in a decentralized manner, and needed to work on top of each other. How do you work on a project where there are 15,000 people writing code? Git was created for this purpose.

It's as complex as it needs to be to support the workflows it was designed to be. A dumber tool would be easy to create, but then it would not be able to support more complex workflows like linux kernel development. So it's not needlessly complex, though it is more complex than it needs to be for simple use cases.

For those needing a less complicated frontend, there's a large number of them to make it easier to interact with git. For people that aren't full-time software developers, I don't recommend using git directly. However for those that are, it's worth taking the time to understand the underlying concepts so git becomes something you understand because once you do, it's quite elegant for what it does. I'm not going to gatekeep being a software developer on whether or not you know git, but if figuring out for yourself how such a fundamental system works doesn't give you a release of dopamine, this might not be your kind of thing. Which is totally fine. There are tons of things that are and aren't my thing.

I recommend https://learngitbranching.js.org for learning how to navigate around git.

but of course, https://xkcd.com/1597/ applies as well.

Yes. Because git was created by Linus Torvalds specifically to enable and advance Linux kernel development.

The fact it has become so widly adopted is a "happy accident" (or misery). Github I think has been widely credited with making git so common place ("free git hosting") but I don't think git is the "ideal" revision control system for many projects.

Because it was made for Linus for Linus/Linux, this is why the terminology and sometimes workflow is backwards from every other "normal" version control system. A "Pull Request" (PR) is named that because for Linux development Linus/maintainers would PULL changes into Linux kernel tree. In almost every other version control system it's called a Merge Request which logically makes MUCH more sense because you are merging a change (where ever it came from) into a tree.

Git was (still?) the only open-source distributed version control system that could handle enormous code bases with good speed which means it gained a lot of inertia at big companies as well.

I vastly prefer and use Mercurial for personal projects but if you have tried to use Hg on huge code bases (I've tried on Android AOSP) it really chokes. Mercurial got the "user interface" and command-set right and has some nifty features (being able to launch a web server on the fly to get a tree view of your changes) but being written in Python, performance and scalability aren't ideal.

Some of the complexity comes from the fact that in earlier versions it was reasonably expensive to add new subcommands. As a result more functionality got added to existing subcommands like git checkout. This made the UX more confusing.

In newer versions of git the cost of adding new subcommands is reduced and they've started adding more specific commands like git switch.

I think most of the time you’d be ok just knowing a couple of git commands (log, add, commit, pull, push, ..?). And of course there’s also GUI tools.

I don’t think git is that complex for most workflows to be honest. But there is a lot of power that is available if the need arises.

Git is not complex. Its UI is!

Git is very simple. It is built on just four concepts: blobs, trees, commits, refs.

Because Linus had more clout in the SE industry than anyone else and said “SVN bad” and nobody wanted to do enough research to disprove him so here we are.

Merging in Subversion is a complete disaster. The Subversion people kind of acknowledge this and they have a plan and their plan sucks, too. It is incredible how stupid these people are.

So for example, let's go back to one of the things where I think the designers of Subversion were complete morons. Strong opinions. That's me, right? There's a few of them in the room today, I suspect. You're stupid. (Crowd laughs)

Nobody is interest in branching. Branches are completely useless unless you merge them.

https://sandeep.ramgolam.com/blog/linus-torvalds-talks-about...

Because good UI design requires a different skill and takes extra effort to achieve, so it's most often just ignored

All I know of git is clone, pull, commit, and push. That’s all I’ve ever needed. Git can be that simple. Of course it supports more complex uses, which you can learn if you need them.

Btw I moved from Sourcetree to Fork. It’s very similar but way more performant and smooth UI (unless ST has improved in last few years)

Then I got tired of pulling up my UIs and learned the terminal commands

I'd never revert to terminal commands. Git is basically begging to be interfaced with through a GUI given how much sense it makes to visualize a git repo and its workflows. The moment I started using Magit git started to make sense for me.

I had kind of the same path but with GitKraken and Sublime Merge but I kept Sublime Merge around as it ease complex interactions too.

I have only praise for Sublime Merge.

knowledge makes it hard to comprehend the difficulties other people have

The phenomena you describe is known as the Curse of Knowledge [1]

Wikipedia gives an example: A knowledgeable professor might no longer remember the difficulties that a young student encounters when learning a new subject for the first time. [2]

[1] https://academia.stackexchange.com/q/163747/132074

[2] https://en.wikipedia.org/wiki/Curse_of_knowledge

I understand the commonly used core concepts of git pretty well, and using that knowledge, I can do exactly what I want using Git GUIs (IntelliJ these days). With CLI I can do pulls and commits at most.

Admittedly, I still have trouble remembering the commands to do what I want (hello, rebase --onto A B C), though :P.

I work at a company where every developer uses Sourcetree, a GUI for Git. I don't really have a need to remember Git commands (and what arguments they take) anymore after using a GUI. For me, it is sufficient to know what Git commands do without knowing the semantics.

I can confirm the part about rebase workflow, it really forces you to understand the git model. I sincerely recommend every dev to try it at least once. It also got me into custom power tools for git, like incremental rebase, dual blame, etc.

I always find it interesting how knowledge makes it hard to comprehend the difficulties other people have.

Once the mind had bootstrapped itself to a concept, it is very hard to empathize with your past self unless you took cares to document the difficulties while still in the confused state, articulating as much detail and as many fallacies encountered as possible.

I always liken it to Wittgenstein's analogy -- don't throw away the ladder after having climbed up upon it!

I can do git pull, branch, add, commit, push, merge, diff, status, stash pretty much without thinking but much beyond that I have to look it up.

Is it common that developers still have issues with git after using it professionally for a couple of years?

As someone who has worked on developer tooling, including building a custom git client at a former job - yes.

Most people learn a few specific workflows not conceptually how things work under the hood.

Visual editors like GitKraken, Submlime Merge, Sourcetree, etc, have made this much better but there's still a big gap.

Subversion. It was made by CVS maintainers and a lot of care and thought was put into how it works and how the commands work and what the names of the commands are. Subversion is limited in being an older model of version control where there is exactly one single source of truth.

In my mind Git solves a different problem that Linus Torvalds was facing: many people working in parallel with only some of the ideas pushed upstream, but many people wanting to make changes and easily being able to move forward to the latest changes from upstream.

My extremely opinionated view is that most people should use Subversion unless they have a very complicated team structure. And that means every solo dev working by themselves should not complicate their own lives by using Git unless they are really comfortable with it already.

Mercurial if you're not on a huge code base. While the core command-line hg works great, GUIs and third-party programs are kind of lacking.

Atlassian Sourcetree in theory works with Hg (because Atlassian's Bitbucket used Mercurial as their primary version control system before moving to git) but SourceTree is Windows/Mac only, there is no Linux version for some strange reason.

Trying to run SourceTree on Linux via WINE fails because Sourcetree can't be installed with the 'Administrator' user and recent WINE releases have (accidentally?) removed the ability to run a WINE program as a non-Administrator user.

I haven't personally tried (yet) to install Sourcetree on a Windows machine and copy the directory over and try via WINE, but it's on my list to do.

Jujutsu! Git-compatible and a generational leap in source control that most people are going to love.

As a former member of Meta's source control team, I believe this with pretty high confidence -- many of the workflows that we rolled out within Mercurial/Sapling, and caused it to consistently be the most loved developer tool at Meta for many years based on surveys and interviews, have been adopted and improved by Jujutsu. See my testimonial, the first one at [2].

[1] https://martinvonz.github.io/jj

[2] https://martinvonz.github.io/jj/latest/testimonials

(Disclosure: I'm obviously biased towards the Jujutsu workflows, and its creator and I worked together on Mercurial. But I like to think that this specific belief of mine is pretty data-driven, both via stated and revealed preference.)

git is now so ubiquitous in software development, that it's hard to justify learning another version control system. You're probably better off learning the core concepts and using the most common git commands through some GUI.

A small, simple subset of git? You generally don't need all the esoteric stuff people complain about day-to-day.

Pretty much what is listed in the OP cheat sheet.

I think a better name would be “git praise”

I think `blame` is on-brand for a tool called `git`.

and off-by-one errors.

15 years… 15 years to discover git diff --staged !

Wow, TIL `git diff --staged` exists and is an alias to `git diff --cached`, which I have used for many years. "staged" certainly feels more intuitive, but will I ever be able to undo this muscle memory?!

I find aliasing a lot of these saves me a good chunk of time and reduces the barrier to better organize my work.

In case anyone cares to browse or suggest their own: https://gitlab.com/Falimonda/gitrc

Do you find that better than a stash or a branch because it shows up in ls?

You could use stash for just that use case (even multiple times to make multiple "patches").

For a more robuts method, you could also just commit (without pushing of course). Then, you can do "git reset --hard HEAD~1", and you have a pre-patch env ready for more work. When you need to re-do your commit, you can check reflog to get the ID.

Either way is, to me, an easier way to achieve the same result as patches.

But it requires you to learn emacs. I thought I could just apt-get emacs and then from there do something to the effect of "install magit" and have a easy to use interface to git.

I half a day later I gave up. Never got to install magit.

I am just the opposite. I started using Git not long after it gained traction outside of the kernel project. Of course, it was primarily geared toward working in the terminal then. Some years later I had switched to Emacs and gave Magit a whirl. Even after going through quite a bit of its copious documentation, I just never felt comfortable with it. I guess I don't like being that far removed from the actual goings on with the repository.

I've since switched to Vim and happily use git at the terminal prompt. I doubt that will ever change as the interactive interface of various Git commands has improved.

Ahh, thank you:

    git commit —-fixup $COMMIT_ID

I only recently learnt this one, it's great for working with stacked patches in gerrit.

Unfortunately, this requires creating a Medium account and signing in. Maybe it also requires payment later on.

This is the message I see.

The author made this story available to Medium members only.

If you’re new to Medium, create a new account to read this story on us.

Jujutsu has 100% cured me of those exact fears. Here are some ways I deal with them:

- I don't know if there will be conflicts when after some operation. I just do the operation and see what happens. If there are conflicts, I either deal with them, undo the operation that caused the conflict, or make a me commit somewhere else, leaving the conflict to be dealt with later.

- I know there is going to be a conflict. In this case I may duplicate the related branches and either try to reconcile them ahead of time, or try to do the conflicting operating and walk through resolving it. If the conflict resolution gets gnarly, I can either undo portions of the resolution and keep trying, put it off and do something else for some time, or abandon the whole tree.

git log -G is much more often what I want - diff contains some text but doesn't necessarily add or remove it.

I always custom-select hunks of my current work to assemble into coherent commits, where possible. I find it really helps me to rearrange the work I've done in my head in such a way that if I needed to walk someone through it, I could do so by walking the commit line.

Going to have to disagree on the lack of an index: I can see workflows where that's simpler, but I'm so used to that now with git (for better or worse) I'm imagining that'd be a pretty big workflow change for me...

Other than playing around with it, I haven't really used it in anger though, so...