Source Control Learning Lab

Learn Git from commits to the object model, with both workflow and internals.

A Git documentation site for collaborative developers, covering quick start, common workflows, recovery strategies, and hands-on guidance for rebase, merge, and reflog.

Core Modules

5From workflow to recovery
Doc Topics16
Bilingual Pages4

Recommended path

Quick Start → fetch/pull → rebase → reflog

Quick Start

Get Started Fast

Build intuition for branches, commits, and synchronization through a few low-risk commands.

01 / setup

Initialize a repository

Understand git init, git clone, identity config, and the default branch.

git clone repo-url
02 / stage

Stage and commit

Learn the three-layer model of working tree, staging area, and history.

git add . && git commit
03 / sync

Sync with remote

Master how fetch, pull, and push work with local branches.

git fetch origin

Best Practices

Best Practices

Reduce history noise and conflict cost.

Keep commits small and intentional

One clear intent per commit makes review, rollback, and cherry-pick easier.

Fetch first, then choose merge or rebase

Fetching before you decide gives you more control than a default pull.

Check reflog before risky operations

Before reset, rebase, or force push, confirm your recovery path.

Git Internals

Under the Hood

Map command behavior back to the object model.

The object database

See how blob, tree, and commit objects form a trackable history graph.

References and HEAD

Branches, tags, and remote-tracking refs all point to commits.

Recoverability

Reflog and garbage collection determine when lost objects can still be restored.

Reference

Command Learning Path

Organize high-frequency commands into a progressive path.

01

clone

Create a local copy of a repository.

02

add

Move changes into the staging area.

03

commit

Create a new immutable commit.

04

rebase

Rewrite commit bases and clean history.

FAQ

Common Questions

A practical FAQ built from the Git official docs and the Pro Git book, focused on the questions people hit most often.

`git pull` first runs fetch, then integrates the upstream branch into your current branch. The official documentation describes several integration modes, including `--ff-only`, `--rebase`, `--no-rebase`, and `--squash`, so the outcome depends on your flags and config such as `pull.rebase` and `pull.ff`. If you want fewer surprises, fetch first and choose the integration strategy explicitly.

The official `git reset` manual separates them cleanly: `--soft` moves HEAD only, `--mixed` resets the index but keeps working tree changes, and `--hard` resets HEAD, the index, and the working tree together. In practice, `--hard` is the one to treat as destructive because it overwrites your current file state.

Often yes. The official `git reset` documentation explicitly points to `ORIG_HEAD` and related recovery flows after reset, merge, and pull. As long as the underlying objects have not been cleaned up yet, reflog is usually the first place to look before you decide whether to create a new branch or move a ref back.

Git Docs

The content library now renders directly from MDX.

Browse the docs library, or keep expanding the same content pipeline with more Git topics.

Open docs library