12 ms·

Git In Two Minutes (updated after 8 years)

351 points by garyrob 4y ago

garyrob 4y ago
About 8 years ago, I blogged a very brief guide to using git for a solo developer. A lot of people seemed to like it. A couple times since then, I've noticed there was something I was using that wasn't in it, but that could be added without making it significantly longer or more complicated. So there were a couple of updates. I did another one today, and had the thought that since this guide now includes the benefit of 8 years of practical experience in actually using it, while still essentially being "Git In Two Minutes", it might be worth posting to HN. So here it is. It doesn't say anything about github. It really is for a solo developer who wants to start using git in a very painless way. With the additional goal that you can profitably use git for years without going beyond the described features. https://www.garyrobinson.net/2014/10/git-in-two-minutes-for-a-solo-developer.html https://www.garyrobinson.net/2014/10/git-in-two-minutes-for-...
- Izkata 4y ago
  A couple notes: * Since it's an introduction maybe consider "--oneline" instead of "--pretty=oneline" for memorability * Undoing a bad commit - since it mentions a commit message typo, maybe instead redo it with "git commit --amend"
- boredemployee 4y ago
  thank you very much. I'm always reluctant to read/watch any git tutorial, I think that will help me a lot!
  - garyrob 4y ago
    I hope it does!
- notRobot 4y ago
  Thank you for this!
- moritonal 4y ago
  Hey, just a heads up (won't be a problem for most people Goolging git) but on mobile (Firefox) the code blocks are almost unreadable because they're so small.
- noja 4y ago
  Without switch and restore, it is not modern git!
anderskaseorg 4y ago
These days it might be better to teach new users about ‘git switch’ and ‘git restore’ (added in Git 2.23, released 2019-08-16) rather than the two overloaded meanings of the confusing ‘git checkout’ command. https://git-scm.com/docs/git-switch https://git-scm.com/docs/git-switch https://git-scm.com/docs/git-restore https://git-scm.com/docs/git-restore
- garyrob 4y ago
  I'll look into that, thanks!
- malkia 4y ago
  First of all, I'm long time going git n00b (still mainly p4, and g4 for a bit user), but welcome any hints to easy going with git (have to use it occassionally). Saw this though for switch/restore: "THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE."
  - garyrob 4y ago
    Hmm, maybe I should leave as-is, for the time being, anyway! Thank you! Update: based on other comments, I WILL seriously look into replacing the use of checkout. It sounds like these newer features are probably stable enough for the simple things that are being done in the blog post, and that updating the post will more it a bit more useful as a starting point for learning git. I'm thinking of posting the modern syntax as an alternative rather than a replacement to checkout, but I have yet to investigate how stable things are now... will do when I have time. But meanwhile, the checkout method is fine, it works, and it's well-established for many years.
    - NoahKAndrews 4y ago
      I think this Reddit comment has the right idea, especially now that those commands have been released for 3 years: https://www.reddit.com/r/git/comments/ifkbfz/comment/g2on6yo/ https://www.reddit.com/r/git/comments/ifkbfz/comment/g2on6yo...
ducktective 4y ago
obligatory `lazygit` plugging. I do this because this project is criminally underrated: https://github.com/jesseduffield/lazygit https://github.com/jesseduffield/lazygit
demarq 4y ago
Guides like these are an absolute treasure when on-boarding junior devs. It can be really difficult distilling all you know about a certain topic into something short and concise like this.
- malkia 4y ago
  Hey not only junior developers - there are senior ones (like me) that need it too! So thanks for all these "one-pagers" that are easy to remember.
  - demarq 4y ago
    haha but of course!
spaceman_2020 4y ago
as a noob trying to pick up coding just to experiment with some ideas, I always found Git to be surprisingly confusing. I feel that a lot of the command names aren't very intuitive. Or am I just an idiot?
- sedatk 4y ago
  Git is confusing. Alternatives like Mercurial are way more intuitive and easier to use, but they lack popularity.
- probably_wrong 4y ago
  When it comes to git, I am firmly of the opinion that it's not you, it's them. Git is simple, but it takes a lot of experience to appreciate its simplicity. So don't beat yourself up, git is hard and it's okay to be lost.
  - CRConrad 4y ago
    > Git is simple, but it takes a lot of experience to appreciate its simplicity. So don't beat yourself up, git is hard and it's okay to be lost. Yet another example of how, as so often in programming, the "KISS principle" ("Keep It Simple, Stupid") is deceptive: Simple isn't (at least not always) equal with easy. But yeah, with a more well-thought-out set of commands it would have been a lot easier for a lot of people. I think it's just simply (heh!) that it was released a tad too early, before anyone had thought more deeply about keeping the syntax orthogonal, and the world's been stuck with those choices (largely, choices not made in the first place) ever since, for backwards compatibility.
- School-Cotton 4y ago
  I don't know whether you're an idiot or not, but thinking git is confusing is certainly not evidence to that effect. Git _is_ confusing; it became the de-facto standard because it was the first free DVCS (and DVCSs solve lots of problems that were common to old non-distributed VCSs), not because its UI is particularly well-designed.
- garyrob 4y ago
boustrophedon 4y ago
In both examples given in the "Undoing a bad commit" section (fixing a commit message and fixing an error in a file) it's easier to make the change and then run `git commit -a --amend` which takes the current changes you have and adds them to the last commit, allowing you to change the commit message as well. There are other cases where git reset is useful, but generally not for the reasons given.
candiddevmike 4y ago
Why do they have '--' as an argument in a lot of the commands? I don't think that's necessary?
- PeterWhittaker 4y ago
  To quote TFM: > This option can be used to separate command-line options from the list of files, (useful when filenames might be mistaken for command-line options). This is a common idiom, e.g., to grep a file for a pattern that matches a grep argument, > grep -- -e file Edit: fixed dash weirdness.
- gizmo686 4y ago
  It forces git to intereperet what comes after as paths. Normally this is not needed, but occasionally you get a filename that causes ambiguity. For instance, "git checkout test.c" will check out the file test.c unless you happen to have a branch called "test.c". (See also people complaining that checkout is overloaded". Simmilarly, "git add --verbose test.c" will add test.c, and log that to stdout. "git add -- --verbose test.c" will add test.c and --verbose, where "--verbose" is the name of a file. This isn't git specific, most CLI tools use "--" to restrict the parsing on arguements that follow.
kelthuzad 4y ago
I found the "Missing Semester" lectures on YouTube to be pretty helpful: Regarding git there is: Lecture 6: Version Control [0] [0] https://youtu.be/2sjqTHE0zok https://youtu.be/2sjqTHE0zok
ArrayBoundCheck 4y ago
I wish they made a breaking change in the next version and make the CLI actually usable. Before you downvote, ask yourself how do you list tags, branches and remote
- School-Cotton 4y ago
  They shouldn't break the existing `git` command as it is widely used in scripts. But there are projects that try to build better UIs on top of git; the most serious such attempt that I know of is magit.
- ajross 4y ago
  "git tag", "git branch -a", "git remote -v" You point is what, that these are needlessly asymmetric? It's true. But they're in my head because I do them every day, and it's not like I'm suffering under the burden of remembering a handful of flags. That's a pretty far cry from "not actually usable", so maybe your hyperbole is a little misplaced?
  - ArrayBoundCheck 4y ago
    Correct. That was a simple example that's easy to understand Anyone with half a brain can understand that if they can't keep something as simple as printing a list consistent you better believe nothing else will be straightforward. Which is my point. NOTHING is straightforward and I haven't met a single person who likes the CLI if they do anything more complex than a commit, push and pull. I know people who still refuse to use rebase and don't understand bisect or blame. They use a GUI to restore files
- PeterWhittaker 4y ago
  Branches are easy, what with them being only labels: > git branch --all Tags are different, since they are actual objects in git, but using ls-remote isn’t tough, and one could create an alias.
- mmcclimon 4y ago
  While acknowledging that git's CLI is often unintuitive: `git tag` lists tags, `git branch` lists branches, and `git remote` lists remotes, so I don't think I understand this particular objection.
probably_wrong 4y ago
> it it’s enough be useful for beginning solo developers, and provides a start from which you can grow. I like this guide a lot as a cheatsheet. However, when it comes to beginners I fear it is one of those things that make sense only when you already know what the guide is talking about. It would take me more than two minutes just to explain a completely new developer what a commit is and why they would want one. And God help us if I throw the output of "diff" at them without warning... The sad truth is, you cannot explain git in two minutes. I nonetheless admire the author for giving the problem a fair fight.
nmz 4y ago
Absolute crap article. You don't learn git in two minutes if you don't talk about rebase and remotes. You want to learn a dvcs in 2 minutes? try fossil.
- CRConrad 4y ago
  Absolute crap comment. You don't learn anything in two minutes if you don't even read the headline: > Git In Two Minutes (For A Solo Developer)
soupshield 4y ago
What do we call the "--" part in a command like this: git checkout HEAD -- <filename> I find it hard to remember things unless I understand their purpose. It looks like it's specifying an argument but without an argument name (e.g. --verbose), unless it's similar to a pipe | symbol and <filename> is being passed to the checkout command as some special kind of argument?
- swordbeta 4y ago
  https://unix.stackexchange.com/a/11382 https://unix.stackexchange.com/a/11382
- ttymck 4y ago
  It is a delimiter indicating the end of options: https://unix.stackexchange.com/questions/11376/what-does-double-dash-mean https://unix.stackexchange.com/questions/11376/what-does-dou...
- gizmo686 4y ago
  I don't know what it is called, but it forces what comes after to be interpreted as a filepath. This is not git specific, but a common convention for CLI tools. Try running: > touch -- -i foo > rm -- -i foo And compare what happens without the "--".
  - soupshield 4y ago
    Thank you for this brilliant explanation (complete with interactive example :) I completely get it now.
  - pojzon 4y ago
    Not only a filepath, this means pass anything past “—-“ ‘as is’ as an input and not an option flag. docker run -it nginx —- ls la
    - drdec 4y ago
      Not a file path specifically and not an input exactly but I think the proper word would be an argument.
carom 4y ago
How does this not mention git push? That and pull seem a lot more essential than everything that came after commit.
- CRConrad 4y ago
  > How does this not mention git push? Because it's about using git as a single-user, single-machine version control tool.
brasetvik 4y ago
It's not a single digit minute read, but to me "Git from the Bottom Up" was what really made me understand git a long time ago. https://jwiegley.github.io/git-from-the-bottom-up/ https://jwiegley.github.io/git-from-the-bottom-up/ git's the kind of tool where understanding how your commands operate on the underlying data structures will probably make it a lot easier to use efficiently. (And they're beautifully simple despite how powerful and flexible they are) As a tool you might be using for hours per week for a few more decades, it's worth the investment going beyond the "in x minutes". I tend to provide both to juniors. Obligatory: https://xkcd.com/1597/ https://xkcd.com/1597/
- copperx 4y ago
  Is is better than the Git Internals book?
quickthrower2 4y ago
In solo development I still revert rather than reset and don't force push. I see no harm in having history. You may even be glad you have it later on. Revert on the command line is very easy to use, maybe easier than reset as you don't need to think about whether it is hard or soft you want. Once vice I have for solo development that I won't do at work is really crappy commit messages. Like "ditto" for a commit that is similar to the one before or "typo" if I am just correcting a spelling mistake.
- stu2b50 4y ago
  I think that vice is honestly much better than another common vice: not committing because of commit message paralysis. If you don't commit, git is doing little to help you do anything. Commits, and their messages, can always be redone with an amend, or a rebase.
  - quickthrower2 4y ago
    This makes me think that messages should be a separate entity and not part of what computes the hash. So you can retrospectively change a message later on if it needs some more detail.
- jonahx 4y ago
  > I see no harm in having history. You want meaningful history, not unfiltered history. The harm is that the history is no longer as useful if it's not curated -- whether that's for tracking down the origin of a bug, or just using it to remember what you did a few weeks ago. It's easy to see the flaw in "keep everything" by taking the argument to its logical conclusion, which would be recording the history of every keystroke in your editor. If you have false starts or alternate approaches that you gave up on but think you might still want, by all means save them, just not in "main."
  - quickthrower2 4y ago
    You could use branches / tags for this purpose. Reverts are not too bad becuase they are pretty meaningful. If your commits are meaningful then the revert is "reverts: {meaniningful commit message}"
crossroadsguy 4y ago
This reminds me — what was that human readable “man” tool again? I think I had come across a homebrew package back in the day, that let you read command docs in a sane language, but lost track of it.
- tux2bsd 4y ago
  > man... that let you read command docs in a sane language That would be nice. It is a pity most man pages are elitist and lack good useful examples.
  - thijsvandien 4y ago
    My goto for useful examples is tldr: https://github.com/tldr-pages/tldr https://github.com/tldr-pages/tldr.
p4bl0 4y ago
I find it odd to have `git status` shown only at the end and presented as a bonus. That would have been the first command I would speak of after `git init`. I use it so often that I have an alias in my shell for it: `gis`. It shows all the relevant information and generally suggests commands that would perform what you might want to do in the situation you are in (new untracked files, tracked files changes, staged changes that you may want to unstage, merging conflicts, rebase in progress, etc.). It really helps with Git discoverability, which is not negligible when you set yourself to present such a complexe tool in two minutes!
bcoughlan 4y ago
Not as beginnery but I made a similar little cheat sheet showing how to explore the history of a codebase: https://bcoughlan.github.io/posts/git-detective-cheatsheet/ https://bcoughlan.github.io/posts/git-detective-cheatsheet/
d4rkp4ttern 4y ago
We need a copilot for the command line. For the bazillion times I have to look up stack-overflow for doing anything unusual with git, like undoing things etc. And not just git. Maybe some day there will be an oh-my-zsh plugin for copilot.

351 points by garyrob 4y ago

About 8 years ago, I blogged a very brief guide to using git for a solo developer. A lot of people seemed to like it. A couple times since then, I've noticed there was something I was using that wasn't in it, but that could be added without making it significantly longer or more complicated. So there were a couple of updates. I did another one today, and had the thought that since this guide now includes the benefit of 8 years of practical experience in actually using it, while still essentially being "Git In Two Minutes", it might be worth posting to HN. So here it is. It doesn't say anything about github. It really is for a solo developer who wants to start using git in a very painless way. With the additional goal that you can profitably use git for years without going beyond the described features. https://www.garyrobinson.net/2014/10/git-in-two-minutes-for-a-solo-developer.html https://www.garyrobinson.net/2014/10/git-in-two-minutes-for-...

Izkata 4y ago
A couple notes: * Since it's an introduction maybe consider "--oneline" instead of "--pretty=oneline" for memorability * Undoing a bad commit - since it mentions a commit message typo, maybe instead redo it with "git commit --amend"
boredemployee 4y ago
thank you very much. I'm always reluctant to read/watch any git tutorial, I think that will help me a lot!
- garyrob 4y ago
  I hope it does!
notRobot 4y ago
Thank you for this!
moritonal 4y ago
Hey, just a heads up (won't be a problem for most people Goolging git) but on mobile (Firefox) the code blocks are almost unreadable because they're so small.
noja 4y ago
Without switch and restore, it is not modern git!

anderskaseorg 4y ago

These days it might be better to teach new users about ‘git switch’ and ‘git restore’ (added in Git 2.23, released 2019-08-16) rather than the two overloaded meanings of the confusing ‘git checkout’ command. https://git-scm.com/docs/git-switch https://git-scm.com/docs/git-switch https://git-scm.com/docs/git-restore https://git-scm.com/docs/git-restore

garyrob 4y ago
I'll look into that, thanks!
malkia 4y ago
First of all, I'm long time going git n00b (still mainly p4, and g4 for a bit user), but welcome any hints to easy going with git (have to use it occassionally). Saw this though for switch/restore: "THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE."
- garyrob 4y ago
  Hmm, maybe I should leave as-is, for the time being, anyway! Thank you! Update: based on other comments, I WILL seriously look into replacing the use of checkout. It sounds like these newer features are probably stable enough for the simple things that are being done in the blog post, and that updating the post will more it a bit more useful as a starting point for learning git. I'm thinking of posting the modern syntax as an alternative rather than a replacement to checkout, but I have yet to investigate how stable things are now... will do when I have time. But meanwhile, the checkout method is fine, it works, and it's well-established for many years.
  - NoahKAndrews 4y ago
    I think this Reddit comment has the right idea, especially now that those commands have been released for 3 years: https://www.reddit.com/r/git/comments/ifkbfz/comment/g2on6yo/ https://www.reddit.com/r/git/comments/ifkbfz/comment/g2on6yo...

ducktective 4y ago

obligatory `lazygit` plugging. I do this because this project is criminally underrated: https://github.com/jesseduffield/lazygit https://github.com/jesseduffield/lazygit

demarq 4y ago

Guides like these are an absolute treasure when on-boarding junior devs. It can be really difficult distilling all you know about a certain topic into something short and concise like this.

malkia 4y ago
Hey not only junior developers - there are senior ones (like me) that need it too! So thanks for all these "one-pagers" that are easy to remember.
- demarq 4y ago
  haha but of course!

spaceman_2020 4y ago

as a noob trying to pick up coding just to experiment with some ideas, I always found Git to be surprisingly confusing. I feel that a lot of the command names aren't very intuitive. Or am I just an idiot?

sedatk 4y ago
Git is confusing. Alternatives like Mercurial are way more intuitive and easier to use, but they lack popularity.
probably_wrong 4y ago
When it comes to git, I am firmly of the opinion that it's not you, it's them. Git is simple, but it takes a lot of experience to appreciate its simplicity. So don't beat yourself up, git is hard and it's okay to be lost.
- CRConrad 4y ago
  > Git is simple, but it takes a lot of experience to appreciate its simplicity. So don't beat yourself up, git is hard and it's okay to be lost. Yet another example of how, as so often in programming, the "KISS principle" ("Keep It Simple, Stupid") is deceptive: Simple isn't (at least not always) equal with easy. But yeah, with a more well-thought-out set of commands it would have been a lot easier for a lot of people. I think it's just simply (heh!) that it was released a tad too early, before anyone had thought more deeply about keeping the syntax orthogonal, and the world's been stuck with those choices (largely, choices not made in the first place) ever since, for backwards compatibility.
School-Cotton 4y ago
I don't know whether you're an idiot or not, but thinking git is confusing is certainly not evidence to that effect. Git _is_ confusing; it became the de-facto standard because it was the first free DVCS (and DVCSs solve lots of problems that were common to old non-distributed VCSs), not because its UI is particularly well-designed.
garyrob 4y ago

boustrophedon 4y ago

In both examples given in the "Undoing a bad commit" section (fixing a commit message and fixing an error in a file) it's easier to make the change and then run `git commit -a --amend` which takes the current changes you have and adds them to the last commit, allowing you to change the commit message as well. There are other cases where git reset is useful, but generally not for the reasons given.

candiddevmike 4y ago

Why do they have '--' as an argument in a lot of the commands? I don't think that's necessary?

PeterWhittaker 4y ago
To quote TFM: > This option can be used to separate command-line options from the list of files, (useful when filenames might be mistaken for command-line options). This is a common idiom, e.g., to grep a file for a pattern that matches a grep argument, > grep -- -e file Edit: fixed dash weirdness.
gizmo686 4y ago
It forces git to intereperet what comes after as paths. Normally this is not needed, but occasionally you get a filename that causes ambiguity. For instance, "git checkout test.c" will check out the file test.c unless you happen to have a branch called "test.c". (See also people complaining that checkout is overloaded". Simmilarly, "git add --verbose test.c" will add test.c, and log that to stdout. "git add -- --verbose test.c" will add test.c and --verbose, where "--verbose" is the name of a file. This isn't git specific, most CLI tools use "--" to restrict the parsing on arguements that follow.

kelthuzad 4y ago

I found the "Missing Semester" lectures on YouTube to be pretty helpful: Regarding git there is: Lecture 6: Version Control [0] [0] https://youtu.be/2sjqTHE0zok https://youtu.be/2sjqTHE0zok

ArrayBoundCheck 4y ago

I wish they made a breaking change in the next version and make the CLI actually usable. Before you downvote, ask yourself how do you list tags, branches and remote

School-Cotton 4y ago
They shouldn't break the existing `git` command as it is widely used in scripts. But there are projects that try to build better UIs on top of git; the most serious such attempt that I know of is magit.
ajross 4y ago
"git tag", "git branch -a", "git remote -v" You point is what, that these are needlessly asymmetric? It's true. But they're in my head because I do them every day, and it's not like I'm suffering under the burden of remembering a handful of flags. That's a pretty far cry from "not actually usable", so maybe your hyperbole is a little misplaced?
- ArrayBoundCheck 4y ago
  Correct. That was a simple example that's easy to understand Anyone with half a brain can understand that if they can't keep something as simple as printing a list consistent you better believe nothing else will be straightforward. Which is my point. NOTHING is straightforward and I haven't met a single person who likes the CLI if they do anything more complex than a commit, push and pull. I know people who still refuse to use rebase and don't understand bisect or blame. They use a GUI to restore files
PeterWhittaker 4y ago
Branches are easy, what with them being only labels: > git branch --all Tags are different, since they are actual objects in git, but using ls-remote isn’t tough, and one could create an alias.
mmcclimon 4y ago
While acknowledging that git's CLI is often unintuitive: `git tag` lists tags, `git branch` lists branches, and `git remote` lists remotes, so I don't think I understand this particular objection.

probably_wrong 4y ago

> it it’s enough be useful for beginning solo developers, and provides a start from which you can grow. I like this guide a lot as a cheatsheet. However, when it comes to beginners I fear it is one of those things that make sense only when you already know what the guide is talking about. It would take me more than two minutes just to explain a completely new developer what a commit is and why they would want one. And God help us if I throw the output of "diff" at them without warning... The sad truth is, you cannot explain git in two minutes. I nonetheless admire the author for giving the problem a fair fight.

nmz 4y ago

Absolute crap article. You don't learn git in two minutes if you don't talk about rebase and remotes. You want to learn a dvcs in 2 minutes? try fossil.

CRConrad 4y ago
Absolute crap comment. You don't learn anything in two minutes if you don't even read the headline: > Git In Two Minutes (For A Solo Developer)

soupshield 4y ago

What do we call the "--" part in a command like this: git checkout HEAD -- <filename> I find it hard to remember things unless I understand their purpose. It looks like it's specifying an argument but without an argument name (e.g. --verbose), unless it's similar to a pipe | symbol and <filename> is being passed to the checkout command as some special kind of argument?

swordbeta 4y ago
https://unix.stackexchange.com/a/11382 https://unix.stackexchange.com/a/11382
ttymck 4y ago
It is a delimiter indicating the end of options: https://unix.stackexchange.com/questions/11376/what-does-double-dash-mean https://unix.stackexchange.com/questions/11376/what-does-dou...
gizmo686 4y ago
I don't know what it is called, but it forces what comes after to be interpreted as a filepath. This is not git specific, but a common convention for CLI tools. Try running: > touch -- -i foo > rm -- -i foo And compare what happens without the "--".
- soupshield 4y ago
  Thank you for this brilliant explanation (complete with interactive example :) I completely get it now.
- pojzon 4y ago
  Not only a filepath, this means pass anything past “—-“ ‘as is’ as an input and not an option flag. docker run -it nginx —- ls la
  - drdec 4y ago
    Not a file path specifically and not an input exactly but I think the proper word would be an argument.

carom 4y ago

How does this not mention git push? That and pull seem a lot more essential than everything that came after commit.

CRConrad 4y ago
> How does this not mention git push? Because it's about using git as a single-user, single-machine version control tool.

brasetvik 4y ago

It's not a single digit minute read, but to me "Git from the Bottom Up" was what really made me understand git a long time ago. https://jwiegley.github.io/git-from-the-bottom-up/ https://jwiegley.github.io/git-from-the-bottom-up/ git's the kind of tool where understanding how your commands operate on the underlying data structures will probably make it a lot easier to use efficiently. (And they're beautifully simple despite how powerful and flexible they are) As a tool you might be using for hours per week for a few more decades, it's worth the investment going beyond the "in x minutes". I tend to provide both to juniors. Obligatory: https://xkcd.com/1597/ https://xkcd.com/1597/

copperx 4y ago
Is is better than the Git Internals book?

quickthrower2 4y ago

In solo development I still revert rather than reset and don't force push. I see no harm in having history. You may even be glad you have it later on. Revert on the command line is very easy to use, maybe easier than reset as you don't need to think about whether it is hard or soft you want. Once vice I have for solo development that I won't do at work is really crappy commit messages. Like "ditto" for a commit that is similar to the one before or "typo" if I am just correcting a spelling mistake.

stu2b50 4y ago
I think that vice is honestly much better than another common vice: not committing because of commit message paralysis. If you don't commit, git is doing little to help you do anything. Commits, and their messages, can always be redone with an amend, or a rebase.
- quickthrower2 4y ago
  This makes me think that messages should be a separate entity and not part of what computes the hash. So you can retrospectively change a message later on if it needs some more detail.
jonahx 4y ago
> I see no harm in having history. You want meaningful history, not unfiltered history. The harm is that the history is no longer as useful if it's not curated -- whether that's for tracking down the origin of a bug, or just using it to remember what you did a few weeks ago. It's easy to see the flaw in "keep everything" by taking the argument to its logical conclusion, which would be recording the history of every keystroke in your editor. If you have false starts or alternate approaches that you gave up on but think you might still want, by all means save them, just not in "main."
- quickthrower2 4y ago
  You could use branches / tags for this purpose. Reverts are not too bad becuase they are pretty meaningful. If your commits are meaningful then the revert is "reverts: {meaniningful commit message}"

crossroadsguy 4y ago

This reminds me — what was that human readable “man” tool again? I think I had come across a homebrew package back in the day, that let you read command docs in a sane language, but lost track of it.

tux2bsd 4y ago
> man... that let you read command docs in a sane language That would be nice. It is a pity most man pages are elitist and lack good useful examples.
- thijsvandien 4y ago
  My goto for useful examples is tldr: https://github.com/tldr-pages/tldr https://github.com/tldr-pages/tldr.

p4bl0 4y ago

I find it odd to have `git status` shown only at the end and presented as a bonus. That would have been the first command I would speak of after `git init`. I use it so often that I have an alias in my shell for it: `gis`. It shows all the relevant information and generally suggests commands that would perform what you might want to do in the situation you are in (new untracked files, tracked files changes, staged changes that you may want to unstage, merging conflicts, rebase in progress, etc.). It really helps with Git discoverability, which is not negligible when you set yourself to present such a complexe tool in two minutes!

bcoughlan 4y ago

Not as beginnery but I made a similar little cheat sheet showing how to explore the history of a codebase: https://bcoughlan.github.io/posts/git-detective-cheatsheet/ https://bcoughlan.github.io/posts/git-detective-cheatsheet/

d4rkp4ttern 4y ago

We need a copilot for the command line. For the bazillion times I have to look up stack-overflow for doing anything unusual with git, like undoing things etc. And not just git. Maybe some day there will be an oh-my-zsh plugin for copilot.