How to learn Git
This path assumes you can use a terminal and edit text files. It gets you to a point where you can recover from a bad rebase, explain a merge conflict to a colleague, and read a repository's history as a graph. No prior version control experience needed.
Hours
40-60 hours
Calendar
about 10 weeks at 4-6 hours a week
Stages
5
Start from
You need basic comfort with a terminal: moving between directories, listing files, running a command with flags. You do not need to know any other version control system, and you do not need to memorise command flags before you understand the underlying model.
Why the usual order fails
Most Git tutorials start with add, commit, push, and pull. That order teaches you to operate a remote backup service, not to understand what Git is. Git is a directed acyclic graph of commits, where branches are just movable pointers and merges are new commits with two parents. If you learn the commands before the graph, every merge conflict looks like a mysterious failure of the tool rather than a predictable consequence of two histories diverging. The common order fails because it hides the model behind porcelain commands that were designed to be convenient, not to be understood.
This path starts with the object database and the commit graph. In week one you create commits by writing tree and blob objects by hand, then you inspect them with cat-file and ls-tree. Most plans have you pushing to GitHub in the first hour, which teaches you that Git is a cloud service. Here you do not touch a remote until week four. By then you can draw the graph of any repository you are working in, and a merge conflict is just two nodes in the graph that both changed the same line. That is the difference: you learn the graph first, and the commands become names for operations on the graph.
The path, in the order it has to be walked.
Each stage assumes the one above it and nothing below it. The check at the foot of each is the point — you are meant to fail it, go back, and try again before moving on.
The object database
weeks 1-2Git stores everything as objects: blobs, trees, commits, and annotated tags. You create these objects by hand and inspect them with plumbing commands. This stage sits first because every later concept—branches, merges, rebases—is a manipulation of these objects.
- blob, tree, commit, and tag objects
- SHA-1 hashing and content addressing
- git hash-object and git cat-file
- git mktree and git commit-tree
- the .git directory layout
- HEAD as a pointer to a commit
- parent pointers in commit objects
You can now: Create a commit without using git commit, then inspect its raw contents and draw the object graph on paper.
Branches and the index
weeks 3-4Branches are just files containing a commit hash. The index is a staging area between your working tree and the next commit. Understanding these two mechanisms makes add, commit, checkout, and reset predictable instead of magical.
- branch as a pointer to a commit
- the index as a proposed next commit
- git add and git reset as index operations
- detached HEAD state
- git checkout and git switch
- git stash as a temporary commit
- reflog as a safety net
You can now: Explain, with a diagram, what happens to HEAD, the index, and the working tree when you run git reset --hard, git reset --soft, and git reset --mixed.
Merging and conflicts
weeks 5-6A merge is a commit with two parents. Conflicts happen when the same lines changed in both histories. This stage sits after branches because you need to see the graph before you can understand why a merge produces a particular result.
- fast-forward merges vs true merges
- merge commits and their parents
- conflict markers and how to read them
- git mergetool and manual conflict resolution
- octopus merges
- git rerere for repeated conflicts
- merge strategies: recursive, ours, theirs
You can now: Create a conflict between two branches, resolve it by editing the file, and explain why the conflict occurred in terms of the commit graph.
Remotes and collaboration
weeks 7-8Remotes are just other copies of the repository. Fetch, push, and pull are operations that move commits and update remote-tracking branches. This stage comes after merging because collaboration is mostly merging with extra steps.
- remote-tracking branches
- git fetch vs git pull
- git push and fast-forward rules
- force push and when it is safe
- pull requests as merge requests
- forking vs branching workflows
- git remote add and multiple remotes
You can now: Set up two local repositories, push and fetch between them, and explain what origin/main means after a fetch.
Rewriting history
weeks 9-10Rebase, cherry-pick, and commit --amend create new commits rather than editing old ones. This stage sits near the end because rewriting history is dangerous only when you do not understand that it creates new objects and invalidates old hashes.
- git rebase and interactive rebase
- git cherry-pick
- git commit --amend
- squashing and reordering commits
- git filter-branch and git filter-repo
- recovering from a bad rebase with reflog
- the golden rule of rewriting public history
You can now: Take a branch with five messy commits, rebase it interactively to squash and reorder them, and recover from a deliberately broken rebase using the reflog.
The hours are fixed. The calendar is yours.
The same path at three speeds, and what actually goes wrong at each.
3 hours a week
You will finish in about 15-20 weeks. The main risk is forgetting the object model between sessions, because the early stages build on each other. You will need to re-read your notes each week, and merge conflicts will feel harder because you have not seen one for a fortnight.
8 hours a week
You will finish in about 6-8 weeks. This is the sweet spot for Git: enough time to do the exercises properly, but not so much that you skip the hand-drawing of graphs. You can hold the whole model in your head between sessions.
20 hours a week
You will finish in about 2-3 weeks, but you will not retain it as well. The object database and rebase stages need sleep between sessions to consolidate. At this pace you will be able to do the exercises, but you will forget the plumbing commands within a month.
Four ways people lose a year on this.
Each of these is appealing for a real reason, which is why they are common. What they cost is the part nobody mentions.
Learning commands before the object model
People memorise git add, git commit, git push as a sequence of incantations. It is appealing because you can make a repository work in ten minutes. The cost is that every unexpected situation—a detached HEAD, a failed push, a weird merge—becomes a crisis instead of a diagnosable state of the graph.
Using a GUI before understanding the graph
Git GUIs show you a pretty picture of branches and commits, but they hide the object database and the index. It is appealing because you can see the graph without drawing it yourself. The cost is that you never learn what the graph actually is, so when the GUI shows something confusing you have no mental model to fall back on.
Treating merge conflicts as failures
People see conflict markers and think they have broken something. It is appealing to avoid conflicts by never branching or by pulling constantly. The cost is that you never learn to read a conflict as a specific, predictable situation: two commits changed the same lines. Avoiding conflicts means avoiding the main skill Git exists to teach.
Force pushing to fix a mistake
When a push is rejected, people run git push --force to make the remote match their local branch. It is appealing because it makes the error go away immediately. The cost is that you have rewritten history that other people may have based work on, and you have destroyed the evidence of what actually happened. The reflog can save you locally, but not on the remote.
How to know it worked.
Not a syllabus you tick off — six things to attempt. If one of them is still hard, the stage it belongs to is the one to go back to.
- Create a commit using only git hash-object, git mktree, and git commit-tree.
- Draw the commit graph of a repository with two branches and one merge.
- Explain what git reset --soft does to HEAD, the index, and the working tree.
- Resolve a merge conflict and explain which two commits caused it.
- Rebase a branch interactively and squash three commits into one.
- Recover a deleted branch using only the reflog.
Questions about learning Git.
The five we hear most. The intro film answers most of them in a minute and a half.
how long does it take to learn git
For genuine working competence—not just add, commit, push—expect 40-60 hours of focused practice. That means you can read a repository's history, resolve conflicts without panic, and recover from a bad rebase. You can learn the basic commands in an afternoon, but that is not the same as understanding the graph.
is git hard to learn
Git is hard to learn if you start with the commands, because they hide the underlying model. If you start with the object database and the commit graph, the commands become names for operations on that graph. The difficulty is not the tool; it is the order in which most tutorials teach it.
do i need to know the command line to use git
You need basic terminal comfort: moving between directories, listing files, running a command with flags. You do not need to be a shell expert. The command line is where Git's model is most visible, and the plumbing commands that teach you the graph are only available there.
is git the same as github
No. Git is a version control system that runs on your machine and stores a graph of commits. GitHub is a hosting service that stores copies of Git repositories and adds a web interface, pull requests, and issue tracking. You can use Git fully without GitHub, and you can use GitHub without understanding Git—but that is a mistake.
can i learn git without learning the command line
You can learn to operate a Git GUI without the command line, but you will not learn Git. The GUI hides the object database, the index, and the reflog—the very things that make Git predictable. If you only ever use a GUI, you will be dependent on it and unable to diagnose problems when it shows you something unexpected.
A path is not a course.
This is the shape of Git, not the teaching of it. Hand the same path to BiliMind and it writes the lessons onto it — in the form each one calls for, with practice that gets marked and a schedule that bends when your week does. Mapping a course is free and unlimited.
This roadmap was drafted on 18 September 2026 by the same engine that builds BiliMind courses, and reviewed before publishing. Hours are honest estimates for working competence, not for a demo — treat them as a starting point and adjust them against your own first fortnight.