Ask HN: How long did it take you to learn Git?
14 comments
Couple of days to get basic commands to muscle memory and to get intuition how git works internally.
Save yourself from confusion and waste of time, and read/skim through the Pro Git book. It has very good diagrams explaining the workings of git. As of 2025, the book is a bit dated for the very latest (unnecessary?) commands of git, but the basics are still the same.
That said, git is the de facto version control tool in the industry, but I prefer Fossil for my personal projects. Nothing beats the timeline view and other simple tools and easy customizability in Fossil.
Save yourself from confusion and waste of time, and read/skim through the Pro Git book. It has very good diagrams explaining the workings of git. As of 2025, the book is a bit dated for the very latest (unnecessary?) commands of git, but the basics are still the same.
That said, git is the de facto version control tool in the industry, but I prefer Fossil for my personal projects. Nothing beats the timeline view and other simple tools and easy customizability in Fossil.
Define “learn git”? For the few commands I actually uses, I don’t remember it being any more than a day. I don’t see a reason to become an expert and things I might only use once every 5 years, if that.
Even Linus Torvalds only really uses a few commands.
> Torvalds described himself as a casual user of Git who mainly uses just five commands: git merge, git blame, git log, git commit and git pull – though he adds later in the interview that he also uses git status “fairly regularly.”
Even Linus Torvalds only really uses a few commands.
> Torvalds described himself as a casual user of Git who mainly uses just five commands: git merge, git blame, git log, git commit and git pull – though he adds later in the interview that he also uses git status “fairly regularly.”
I was used to subversion so I found a cheat-sheet for git for subversion users and that was mostly good enough for my use cases. Over time I learned more out of need and curiosity. It was not a one and done but the basics were a few minutes.
once you understand git's data model (objects, refs, log + reflog) -- it becomes very intuitive.
git stores a snapshot of every commit along with the history (the DAG / log) of where that snapshot came from.
Merges are just tree traversals from one branch to another.
Once you understand the data model, the clumsy commands become a bit more intuitive.
Get really confident with stash, reset, reflog & rebase . Those commands let you revert and reassemble the log easily.
nuking .git and starting fresh is why people struggle with git. All of the power is in the reflog and the ability to manipulate & restore a healthy state at any time.
git stores a snapshot of every commit along with the history (the DAG / log) of where that snapshot came from.
Merges are just tree traversals from one branch to another.
Once you understand the data model, the clumsy commands become a bit more intuitive.
Get really confident with stash, reset, reflog & rebase . Those commands let you revert and reassemble the log easily.
nuking .git and starting fresh is why people struggle with git. All of the power is in the reflog and the ability to manipulate & restore a healthy state at any time.
Depends what you mean by learning Git. To use it on a basic level, a few hours maybe. But I'm very, very far from an expert here, and know maybe 1% of the commands possible there.
I've been using Git for years and haven't learned even half of it. I use a small subset that I understand, and the rest I learn about (or refresh my knowledge) when I need it.
You never do. You just learn what you need for your daily needs.
I mostly learned the subset that I need for my everyday work. I'm sceptical about whether I'm smart enough to learn the rest. Frankly the complexity and unfriendliness of the tooling scares me a little, and I've been doing this software dev thing for over thirty years.
SCCS, RCS, SourceSafe, Vault, TFS, git. Use the gui if you can.
SCCS, RCS, SourceSafe, Vault, TFS, git. Use the gui if you can.
I thought it was a very sophisticated system of file version management that very carefully measured deltas between versions of files, and stored only those deltas. If you believe this, you'll experience nothing but grief with Git, because that's not what it is.
It actually stores everything you tell it to, and can optionally compress it down to deltas. The storage at the root is all content based, instead of file name based, so if you have 5000 different names for the exact same 1 megabyte of stuff, you'll only store it once, along with all the names (and other metadata it uses internally).