Source Control Learning Lab
Master Git. Build Better History.
A Git documentation site for collaborative developers, covering quick start, common workflows, recovery strategies, and hands-on guidance for rebase, merge, and reflog.
Commands · Workflows · InternalsFigures + Practice + RecoveryBilingual learning system
Quick Start
Get Started Fast
Build intuition for branches, commits, and synchronization through a few low-risk commands.
Initialize a repository
Understand git init, git clone, identity config, and the default branch.
git clone repo-urlStage and commit
Learn the three-layer model of working tree, staging area, and history.
git add . && git commitSync with remote
Master how fetch, pull, and push work with local branches.
git fetch originStart Here
Choose How You Want to Enter
Some readers arrive with a goal, others with a concrete problem. This keeps both entry modes in one tighter navigation surface.
By Goal
If you want to follow a learning track, start from the job you need to accomplish.
Changelog
Latest Updates
Start with the most recently added or expanded teaching entries to catch up quickly.
Workflows
Gitflow Workflow
Use Atlassian's Gitflow explanation to clarify the roles of main, develop, feature, release, and hotfix branches, plus where Gitflow still fits today.
WorkflowsUsing git worktree as the default mode for AI coding agents
Turn git worktree into the default parallel-task mode for AI coding agents so implementation, review, validation, and hotfix work stay isolated and recoverable.
RecoveryUndo after a pull you regret
When a pull leaves your branch in an unexpected state, first determine what pull actually did, then recover with ORIG_HEAD, reflog, or a rescue branch.
Commandsgit-worktree Tutorial
Create parallel working directories for one repository to reduce stash/switch friction and improve multi-task flow.
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.
Reference
Command Learning Path
Organize high-frequency commands into a progressive path.
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.