10 ms·

Git cheat sheet [pdf]

328 points by tambourine_man 2y ago

tiffanyh 2y ago
Is there a historical reason why git is needlessly complex? Seeing this cheat sheet really brings it to life.
- jimbob45 2y ago
  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-git-at-google#genuine https://sandeep.ramgolam.com/blog/linus-torvalds-talks-about...
- fragmede 2y ago
  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 https://learngitbranching.js.org for learning how to navigate around git. but of course, https://xkcd.com/1597/ https://xkcd.com/1597/ applies as well.
  - Zambyte 2y ago
    After learning Jujutsu, I realized this is really wrong. The underlying data structures and operations are great, and they serve their purposes really well (such as supporting 10k+ people collaborating like you mentioned). They are what makes git great. The git command line interface is a needlessly complex abstraction on top of them that tries to encourage certain behaviors, but does a really bad job at it.
    - vrinsd 2y ago
      100% agree. The fact there are 5 different ways to do the same thing is BAD, not good. Have one well defined, documented clear way to solve a problem.
      - fragmede 2y ago
        There are 3 different ways I could get to the store, I could walk or drive or bicycle. There are also 3 different paths I can take. I could go down road A, sidestreet B, or alleyway C. I know you'd rather one big button to press that just says "do it" on it, but in order to perform complex actions on complex objects, there are going to be multiple ways to accomplish the same thing.
        ladzoppelin 2y ago
        But what if one of the ways to the store is dangerous once in a while but usually safe and always just as fast as the other 2 ways to the store.. Laziness has nothing to with the posters question. There is nothing wrong with Git , I just don't agree with the comparison.
        fragmede 2y ago
        But if the dangerous route takes only 15 minutes, and the safe ones take an hour, why shouldn't I, being fully aware of the risks, have the option to take it when I want to? I don't know where I called anyone lazy.
- wsc981 2y ago
  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.
- vrinsd 2y ago
  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.
  - 8n4vidtmkvmk 2y ago
    There's a C version of hg, and more recently a rust version. I can't say how much faster they are though
    - wakawaka28 2y ago
      I don't think those other implementations were ever finished.
  - wakawaka28 2y ago
    > 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. I used to think Mercurial had a better UI but I changed my mind after taking the time to understand Git. Mercurial does have nifty features but Git's way of working isn't hard or especially counterintuitive. You must learn the terminology to properly understand it, but after that it's smooth sailing. Git actually has fewer moving parts than Mercurial, as there are less extraneous features. Instead of 3 or more categories of "branch-like" graph structures like Mercurial, you get branches as refs in Git. Every named leaf in the commit graph is a branch or a tag, and those have simple properties. There are surely git plugins to add more metadata but you don't really need that. Git too has a web interface by default: https://git-scm.com/docs/gitweb https://git-scm.com/docs/gitweb Of course there are many Github-like solutions specifically catered to hosting repos and entire project workflows with Git too.
- sam_bristow 2y ago
  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.
  - tambourine_man 2y ago
    Why was that?
  - marssaxman 2y ago
    The addition of `switch` and `restore` has probably reduced my daily cursing-at-git rate by half.
- tasuki 2y ago
  Git is not complex. Its UI is! Git is very simple. It is built on just four concepts: blobs, trees, commits, refs.
- eviks 2y ago
  Because good UI design requires a different skill and takes extra effort to achieve, so it's most often just ignored
thecrims0nchin 2y ago
I liked the way I learned git. I started with sourcetree, a third party git gui. Super simple to use and understand. Then I moved to git gui, this step could be skipped. Then I got tired of pulling up my UIs and learned the terminal commands. Highly suggest this for anyone new, but just my (n=1) experience.
- SoftTalker 2y ago
  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.
  - lacedeconstruct 2y ago
    Life is simple until we play with time, once you start altering the past everything falls apart
    - knighthack 2y ago
      This... seems a bit deeper than a comment about just Git.
    - Zambyte 2y ago
      It's not possible to alter commits with git. They are immutable. You can only make new commits that are based on existing ones in some way. The distinction is important, because the original commit (such as a commit pre-rebase) still exists after it's been "changed".
      - jcranmer 2y ago
        > The distinction is important, because the original commit (such as a commit pre-rebase) still exists after it's been "changed". The original commit will only exist for as long as git deigns not to garbage collect it.
      - deleted 2y ago
        [deleted]
ruraljuror 2y ago
Love this. I would add: git commit —-fixup $COMMIT_ID combined with git rebase -i upstream/master —autosquash These have become staples of my recent workflow. Julia’s example uses HEAD^^^^^ to rebase the previous 5 commits. I have been doing this as HEAD~5, until recently I realized you can just rebase all commits up to the upstream HEAD.
- lathiat 2y ago
  I only recently learnt this one, it's great for working with stacked patches in gerrit.
- mwpmaybe 2y ago
  Ahh, thank you: git commit —-fixup $COMMIT_ID I'm adopting this immediately. I always make little "oops <topic>" commits like "oops GET users/me" and then manually move and fixup them on my next interactive rebase. This is much better!
behnamoh 2y ago
Are there git alternatives that aren't a PITA to master before one can use them in production?
- vrinsd 2y ago
  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.
  - vrinsd 2y ago
    This whole thread got me to go back and see what else is out there and I remembered there's another (potentially) saner choice: Fossil : https://www.fossil-scm.org/home/doc/trunk/www/index.wiki https://www.fossil-scm.org/home/doc/trunk/www/index.wiki I haven't used it myself but I might for a solo project I'm involved in right now. A good read (not my article, linked from the Fossil site): https://wholesomedonut.prose.sh/using-fossil-not-git https://wholesomedonut.prose.sh/using-fossil-not-git
- cjensen 2y ago
  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.
mariocesar 2y ago
I didn't know about `git add -p`. Really useful! -p, --patch Interactively choose hunks of patch between the index and the work tree and add them to the index. This gives the user a chance to review the difference before adding modified contents to the index.
- Fellshard 2y ago
  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.
nomilk 2y ago
A couple of hidden gems: git diff --staged (shows the diff between the last commit and what you've got staged, great when what you're staging is finicky, lets you double check that you have precisely the files/hunks you intended) git log <file> (git log, but for just commits where <file> was touched; saves pilfering through all of git log, especially useful when the file only gets modified infrequently) Random tip: when using git add --patch, try the 'e' option if you need more nuance than the hunks git provides (it contains instructions for how to ex/include individual lines, so you don't have to remember how to do it).
- omginternets 2y ago
  15 years… 15 years to discover git diff --staged !
  - neoecos 2y ago
    I don't consider myself a git savvy person, but the help gives output, and I think this command is used a lot
- m0zzie 2y ago
  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?!
  - anbotero 2y ago
    Same here. Just make it an alias: ds. I’m using git dc, but it seems ds may be my new one, haha.
- Falimonda 2y ago
  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 https://gitlab.com/Falimonda/gitrc
- 2y ago
ChrisMarshallNY 2y ago
She delivers, yet again. Thanks!
johnwheeler 2y ago
I'll say it aloud: People need to drop git and look at JJ https://martinvonz.github.io/jj/v0.17.1/ https://martinvonz.github.io/jj/v0.17.1/ I think even Linus thinks git has a shitty UI. JJ has an amazing workflow.
- pixelesque 2y ago
  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...
jmercouris 2y ago
If you aren't already, you can also try Magit. It really helps one master and interact with Git.
Panzer04 2y ago
I always find it interesting how knowledge makes it hard to comprehend the difficulties other people have. I used to barely understand git, but after a couple of years working at a company that relies on a rebase workflow, I'd like to think I largely understand how it works. Its nice to recognise pretty much every operation on this cheatsheet. Is it common that developers still have issues with git after using it professionally for a couple of years? Admittedly, I still have trouble remembering the commands to do what I want (hello, rebase --onto A B C), though :P.
- nomilk 2y ago
  > 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 https://academia.stackexchange.com/q/163747/132074 [2] https://en.wikipedia.org/wiki/Curse_of_knowledge https://en.wikipedia.org/wiki/Curse_of_knowledge
  - acjohnson55 2y ago
    The skillset to navigate this is one of the underappreciated challenges of teaching.
    - vsnf 2y ago
      Exactly zero of my mathematics professors, and a large portion of my CS professors managed to adequately account for this. The professors of mine who did manage it remain firmly in my memories as great people and great teachers, while the one's who didn't inhabit an area between complete memory erasure, and disdain for how hard they made my life. This is at the very core of what it means to be a teacher, not just knowing the material, but knowing how to teach the material. I consider many of them to be failures at their main job for failing to navigate the curse.
      - 2y ago
codenlearn 2y ago
the one thing that is handy and missing here is creating and pushing tags.
ashconnor 2y ago
>squash the last 5 commits into one: `git rebase -i HEAD^^^^^^` Shouldn't this be: `git rebase -i HEAD~5` ? Assuming you only want to rebase linear history. https://stackoverflow.com/questions/2221658/whats-the-difference-between-head-and-head-in-git https://stackoverflow.com/questions/2221658/whats-the-differ...
wyldfire 2y ago
The biggest eye opener for me is understanding that all those commits are "still in there". Tags and branches merely point to a commit and the commit that branch used to apply to isn't gone. Many (probably fair to say "nearly all"?) commands will be non destructive in that you can easily refer to older incarnations of your branch. I'd seen "git reflog" but mostly used it to remind me of "that branch I worked on a while ago". I gained a semi-healthy fear of operations that could land me in the middle of a conflict resolution that I wasn't interested in handling right now (often because the conflict occurred because I was referring to the wrong commit/branch). I haven't completely cured that fear but at least I feel pretty comfortable recovering any old work among rebases, etc.
- Zambyte 2y ago
  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.
iamcreasy 2y ago
git reset HEAD is nifty way to unstage everything! Really cool!
_blz2 2y ago
Read once here, the best cheat sheet is one you create yourself. In my case, with fish shell or bash history search with fzf, I've effectively created a cheat sheet of commands I frequently tend to use with working examples. Seems to be working for me so far.
pncnmnp 2y ago
I have a funny little habit that probably stems from a certain degree of paranoia when working on a decent-sized change. I like to keep a local patch of it, as follows: "git diff > works.patch" Later on, you can apply it if necessary with "git apply works.patch".
- erik_seaberg 2y ago
  Do you find that better than a stash or a branch because it shows up in ls?
  - pncnmnp 2y ago
    Yes, it can be nice as an archival thing. Keep a directory filled with experimental patches you made to certain parts of your code. Maybe branches are better for certain use cases. I use stash too, but for different purposes. For instance, when I'd like to quickly change branches to fix a bug/issue and then come back to my stuff. Sometimes, I use stash for resolving potentially complicated pre-commit merges as well.
- BossingAround 2y ago
  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.
  - puddingvlaai 2y ago
    Instead of looking up the commit hash in your reflog, you could also just create a branch on that commit and refer to the commit with the branch name.
1000100_1000101 2y ago
One of faves isn't listed. git log -LstartLine,endLine:fileName It's like an extended git blame, showing how the specified lines evolved over time, and by who. Tracks the change as the line numbers evolve, and even as the file is moved. Answers the questions of "who did this, when, and why?" / "How long has it been like that?", etc.
lordmoma 2y ago
this is a better one: https://medium.com/@lordmoma/so-you-think-you-know-git-673f9c4b0792 https://medium.com/@lordmoma/so-you-think-you-know-git-673f9...
- AnonC 2y ago
  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.
  - SushiHippie 2y ago
    Non login-walled link: https://webcache.googleusercontent.com/search?q=cache:https://medium.com/@lordmoma/so-you-think-you-know-git-673f9c4b0792 https://webcache.googleusercontent.com/search?q=cache:https:...
    - CRConrad 2y ago
      Thanks, but alas, doesn't work: I can see the content flash by for an instant, but then it goes away and there's only some Google boilerplate text.
rezonant 2y ago
One thing missing that I use all the time, "git cherry". Without arguments it will show you what commits in your local branch are not in your remote tracking branch. Use "git cherry <ref>" to list the commits in the current branch that are not in the given ref. Most simple use is to know what you are about to push. Second use case is getting a commit list for release notes when using deployment/promotion branches. Super useful, I thought everyone used it but maybe some don't know!
shmerl 2y ago
For listing branches, git branch -vv gives some more info.
abalone 2y ago
This is great, especially the little diagrams which help illustrate rebasing vs merging, one of the tricker parts of the git learning curve. Having said that I think it could more clearly state the author's typical preferred practice for updating a branch and integrating it with main when you're done. There's a few techniques listed for diverged branches, but then fast-forward merge is in its own box and it's not super clear how you might use working-branch rebasing with it to eliminate divergences in the first place (even though it's hinted at under "pull changes"). I wonder if it would be clearer to say something like "combining branches: rebase your branch and do a (FF) merge, optionally with squashing," or however they like to do it.
koito17 2y ago
Cool cheat sheet, especially because it covers common use cases. But practically everything covered here I was able to learn independently with Magit. It's also much easier to press one or two keys in the magit-status buffer than to open a terminal and manually type git commands, so I pretty much never use the git CLI directly, not even for a clone.
- wodenokoto 2y ago
  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.
  - noman-land 2y ago
    I had this exact experience trying to install Common Lisp. Installed emacs and wtfed out of there 30 min later having learned nothing and feeling slightly traumatized.
- plowjockey 2y ago
  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.
redbell 2y ago
"There are only two hard things in Computer Science: cache invalidation and naming things." - Phil Karlton [0] Based on the above statement, I find it extremely weird to see such git command named "blame", then I realized I'm not the only one: What does 'git blame' do? [1]. Blame someone else for your bad code [2]. Git blame should be called git credit [3]. Does Git Blame sound too negative? [4]. ______________________________ 0. https://skeptics.stackexchange.com/questions/19836/has-phil-karlton-ever-said-there-are-only-two-hard-things-in-computer-science https://skeptics.stackexchange.com/questions/19836/has-phil-... 1. https://stackoverflow.com/questions/31203001/what-does-git-blame-do https://stackoverflow.com/questions/31203001/what-does-git-b... 2. https://news.ycombinator.com/item?id=27963868 https://news.ycombinator.com/item?id=27963868 3. https://dev.to/damcosset/git-blame-should-be-called-git-credit-27h5 https://dev.to/damcosset/git-blame-should-be-called-git-cred... 4. https://www.reddit.com/r/ProgrammerHumor/comments/r5lzyo/does_git_blame_sound_too_negative_just_look_up/ https://www.reddit.com/r/ProgrammerHumor/comments/r5lzyo/doe...
- leipert 2y ago
  I think a better name would be “git praise”
  - petepete 2y ago
    I'm sure you know this, but for younger readers, in Subversion 'praise' was an alias for 'blame'. For neutrality, 'annotate’ was another alias.
  - omoikane 2y ago
    One advantage that "git blame" has over possible alternatives such as "git credit", "git author", or "git praise", is that it's one character shorter and maybe faster to type. For the same number of characters, I have heard of "git glory" as a possible alternative.
- TiredOfLife 2y ago
  and off-by-one errors.
- 2y ago
KennyBlanken 2y ago
These cheat sheets are a great idea spoiled somewhat by the use of an infuriatingly annoying-to-read font. If your mission is to make hard topics easier to understand, why are you using a hard-to-read font whose only purpose is to make the cheat sheet look folksy?
wodenokoto 2y ago
> Find every commit that added or removed some text > git log -S banana I literally spend half an hour the other day having an argument with chatGPT about how I could find versions of a file that contained a specific string. Guess I should have asked for commits and not versions of files.
- kzrdude 2y ago
  git log -G is much more often what I want - diff contains some text but doesn't necessarily add or remove it.
Dban1 2y ago
git fetch origin <branch_name>:<branch_name> to update a branch while you're on another branch
timvisee 2y ago
`git rebase --onto FIRST_ID^ NEW_PARENT` is also super powerful to put a series of commits on top of a new parent when history has changed. That happens with PRs and squash merges quite often. https://stackoverflow.com/a/29916361/1000145 https://stackoverflow.com/a/29916361/1000145
thefz 2y ago
Julia Evans' content is always high quality.
rswail 2y ago
Git has its quirks, but the underlying model is good. There's some naming problems, like I just had to explain lightweight tags vs annotated ones to some newbies. The lightweight ones should have had a different name, like "bookmarks" or something.
incognito124 2y ago
Try JJ: https://github.com/martinvonz/jj https://github.com/martinvonz/jj
geekster777 2y ago
Every cheat sheet like this highlights the surprisingly high learning curve of the git cli. It's an interface that really ships it's underlying data model rather than optimizing for common workflows. This isn't necessarily a bad thing, but I often feel like the target audience of git is the power user, leaving me uncertain anytime I need to perform an intermediate level action. Lately I've been enjoying Graphite as a tool to interface with git. Commands are based around atomic actions I want to perform, despite often triggering multiple git commands under the hood. This has reduced my overall mental overhead, and removed many footguns.
adamsilkey 2y ago
Maybe my favorite option is missing here. `git commit -v` This will put the diff of the commit into your commit message as comments. Makes it easy to remember what you're doing/committing without having to jump back to the terminal/someplace else to look at the diff.
looshch 2y ago
i have many aliases [1] for everything i ever need to do in git, serves me great for the past couple of years [1] https://github.com/looshch/configs/blob/master/.gitconfig https://github.com/looshch/configs/blob/master/.gitconfig

Is there a historical reason why git is needlessly complex? Seeing this cheat sheet really brings it to life.

jimbob45 2y ago
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-git-at-google#genuine https://sandeep.ramgolam.com/blog/linus-torvalds-talks-about...
fragmede 2y ago
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 https://learngitbranching.js.org for learning how to navigate around git. but of course, https://xkcd.com/1597/ https://xkcd.com/1597/ applies as well.
- Zambyte 2y ago
  After learning Jujutsu, I realized this is really wrong. The underlying data structures and operations are great, and they serve their purposes really well (such as supporting 10k+ people collaborating like you mentioned). They are what makes git great. The git command line interface is a needlessly complex abstraction on top of them that tries to encourage certain behaviors, but does a really bad job at it.
  - vrinsd 2y ago
    100% agree. The fact there are 5 different ways to do the same thing is BAD, not good. Have one well defined, documented clear way to solve a problem.
    - fragmede 2y ago
      There are 3 different ways I could get to the store, I could walk or drive or bicycle. There are also 3 different paths I can take. I could go down road A, sidestreet B, or alleyway C. I know you'd rather one big button to press that just says "do it" on it, but in order to perform complex actions on complex objects, there are going to be multiple ways to accomplish the same thing.
      - ladzoppelin 2y ago
        But what if one of the ways to the store is dangerous once in a while but usually safe and always just as fast as the other 2 ways to the store.. Laziness has nothing to with the posters question. There is nothing wrong with Git , I just don't agree with the comparison.
        fragmede 2y ago
        But if the dangerous route takes only 15 minutes, and the safe ones take an hour, why shouldn't I, being fully aware of the risks, have the option to take it when I want to? I don't know where I called anyone lazy.
wsc981 2y ago
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.
vrinsd 2y ago
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.
- 8n4vidtmkvmk 2y ago
  There's a C version of hg, and more recently a rust version. I can't say how much faster they are though
  - wakawaka28 2y ago
    I don't think those other implementations were ever finished.
- wakawaka28 2y ago
  > 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. I used to think Mercurial had a better UI but I changed my mind after taking the time to understand Git. Mercurial does have nifty features but Git's way of working isn't hard or especially counterintuitive. You must learn the terminology to properly understand it, but after that it's smooth sailing. Git actually has fewer moving parts than Mercurial, as there are less extraneous features. Instead of 3 or more categories of "branch-like" graph structures like Mercurial, you get branches as refs in Git. Every named leaf in the commit graph is a branch or a tag, and those have simple properties. There are surely git plugins to add more metadata but you don't really need that. Git too has a web interface by default: https://git-scm.com/docs/gitweb https://git-scm.com/docs/gitweb Of course there are many Github-like solutions specifically catered to hosting repos and entire project workflows with Git too.
sam_bristow 2y ago
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.
- tambourine_man 2y ago
  Why was that?
- marssaxman 2y ago
  The addition of `switch` and `restore` has probably reduced my daily cursing-at-git rate by half.
tasuki 2y ago
Git is not complex. Its UI is! Git is very simple. It is built on just four concepts: blobs, trees, commits, refs.
eviks 2y ago
Because good UI design requires a different skill and takes extra effort to achieve, so it's most often just ignored

I liked the way I learned git. I started with sourcetree, a third party git gui. Super simple to use and understand. Then I moved to git gui, this step could be skipped. Then I got tired of pulling up my UIs and learned the terminal commands. Highly suggest this for anyone new, but just my (n=1) experience.

SoftTalker 2y ago
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.
- lacedeconstruct 2y ago
  Life is simple until we play with time, once you start altering the past everything falls apart
  - knighthack 2y ago
    This... seems a bit deeper than a comment about just Git.
  - Zambyte 2y ago
    It's not possible to alter commits with git. They are immutable. You can only make new commits that are based on existing ones in some way. The distinction is important, because the original commit (such as a commit pre-rebase) still exists after it's been "changed".
    - jcranmer 2y ago
      > The distinction is important, because the original commit (such as a commit pre-rebase) still exists after it's been "changed". The original commit will only exist for as long as git deigns not to garbage collect it.
    - deleted 2y ago
      [deleted]

ruraljuror 2y ago

Love this. I would add: git commit —-fixup $COMMIT_ID combined with git rebase -i upstream/master —autosquash These have become staples of my recent workflow. Julia’s example uses HEAD^^^^^ to rebase the previous 5 commits. I have been doing this as HEAD~5, until recently I realized you can just rebase all commits up to the upstream HEAD.

lathiat 2y ago
I only recently learnt this one, it's great for working with stacked patches in gerrit.
mwpmaybe 2y ago
Ahh, thank you: git commit —-fixup $COMMIT_ID I'm adopting this immediately. I always make little "oops <topic>" commits like "oops GET users/me" and then manually move and fixup them on my next interactive rebase. This is much better!

behnamoh 2y ago

Are there git alternatives that aren't a PITA to master before one can use them in production?

vrinsd 2y ago
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.
- vrinsd 2y ago
  This whole thread got me to go back and see what else is out there and I remembered there's another (potentially) saner choice: Fossil : https://www.fossil-scm.org/home/doc/trunk/www/index.wiki https://www.fossil-scm.org/home/doc/trunk/www/index.wiki I haven't used it myself but I might for a solo project I'm involved in right now. A good read (not my article, linked from the Fossil site): https://wholesomedonut.prose.sh/using-fossil-not-git https://wholesomedonut.prose.sh/using-fossil-not-git
cjensen 2y ago
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.

mariocesar 2y ago

I didn't know about `git add -p`. Really useful! -p, --patch Interactively choose hunks of patch between the index and the work tree and add them to the index. This gives the user a chance to review the difference before adding modified contents to the index.

Fellshard 2y ago
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.

nomilk 2y ago

A couple of hidden gems: git diff --staged (shows the diff between the last commit and what you've got staged, great when what you're staging is finicky, lets you double check that you have precisely the files/hunks you intended) git log <file> (git log, but for just commits where <file> was touched; saves pilfering through all of git log, especially useful when the file only gets modified infrequently) Random tip: when using git add --patch, try the 'e' option if you need more nuance than the hunks git provides (it contains instructions for how to ex/include individual lines, so you don't have to remember how to do it).

omginternets 2y ago
15 years… 15 years to discover git diff --staged !
- neoecos 2y ago
  I don't consider myself a git savvy person, but the help gives output, and I think this command is used a lot
m0zzie 2y ago
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?!
- anbotero 2y ago
  Same here. Just make it an alias: ds. I’m using git dc, but it seems ds may be my new one, haha.
Falimonda 2y ago
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 https://gitlab.com/Falimonda/gitrc
2y ago

ChrisMarshallNY 2y ago

She delivers, yet again. Thanks!

johnwheeler 2y ago

I'll say it aloud: People need to drop git and look at JJ https://martinvonz.github.io/jj/v0.17.1/ https://martinvonz.github.io/jj/v0.17.1/ I think even Linus thinks git has a shitty UI. JJ has an amazing workflow.

pixelesque 2y ago
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...

jmercouris 2y ago

If you aren't already, you can also try Magit. It really helps one master and interact with Git.

Panzer04 2y ago

I always find it interesting how knowledge makes it hard to comprehend the difficulties other people have. I used to barely understand git, but after a couple of years working at a company that relies on a rebase workflow, I'd like to think I largely understand how it works. Its nice to recognise pretty much every operation on this cheatsheet. Is it common that developers still have issues with git after using it professionally for a couple of years? Admittedly, I still have trouble remembering the commands to do what I want (hello, rebase --onto A B C), though :P.

nomilk 2y ago
> 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 https://academia.stackexchange.com/q/163747/132074 [2] https://en.wikipedia.org/wiki/Curse_of_knowledge https://en.wikipedia.org/wiki/Curse_of_knowledge
- acjohnson55 2y ago
  The skillset to navigate this is one of the underappreciated challenges of teaching.
  - vsnf 2y ago
    Exactly zero of my mathematics professors, and a large portion of my CS professors managed to adequately account for this. The professors of mine who did manage it remain firmly in my memories as great people and great teachers, while the one's who didn't inhabit an area between complete memory erasure, and disdain for how hard they made my life. This is at the very core of what it means to be a teacher, not just knowing the material, but knowing how to teach the material. I consider many of them to be failures at their main job for failing to navigate the curse.
    - 2y ago

codenlearn 2y ago

the one thing that is handy and missing here is creating and pushing tags.

ashconnor 2y ago

>squash the last 5 commits into one: `git rebase -i HEAD^^^^^^` Shouldn't this be: `git rebase -i HEAD~5` ? Assuming you only want to rebase linear history. https://stackoverflow.com/questions/2221658/whats-the-difference-between-head-and-head-in-git https://stackoverflow.com/questions/2221658/whats-the-differ...

wyldfire 2y ago

The biggest eye opener for me is understanding that all those commits are "still in there". Tags and branches merely point to a commit and the commit that branch used to apply to isn't gone. Many (probably fair to say "nearly all"?) commands will be non destructive in that you can easily refer to older incarnations of your branch. I'd seen "git reflog" but mostly used it to remind me of "that branch I worked on a while ago". I gained a semi-healthy fear of operations that could land me in the middle of a conflict resolution that I wasn't interested in handling right now (often because the conflict occurred because I was referring to the wrong commit/branch). I haven't completely cured that fear but at least I feel pretty comfortable recovering any old work among rebases, etc.

Zambyte 2y ago
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.

iamcreasy 2y ago

git reset HEAD is nifty way to unstage everything! Really cool!

_blz2 2y ago

Read once here, the best cheat sheet is one you create yourself. In my case, with fish shell or bash history search with fzf, I've effectively created a cheat sheet of commands I frequently tend to use with working examples. Seems to be working for me so far.

pncnmnp 2y ago

I have a funny little habit that probably stems from a certain degree of paranoia when working on a decent-sized change. I like to keep a local patch of it, as follows: "git diff > works.patch" Later on, you can apply it if necessary with "git apply works.patch".

erik_seaberg 2y ago
Do you find that better than a stash or a branch because it shows up in ls?
- pncnmnp 2y ago
  Yes, it can be nice as an archival thing. Keep a directory filled with experimental patches you made to certain parts of your code. Maybe branches are better for certain use cases. I use stash too, but for different purposes. For instance, when I'd like to quickly change branches to fix a bug/issue and then come back to my stuff. Sometimes, I use stash for resolving potentially complicated pre-commit merges as well.
BossingAround 2y ago
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.
- puddingvlaai 2y ago
  Instead of looking up the commit hash in your reflog, you could also just create a branch on that commit and refer to the commit with the branch name.

1000100_1000101 2y ago

One of faves isn't listed. git log -LstartLine,endLine:fileName It's like an extended git blame, showing how the specified lines evolved over time, and by who. Tracks the change as the line numbers evolve, and even as the file is moved. Answers the questions of "who did this, when, and why?" / "How long has it been like that?", etc.

lordmoma 2y ago

this is a better one: https://medium.com/@lordmoma/so-you-think-you-know-git-673f9c4b0792 https://medium.com/@lordmoma/so-you-think-you-know-git-673f9...

AnonC 2y ago
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.
- SushiHippie 2y ago
  Non login-walled link: https://webcache.googleusercontent.com/search?q=cache:https://medium.com/@lordmoma/so-you-think-you-know-git-673f9c4b0792 https://webcache.googleusercontent.com/search?q=cache:https:...
  - CRConrad 2y ago
    Thanks, but alas, doesn't work: I can see the content flash by for an instant, but then it goes away and there's only some Google boilerplate text.

rezonant 2y ago

One thing missing that I use all the time, "git cherry". Without arguments it will show you what commits in your local branch are not in your remote tracking branch. Use "git cherry <ref>" to list the commits in the current branch that are not in the given ref. Most simple use is to know what you are about to push. Second use case is getting a commit list for release notes when using deployment/promotion branches. Super useful, I thought everyone used it but maybe some don't know!

shmerl 2y ago

For listing branches, git branch -vv gives some more info.

abalone 2y ago

This is great, especially the little diagrams which help illustrate rebasing vs merging, one of the tricker parts of the git learning curve. Having said that I think it could more clearly state the author's typical preferred practice for updating a branch and integrating it with main when you're done. There's a few techniques listed for diverged branches, but then fast-forward merge is in its own box and it's not super clear how you might use working-branch rebasing with it to eliminate divergences in the first place (even though it's hinted at under "pull changes"). I wonder if it would be clearer to say something like "combining branches: rebase your branch and do a (FF) merge, optionally with squashing," or however they like to do it.

koito17 2y ago

Cool cheat sheet, especially because it covers common use cases. But practically everything covered here I was able to learn independently with Magit. It's also much easier to press one or two keys in the magit-status buffer than to open a terminal and manually type git commands, so I pretty much never use the git CLI directly, not even for a clone.

wodenokoto 2y ago
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.
- noman-land 2y ago
  I had this exact experience trying to install Common Lisp. Installed emacs and wtfed out of there 30 min later having learned nothing and feeling slightly traumatized.
plowjockey 2y ago
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.

redbell 2y ago

"There are only two hard things in Computer Science: cache invalidation and naming things." - Phil Karlton [0] Based on the above statement, I find it extremely weird to see such git command named "blame", then I realized I'm not the only one: What does 'git blame' do? [1]. Blame someone else for your bad code [2]. Git blame should be called git credit [3]. Does Git Blame sound too negative? [4]. ______________________________ 0. https://skeptics.stackexchange.com/questions/19836/has-phil-karlton-ever-said-there-are-only-two-hard-things-in-computer-science https://skeptics.stackexchange.com/questions/19836/has-phil-... 1. https://stackoverflow.com/questions/31203001/what-does-git-blame-do https://stackoverflow.com/questions/31203001/what-does-git-b... 2. https://news.ycombinator.com/item?id=27963868 https://news.ycombinator.com/item?id=27963868 3. https://dev.to/damcosset/git-blame-should-be-called-git-credit-27h5 https://dev.to/damcosset/git-blame-should-be-called-git-cred... 4. https://www.reddit.com/r/ProgrammerHumor/comments/r5lzyo/does_git_blame_sound_too_negative_just_look_up/ https://www.reddit.com/r/ProgrammerHumor/comments/r5lzyo/doe...

leipert 2y ago
I think a better name would be “git praise”
- petepete 2y ago
  I'm sure you know this, but for younger readers, in Subversion 'praise' was an alias for 'blame'. For neutrality, 'annotate’ was another alias.
- omoikane 2y ago
  One advantage that "git blame" has over possible alternatives such as "git credit", "git author", or "git praise", is that it's one character shorter and maybe faster to type. For the same number of characters, I have heard of "git glory" as a possible alternative.
TiredOfLife 2y ago
and off-by-one errors.
2y ago

KennyBlanken 2y ago

These cheat sheets are a great idea spoiled somewhat by the use of an infuriatingly annoying-to-read font. If your mission is to make hard topics easier to understand, why are you using a hard-to-read font whose only purpose is to make the cheat sheet look folksy?

wodenokoto 2y ago

> Find every commit that added or removed some text > git log -S banana I literally spend half an hour the other day having an argument with chatGPT about how I could find versions of a file that contained a specific string. Guess I should have asked for commits and not versions of files.

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

Dban1 2y ago

git fetch origin <branch_name>:<branch_name> to update a branch while you're on another branch

timvisee 2y ago

`git rebase --onto FIRST_ID^ NEW_PARENT` is also super powerful to put a series of commits on top of a new parent when history has changed. That happens with PRs and squash merges quite often. https://stackoverflow.com/a/29916361/1000145 https://stackoverflow.com/a/29916361/1000145

thefz 2y ago

Julia Evans' content is always high quality.

rswail 2y ago

Git has its quirks, but the underlying model is good. There's some naming problems, like I just had to explain lightweight tags vs annotated ones to some newbies. The lightweight ones should have had a different name, like "bookmarks" or something.

incognito124 2y ago

Try JJ: https://github.com/martinvonz/jj https://github.com/martinvonz/jj

geekster777 2y ago

Every cheat sheet like this highlights the surprisingly high learning curve of the git cli. It's an interface that really ships it's underlying data model rather than optimizing for common workflows. This isn't necessarily a bad thing, but I often feel like the target audience of git is the power user, leaving me uncertain anytime I need to perform an intermediate level action. Lately I've been enjoying Graphite as a tool to interface with git. Commands are based around atomic actions I want to perform, despite often triggering multiple git commands under the hood. This has reduced my overall mental overhead, and removed many footguns.

adamsilkey 2y ago

Maybe my favorite option is missing here. `git commit -v` This will put the diff of the commit into your commit message as comments. Makes it easy to remember what you're doing/committing without having to jump back to the terminal/someplace else to look at the diff.

looshch 2y ago

i have many aliases [1] for everything i ever need to do in git, serves me great for the past couple of years [1] https://github.com/looshch/configs/blob/master/.gitconfig https://github.com/looshch/configs/blob/master/.gitconfig