How to learn Git: a roadmap, interactive tutorials, docs and practice

You learn Git by doing, not by reading. To work confidently on a team, you need about twenty commands and three ideas: a commit is a snapshot of the project, a branch is a pointer to a commit, and a remote repository is just another copy of the history. Below is a stage-by-stage roadmap to learn Git, with exercises, free resources and clear criteria for knowing when you've finished each stage.

The plan is aimed at beginners who can already use a terminal at least at the level of cd and ls. If you can't yet, spend an evening on command-line basics first: learning Git without them is noticeably harder.

Why it pays to learn Git systematically

Plenty of people get by for years with five commands copied from someone else's instructions, then panic at their first conflict or "detached HEAD." The reason is almost always the same: no mental model. They don't understand what a command actually changes in the history and in the files.

Learning Git properly pays off quickly. You stop being afraid to experiment because you know how to roll back; you resolve conflicts calmly; you keep a clean history that reviewers and employers can see. Git comes up in interviews for almost every tech role, from frontend to DevOps and data analysis.

Stage 1. The basics: repository, staging area, commit

The goal of the first stage is to understand the basic loop and Git's three areas: the working directory, the staging area (index) and the repository. Budget 2–4 days at an hour a day.

• Installation and initial setup: git config --global user.name, user.email, main as the default branch.
• Creating a repository: git init.
• The git status → git add → git commit loop; partial staging with git add -p.
• Viewing history: git log --oneline, git diff, git diff --staged, git show.
• The .gitignore file: what shouldn't go into the repository.

Exercise. Create a repository for your notes or a small script. Make 15–20 commits, each one a single logical change with a clear message. After every command, run git status and explain to yourself what changed.

You're done with this stage when you can say, without looking it up, how git diff output differs from git diff --staged, and you can commit only some of your modified files.

Stage 2. Branching and merging

Branches are the heart of Git and the main source of fear for beginners. The point here isn't memorizing commands but learning to picture the commit graph. Give this stage about a week.

• Creating and switching: git branch, git switch, git switch -c.
• What HEAD is, and the detached HEAD state.
• Merging: git merge, fast-forward vs. merge commit, the --no-ff flag.
• Conflicts: the <<<<<<< and >>>>>>> markers, git merge --abort.
• Visualization: git log --oneline --graph --all.

Exercise. Create two branches from main and change the same line of the same file in each. Merge them one after the other, get a conflict and resolve it. Repeat until the process feels boring.

At this stage an interactive Git tutorial helps most — more on that below. It shows the graph after every command and builds intuition fast.

Stage 3. Remote repositories and teamwork

The goal is to learn to work with a server the way teams do. You'll need an account on GitHub, GitLab or any other Git host. Allow about a week.

• Connecting and cloning: git remote add, git clone, SSH key authentication.
• Syncing: git push, git push -u, git fetch, git pull and the differences between them.
• Remote-tracking branches such as origin/main.
• Forks, feature branches and pull requests with code review.
• Team workflows: GitHub Flow, Git Flow, trunk-based development.

Exercise. Work with one repository from two "computers": clone it into two different folders. Commit in one, push, pull in the other. Create a situation where your push is rejected because the server moved ahead, and figure out why.

git clone git@github.com:you/sandbox.git copy-a
git clone git@github.com:you/sandbox.git copy-b
cd copy-a && echo "from A" >> notes.txt && git commit -am "Change from A" && git push
cd ../copy-b && echo "from B" >> notes.txt && git commit -am "Change from B"
git push          # rejected: the server moved ahead
git pull          # get A's change, resolve the conflict in notes.txt
git push

This short scenario simulates the most common situation on a team. Go through the output of each command: why the push was rejected, what appeared in origin/main after the fetch, where the merge commit came from. Then repeat the same thing with git pull --rebase and compare the graphs with git log --oneline --graph --all.

Even better, find a partner and build a small project together through pull requests: you'll get a real feel for reviews, conflicts and branch conventions.

Stage 4. Undoing mistakes

This stage turns Git from a source of anxiety into a safety net. 3–5 days.

• git restore and git restore --staged — undoing changes in files and in the staging area.
• git commit --amend — fixing the last commit.
• git reset in --soft, --mixed and --hard modes.
• git revert — safely undoing a published commit.
• git reflog — recovering "lost" commits.

Exercise. Make a few commits, run git reset --hard HEAD~3 and recover them via the reflog. Revert a commit on a "shared" branch and see what that looks like in the history.

Stage 5. Advanced tools

You pick these up as you need them, but it's worth knowing they exist up front.

Interactive Git tutorials: where to practice

A practice tool is great because it gives you a safe sandbox and shows results immediately. A few free options:

• Learn Git Branching (learngitbranching.js.org) — the best interactive tutorial for branches. Levels with challenges, an animated commit graph, available in many languages. It covers commit, branch, merge, rebase, cherry-pick, interactive rebase and working with remotes.
• Oh My Git! — a free, open-source game where Git commands are represented as cards, with real Git running under the hood.
• Your own sandbox repository — the most underrated practice tool. Create a git-sandbox folder and break everything in it: there's nothing to lose.

Interactive tutorials are excellent for understanding the graph, but they don't replace a real project: there are no real files, no editor, no code conflicts and no IDE. Use them as a supplement.

Git documentation and books

The official Git documentation lives at git-scm.com. The Pro Git book by Scott Chacon and Ben Straub is available there for free, including translations into many languages. It's the best Git book out there: the first three chapters (basics, branching) are a must, and the "Git Internals" chapter is for anyone who wants to fully understand the data model.

Built-in help is always at hand: git help <command> opens the full manual, and git <command> -h shows a short list of flags. The Git documentation is dry but precise; get into the habit of checking it rather than trusting the first search result.

git help rebase        # full manual
git switch -h          # quick flag reference
git help -g            # list of concept guides (gitworkflows, gittutorial…)

The gittutorial and giteveryday guides are also useful — they ship with Git and open via git help.

Self-study or a course

Learning Git on your own is entirely doable: a book, an interactive tutorial and a sandbox give you everything you need. The challenge is elsewhere: without structure it's easy to get stuck in theory or, conversely, to pick up commands without understanding them, and without feedback nobody will tell you your history is a mess.

A Git course helps if you want to cover the ground quickly and in order: from your first commit to a pull request in a real repository, with exercises at every step. When choosing a course, look not at its length but at how much of it is practice: are there exercises on conflicts, undoing mistakes, teamwork, and a final project?

How long does it take to learn Git?

These numbers are rough: consistency is what counts. An hour every day beats a weekend marathon once a month.

Common mistakes when learning Git

• Learning only through a GUI. Graphical clients are convenient but hide the model. Understand the command line first, then pick whatever tool you like.
• Memorizing flags. Remember the ideas; the flags are always in -h.
• Being afraid to break things. Until you've run reset --hard and recovered, you don't really know Git has your back.
• Skipping remote repositories. Local Git without push, pull and pull requests is only half the skill.
• "fix" and "update" commits. It's easier to build the habit of meaningful commit messages from day one.

A final project to lock it in

The best test is a simulation of team development. Create a repository, protect its main branch from direct pushes, invite a partner or work from two accounts. Every task gets its own feature branch and a reviewed pull request; cause a conflict at least once, roll back a bad commit with revert at least once, and tag a release.

After a project like this, Git stops being a set of magic spells. You can see the graph, you understand what commands do, and you're ready for interview questions.

Summary

The effective way to learn Git is in order: the basic loop, branches, working with a server, undoing mistakes, then advanced tools. An interactive tutorial helps you see the graph, Pro Git and the official docs give you depth, and your own sandbox plus a team project turn knowledge into skill. That's exactly the path — from git init to a pull request in a final project — that the Git course on Skillaria follows.