There are many ways to support us; in exchange, you'll get this material in a proper format:
- ❤️ shop.ditectrev.com, in EPUB or PDF formats,
▶️ Udemy, in an interactive video course format,- 🆓 Shorter, but free, part of our Udemy course is available on YouTube,
- 🖨️ Amazon, printable physical book in paperback or hardcover (Kindle available, too),
- 📚 Google Play Books, in PDF format,
- 🛍️ Etsy, in PDF format,
- 🛒 eBay, in PDF format,
- 🔄 Patreon subscription allows you to get access to all of the materials in EPUB and PDF formats. You can also buy separate items on Patreon, but the subscription technically allows us to include all updates for EPUB and PDF formats. Hence, you get EPUB and PDF updates when you subscribe to Patreon.
💰 If you work for a company, you could probably easily claim this expense while learning this topic. For us, it's about being in the game or not.
⭐ Good ratings & reviews help us to survive. Please don't forget to leave a nice one when you purchase an item.
✨ This book & course is unlike any Distributed Version Control (Git) book & course you will find online.
✋ Join a live online community and a book & course taught by industry experts and learn about Git. We aim to build an ecosystem of Information Technology (IT) certifications and online courses in cooperation with the technology industry. We believe it will give our students 100% confidence in the pacing market in an open-source environment. We are just at the beginning of our way, so it's even better for you to join now!
- Always happy to answer your questions 😊
- Unhappy? Please raise a refund; we'll always accept it 💸
- Learn about topics, such as 😱
- Introduction to Git:
- What is Git?;
- Git vs GitHub vs Other Hosts;
- History and Evolution of Git;
- Core Principles of Git:
- Snapshots, Not File Diffs;
- The Three Areas: Working Tree, Staging Area, and Repository;
- The Browser Lab:
- github.dev: VS Code in the Browser;
- Learn Git Branching as a Visual Sandbox;
- Repositories, Files, and Commits:
- Creating a Repository on GitHub;
- Making Your First Commit in the GitHub Web Editor;
- Branches and Merging:
- Merge, Squash and Merge, and Rebase and Merge;
- Pull Requests, Forks, and Code Review;
- Conflicts and History Repair in the Browser;
- Releases, Ignore Files, and Repository Hygiene;
- Collaboration, Access, and Other Git Hosts;
- Common Challenges and Debugging Tips;
- Additional Resources and Reading Materials:
- Recommended Tools and Software for Git;
- Other Git Hosts;
- Git on Your Own Machine;
- Git Aliases;
- Appendix A: Rebase and Rewriting History:
- git push --force;
- Appendix B: Cherry-pick, Reset, Reflog, and Bisect;
- Appendix C: Git Internals;
- Appendix D: Submodules, Subtrees, and Monorepos;
- Appendix E: Git LFS, Sparse Checkout, and Large Repos;
- Appendix F: Signing, SSH, Hooks, and CI Checks;
- Appendix G: Restore, Stash, and Clean Working Trees;
- Much More!
- Introduction to Git:
- Real Life examples ✅
- The book & course explains the topic fully in-depth 🔬
v1.0.0: October 26, 2026.
- Launch of the book.
v1.1.0: December X, 2026.
- Post-recording improvements.
v1.1.0: December X, 2026.
- Launch of the course.
We are so thankful for every contribution, which makes sure we can deliver top-notch content. Whenever you find a missing resource, broken link in a Table of Contents, the wrong answer, please submit an issue. Even better would be a Pull Request (PR).
- 👨🎓 Enthusiasts of practical education;
- 👨🎓 Everyone who has heard about Git and would like to know more;
- 👨🎓 Professionalists daily working with technology who want to have a basic grasp of Distributed Version Control without burnout;
- 👨🎓 Sceptical Developers about a book & course solely focused on Git;
- 👨🎓 Self-paced Learners for whom expensive Bootcamps are unaffordable;
- 👨🎓 Students interested in Software Development and Version Control;
- 👨🎓 Students willing to start a career in Software Development;
- 👨🎓 Specialists willing to know A to Z about Git;
- 🤩 Excitement to learn!
- 0️⃣ Prior knowledge is required;
- ✅ You can learn Distributed Version Control (Git) solely based on our book & course.
- Introduction to Git
- History and Evolution of Git
- Core Principles of Git
- The Browser Lab
- Repositories, Files, and Commits
- Branches and Merging
- Pull Requests, Forks, and Code Review
- What a Pull Request Is
- Opening a Pull Request from a Branch
- Reviewers, Comments, and Suggested Changes
- Draft Pull Requests
- Checks, Statuses, and Required Reviews
- Merging and Closing Pull Requests
- Fork vs Clone as a Mental Model
- Contributing to Someone Else's Repository
- Syncing a Fork in the GitHub Interface
- Summary: Pull Requests, Forks, and Code Review
- Conflicts and History Repair in the Browser
- Releases, Ignore Files, and Repository Hygiene
- Collaboration, Access, and Other Git Hosts
- Common Challenges and Debugging Tips
- Additional Resources and Reading Materials
- Appendix A: Rebase and Rewriting History
- Appendix B: Cherry-pick, Reset, Reflog, and Bisect
- Appendix C: Git Internals
- Appendix D: Submodules, Subtrees, and Monorepos
- Appendix E: Git LFS, Sparse Checkout, and Large Repos
- Appendix F: Signing, SSH, Hooks, and CI Checks
- Appendix G: Restore, Stash, and Clean Working Trees
Git is how you record project history, work in parallel, and review changes without overwriting each other. This chapter defines the job, names the problem version control solves, separates Git from GitHub and other hosts, and shows how we practice in the browser so you do not need Git installed on your machine.
What is Git?
Git is a distributed version control system (DVCS). A version control system tracks changes to files over time so you can answer four working questions: what changed, who changed it, when, and—if the commit message is useful—why. Distributed means a complete copy of a repository can hold the full history, not only a copy that lives on one central server. We will unpack that design in Core Principles of Git. For this chapter, treat Git as the engine that stores snapshots of a project.
The official home is git-scm.com. The Git project describes Git as fast, widely used, and released as free and open source software. The Git documentation is the canonical reference for the tool itself. GitHub Docs: About Git is how the same engine shows up when you work on a host.
Git is software, not a website. You can run it from a command line, from a desktop app, or through a host's web UI. This book uses the web UI first. The same snapshots, commits, and branches are Git objects either way. The buttons you click on GitHub still create Git history.
A few words we will keep using:
- Repository (repo): the project plus its history. On GitHub, a repository is the page you open. Under the hood it is a Git database of snapshots.
- Commit: a saved snapshot with a message, an author, and a parent (or parents). You will make your first commit in the GitHub web editor in Repositories, Files, and Commits.
- Branch: a movable name for a line of work. Branches and Merging is the chapter that makes this concrete.
- Host: a service that stores Git repositories and adds a web UI, permissions, and review. Our host is GitHub.
What Git is not:
- Not GitHub. GitHub hosts Git repositories and adds collaboration on top. You can use Git without GitHub. You cannot use GitHub as version control without Git running for you.
- Not a backup product by itself. History helps you recover old versions of tracked files. It does not replace a backup of secrets, untracked files, or the host account.
- Not a deploy button. Some hosts wire Git to CI and hosting. This book stays on version control and collaboration. Host CI as a merge gate is Appendix F, not the main path.
Git started as the tool that tracks the Linux kernel. That origin story belongs in History and Evolution of Git. You do not need that history to start clicking in the browser. You do need the distinction we make next: version control is the job, Git is the tool we use for it, and GitHub is where we practice.
Without version control, a project is a folder that only the latest save can describe. People copy files, email attachments, and rename drafts until nobody can answer "which copy is true?" Version control replaces that mess with a shared history you can inspect, branch, and review.
The daily problems version control is for:
- Overwriting
- Two people edit the same file. The last save wins. The other person's work disappears.
- Version control records both lines of work so you can combine them, or at least see the conflict instead of silently losing a save.
- No latest copy
- Folders named
final,final-v2, andfinal-FINALare not history. They are guesses. - A repository has a default branch that points at the current agreed snapshot, plus older commits you can still open.
- Folders named
- No audit trail
- Fear of changing things
- If the only copy is the live file, every edit feels risky.
- Commits let you take a snapshot before you try something. Branches let you try it without touching the default branch. Revert on GitHub (Conflicts and History Repair in the Browser) is how you undo a published commit without pretending it never happened.
- Review is guesswork
What you get once history exists:
- Snapshots, not a pile of copies. Git records the state of tracked files at each commit. Core Principles of Git explains why those snapshots are not "a list of diffs" even though GitHub shows you a diff view.
- Parallel work. Branches isolate a feature, a fix, or an experiment. You merge when the work is ready. That is the normal GitHub flow we will click through later.
- Attribution. Commits carry an author. Review comments on GitHub sit on those commits.
- Recovery with a record. You can go back to an older snapshot. You can also see the commits you are leaving behind, which a restored zip file never shows.
Version control is the job. Git is one tool that does that job. Older centralized systems such as Apache Subversion and other distributed tools such as Mercurial solved overlapping problems with different designs. We are not running those tools. History and Evolution of Git is where we place Git on that timeline. The working rule for this book: if you need history, review, and parallel work, you need a version control system. We teach that system as Git, practiced on GitHub.
A shared drive, a chat attachment, or a "please use this file" email is not version control. Those channels move bytes. They do not give you a graph of commits you can branch, review, and revert.
Three layers show up in every later chapter. Mixing them up is the most common beginner trap, so we separate them now.
1. Git — the version control system
- Stores repositories, commits, branches, and tags.
- Official site: git-scm.com. Docs: Git documentation.
- Does not require GitHub. A repository on a USB drive, a company server, or another host is still Git if it uses that format.
2. A Git host — the service that stores repositories and adds a web UI
- GitHub is our host. It stores Git repositories and adds issues, pull requests, permissions, and the pages we will click. Product: github.com. Docs: GitHub Docs. Free accounts are enough for the main path; plans are on GitHub Pricing.
- The host runs Git for you when you edit in the browser. You still produce Git commits. You are not using GitHub instead of Git. You are using Git through GitHub.
3. Collaboration features on top of Git
- Pull requests, reviews, checks, and branch rules are host features. They describe Git history; they are not extra Git object types.
- GitHub flow is the usual loop we will practice: branch, commit, open a pull request, review, merge. That loop is a GitHub workflow over Git branches.
Other hosts (mention only — not a lab):
The same Git repositories can live on more than one product. These four show up often at work. They speak Git. Their web UIs look similar to GitHub (repositories, merge requests or pull requests, permissions). We name them so you can recognize them. We do not open a second classroom on them.
- GitLab — gitlab.com (self-managed GitLab exists too). Merge requests are the review object that maps to GitHub pull requests.
- Bitbucket — bitbucket.org. Pull requests over Git repositories.
- Codeberg — codeberg.org. A public Git host with a forge-style web UI.
- Azure Repos — Azure Repos in Azure DevOps. Git repos plus a web editor and pull requests.
Collaboration, Access, and Other Git Hosts repeats this as a one-line tour. Additional Resources and Reading Materials has Other Git Hosts for pointers. Neither place is a second lab. If your job uses GitLab or Bitbucket, the Git model you learn here still applies. The button labels will differ. The commits will not.
Working rule: when we say Git, we mean the version control system. When we say GitHub, we mean the host where you click. When we say another host, we mean "same Git, similar web UI, not our lab."
Why This Book Does Not Require Git Installed Locally
Most Git books start by installing a binary, fixing PATH, and setting SSH keys. That is a real skill. It is also the step that stops people before they have seen a commit. We do not start there.
Why the main path stays in the browser:
- The host already runs Git. Creating a file on GitHub and clicking Commit changes writes a Git commit. You do not need a local
gitprogram for that. The GitHub web file editor is enough for one-file commits. - github.dev is a full editor without a laptop clone. It is Visual Studio Code for the Web. Official docs: Using VS Code for the Web from GitHub and VS Code for the Web. You must be signed in to GitHub. The editor talks to the repository from the browser instead of copying it onto your disk.
- Learn Git Branching is a visual sandbox. You will use it when we need you to see commits and branches. It runs in the browser. It does not install Git and it does not touch your GitHub account.
- GitHub Codespaces is optional. A codespace is a cloud machine with a terminal and Git already there. We name it so GitHub's "Open in codespace" button is not a mystery. Docs: GitHub Codespaces. It is never required. Skip it unless a later chapter marks it optional.
- Local install is a later, skippable section. Additional Resources and Reading Materials has Git on Your Own Machine: when the command line becomes worth it, how to install Git, and how web buttons map to commands. The course can skip that entire section. You can finish the main chapters without it.
What you avoid by not installing yet:
- Operating-system differences in how you install a command-line tool.
- Credential helpers, SSH keys, and personal access tokens before you have made a commit.
- A local clone that drifts from GitHub while you are still learning what a commit is.
What the browser cannot do (so we do not pretend):
- The basic GitHub web editor has no force-push button. Force-push (
git push --force,--force-with-lease) is Appendix A, not the normal workflow. - GitHub has no
git restoreand no stash. Discarding uncommitted edits in the web editor is the browser analog; restore, stash, and clean are Appendix G. - Git aliases (
git config alias.…) have no GitHub web UI. They live under Additional Resources.
You are not missing "real Git" by working in the browser. You are using Git through the host. When a later chapter needs a terminal, we will say so and point at Learn Git Branching, an optional GitHub Codespace, or Git on Your Own Machine. Until then, do not install anything.
This section is a map, not a lab. You will create a GitHub account in The Browser Lab. You do not need to click through a repository yet.
What you need for the main path:
- A web browser.
- Starting in The Browser Lab: a free GitHub account (Creating an account on GitHub).
- No local Git binary. No paid GitHub plan. No GitLab, Bitbucket, Codeberg, or Azure Repos account.
The three practice surfaces we will keep naming:
- Primary function: store the repository and click the real workflow: files, commits, branches, pull requests, reviews, conflict editor, releases.
- When we send you here: anything that must land in a real repository. Creating a repo, editing a file, opening a pull request, merging, reverting.
- How you open it: github.com. Docs start at GitHub Docs.
- One-file edits: the web file editor on GitHub itself.
- Primary function: Visual Studio Code in the browser for multi-file edits, search, and a Source Control view, still without installing Git.
- When we send you here: more than one file, or when the GitHub file editor is too small for the change.
- How you open it: on a GitHub repository, press
.(same tab) or>(new tab), or changegithub.comtogithub.devin the URL. You must be signed in. Docs: Using VS Code for the Web from GitHub, VS Code for the Web. - What it is not: it is not GitHub Codespaces. No cloud VM is required. Extensions that run here without local Git belong in The Browser Lab and in Additional Resources; we will not install them in this chapter.
- Primary function: a visual sandbox. You type commands that look like the Git command line, and the commit graph updates on screen.
- When we send you here: when you need to see branches, merges, and later rebase, without touching a GitHub repository.
- How you open it: learngitbranching.js.org. Source: pcottle/learnGitBranching.
- What it is not: those commands do not install Git on your computer and they do not push to GitHub. The sandbox is a toy repository for your eyes. When we want a real commit, we go back to GitHub.
Optional, never required: GitHub Codespaces
- A codespace is a cloud machine in the browser with a terminal and Git already installed. Docs: GitHub Codespaces.
- Use it only when a later chapter says you need a real terminal and you do not want Git on Your Own Machine. Skip it on the main path.
Working loop we will repeat:
- Read the chapter (this book is the lesson).
- When the text says to record history in a real project, use GitHub — web editor for one file, github.dev for many files.
- When the text says to see the graph, use Learn Git Branching.
- Do not install local Git unless you choose Additional Resources. Do not open GitLab, Bitbucket, Codeberg, or Azure Repos as a classroom.
The next two chapters stay on reading: History and Evolution of Git, then Core Principles of Git. The first click-through lab is The Browser Lab.
We covered what Git is (a distributed version control system, not a website), what problem version control solves (history, parallel work, review, recovery), and how Git differs from GitHub and from other hosts (GitLab, Bitbucket, Codeberg, Azure Repos — same Git, similar web UI, not our lab). You do not need Git installed locally: we practice on GitHub, github.dev, and Learn Git Branching, with GitHub Codespaces optional. You now have the vocabulary we will use for the rest of the book. Next, we will walk through History and Evolution of Git.

