Book 06 · Cheat sheet

Version Control

Git concepts for tracking code changes and collaborating as a team.

01.gitignore: A .gitignore file is a plain-text file listing patterns for files and folders Git should not track, such as dependencies, build output, logs, and secrets.
.gitignore lists patterns for files Git should not track.
Typical entries include dependencies, build output, logs, and .env files with secrets.
Patterns support wildcards (*), directory rules (dist/), comments (#), and exceptions (!).
02Branch: A branch in Git is an independent line of development that lets you work on a feature or fix in isolation, without affecting the main code until you merge it.
A branch is an isolated line of development within a repository.
In Git, a branch is just a lightweight pointer to a commit.
The default branch is usually called main.
03Cherry-pick: A cherry-pick in Git copies the changes from one specific commit onto your current branch as a new commit, without merging the rest of the branch it came from.
git cherry-pick <hash> applies one commit's changes to the current branch.
It creates a new commit with a new hash rather than moving the original.
It is commonly used to backport fixes to release branches or move a misplaced commit.
04Code Review: A code review is the practice of having other developers check code changes before they are merged, to catch bugs, improve quality, and share knowledge.
A code review is a peer check of code changes before they are merged.
It usually happens in a pull request, with comments on specific lines.
Automated checks handle formatting and tests; humans focus on logic, design, and clarity.
05Commit: A commit is a saved snapshot of a project's files in Git, recorded with a unique ID, an author, a timestamp, and a message describing what changed.
A commit is a snapshot of staged changes plus metadata: author, date, message, and parent.
Each commit has a unique hash that identifies it.
Commits stay local until you push them to a remote repository.
06Conventional Commits: Conventional Commits is a specification for structured commit messages like feat: add search, so tools can write changelogs and pick versions automatically.
Conventional Commits defines a structured commit message format.
Messages look like type(scope): description, such as feat: or fix:.
A ! or a BREAKING CHANGE footer marks breaking changes.
07Detached HEAD: A detached HEAD is a Git state in which you have checked out a specific commit instead of a branch, so any new commits you make don't belong to any branch.
HEAD normally points to a branch; in a detached HEAD state it points directly at a commit.
Checking out a commit hash, a tag, or a remote-tracking branch detaches HEAD.
It is safe for inspecting, testing, or building old versions.
08Fast-Forward Merge: A fast-forward merge happens when the target has no new commits since the other branch split off, so Git just moves its pointer ahead with no merge commit.
A fast-forward moves the branch pointer instead of creating a merge commit.
It is only possible when the target branch hasn't diverged.
Rebasing a branch onto the latest main makes it fast-forwardable.
09Fork: A fork is a personal copy of someone else's repository on a hosting platform, letting you experiment freely and propose changes back to the original project.
A fork is a copy of a repository under your own account on a hosting platform.
Forks let you contribute, through pull requests, to projects you can't push to directly.
The original repository is called the upstream; sync with it to stay up to date.
10Git: Git is a free, open-source distributed version control system that tracks changes to files over time, so developers can collaborate and undo mistakes.
Git is a distributed version control system: every clone contains the full history.
Changes are saved as commits, which act as restorable snapshots.
Branches let you work on features in isolation and merge them later.
11Git Bisect: Git bisect is a Git command that uses binary search through commit history to find the exact commit that introduced a bug, testing only a few commits.
Git bisect finds the first commit that introduced a bug.
It uses binary search, so the number of steps grows very slowly with history size.
You mark commits with git bisect good and git bisect bad.
12Git Checkout: git checkout switches to another branch or commit, or restores files to an earlier version; newer Git splits these jobs into git switch and git restore.
git checkout switches branches or restores files.
git checkout -b creates a branch and switches to it.
Git 2.23 split it into git switch and git restore.
13Git Clone: Git clone is a Git command that downloads a complete copy of an existing repository, including its full history, and sets it up on your computer for work.
git clone <url> copies a repository, with its full history, to your machine.
It automatically adds a remote named origin and checks out the default branch.
Every clone is a complete repository that can be used offline.
14Git Diff: Git diff is a Git command that shows the exact line-by-line differences between two versions of your code, such as working files, staged changes, or commits.
git diff shows line-by-line changes, with - for removed lines and + for added lines.
Plain git diff shows unstaged changes; git diff --staged shows what will be committed.
You can compare branches, commits, or single files, and --stat summarizes each file's changes.
15Git Fetch: git fetch downloads new commits, branches and tags from a remote and updates remote-tracking branches like origin/main but not your own branches or files.
git fetch downloads new commits and refs from a remote.
It updates remote-tracking branches such as origin/main.
Your branches, staging area and files are not changed.
16Git Hooks: Git hooks are scripts that Git runs automatically at certain points, such as before a commit or a push, to check code, enforce rules, or automate tasks.
Hooks are scripts that Git runs automatically on events like commit, merge, or push.
A non-zero exit code from a hook like pre-commit cancels the operation.
Hooks in .git/hooks are not shared on clone, so teams use core.hooksPath or a hook manager.
17Git Pull: Git pull is a Git command that downloads new commits from a remote repository and immediately integrates them into your current local branch.
git pull runs git fetch and then merges or rebases the result into your current branch.
It fast-forwards when you have no local commits of your own.
git pull --rebase replays your local commits on top of the remote ones instead of creating a merge commit.
18Git Push: Git push is a Git command that uploads your local commits to a remote repository, updating the matching branch there so others can see and use your work.
git push uploads local commits to a branch on a remote repository.
git push -u origin <branch> publishes a new branch and sets its upstream for later pushes and pulls.
Git rejects pushes that are not fast-forwards; pull first, then push again.
19Git Remote: A Git remote is a named shortcut, such as origin, to another copy of your repository, usually on a server, that you push commits to and pull commits from.
A remote is a short name, such as origin, paired with the URL of another copy of the repository.
git clone creates the origin remote automatically.
git remote -v lists remotes, and git remote add creates a new one.
20Git Reset: Git reset is a Git command that moves the current branch back to an earlier commit and, depending on its mode, also resets the staging area and your files.
git reset <commit> moves the current branch to another commit, removing later commits from it.
--soft keeps the undone changes staged, --mixed (the default) keeps them unstaged, and --hard discards them.
git reset <file> unstages a file without changing its contents.
21Git Revert: Git revert is a Git command that undoes an earlier commit by creating a new commit with the opposite changes, leaving the existing project history intact.
git revert <hash> creates a new commit that reverses the changes of an earlier one.
History is not rewritten, so it is safe to use on shared branches like main.
Reverting a merge commit requires -m 1 to choose which parent to keep.
22Git Stash: Git stash is a command that temporarily saves uncommitted changes and cleans the working directory, so you can switch tasks and restore the work later.
git stash saves uncommitted changes and cleans the working directory.
Stashes are kept on a stack, and stash@{0} is always the newest.
pop restores and removes a stash, while apply restores it and keeps it.
23Git Tag: A Git tag is a named, permanent pointer to a specific commit, most often used to mark release versions such as v1.0.0 in a repository's history.
A tag is a fixed, named pointer to a single commit.
Annotated tags store an author, date, and message and are recommended for releases.
Lightweight tags are simple name-to-commit pointers with no extra data.
24Gitflow: Gitflow is a Git branching model that uses long-lived main and develop branches plus feature, release, and hotfix branches to manage scheduled releases.
Gitflow uses two permanent branches: main for released code and develop for upcoming work.
Feature branches come from develop, release branches prepare a version, and hotfix branches patch production.
Release and hotfix branches merge into both main and develop, and each release is tagged.
25GitHub: GitHub is a platform for hosting Git repositories and working on code together, with pull requests, code review, issues and the largest open-source community.
GitHub hosts Git repositories online and is owned by Microsoft.
Pull requests let teams review and discuss changes before merging.
Issues, projects and GitHub Actions cover planning and automation.
26GitLab: GitLab is a Git hosting platform combining code review, issue tracking, CI/CD pipelines and security scanning in one application, in the cloud or self-hosted.
GitLab hosts Git repositories with review, issues and CI/CD in one place.
It started in 2011 and became a public company in 2021.
Merge requests are its pull requests; pipelines live in .gitlab-ci.yml.
27HEAD: HEAD is Git's pointer to what you have checked out, normally the current branch, which points to its latest commit; new commits are added where HEAD points.
HEAD points to what is checked out, normally the current branch.
New commits are added where HEAD points, moving the branch forward.
HEAD~1, HEAD~3 and HEAD^2 refer to commits relative to it.
28Hotfix: A hotfix is an urgent fix for a serious problem in production, such as a crash or security hole, released quickly and outside the normal release schedule.
A hotfix urgently fixes a serious production problem.
It starts from the code that is running in production and stays minimal.
In Gitflow, hotfix branches merge into both main and develop.
29Merge: A merge in Git combines the changes from one branch into another, joining separate lines of development back together into a single, shared history.
A merge integrates changes from one branch into another.
A fast-forward merge just moves the pointer; a three-way merge creates a merge commit.
Conflicts occur when both branches change the same lines and must be resolved by hand.
30Merge Conflict: A merge conflict happens when Git can't automatically combine two branches because both changed the same lines of a file, so a person must decide the result.
A merge conflict occurs when two branches change the same lines, or one edits a file the other deletes.
Git marks conflicts in the file with <<<<<<<, =======, and >>>>>>> markers.
Resolve by editing the file, removing the markers, running git add, then committing.
31Monorepo: A monorepo is a single version control repository that holds the code for many projects, such as several apps, services, and shared libraries, managed together.
A monorepo keeps many projects and shared libraries in one repository.
Cross-project changes can land in a single atomic commit.
Workspaces and build tools like Nx, Turborepo, and Bazel keep builds fast by running only affected tasks.
32Pull Request: A pull request is a proposal to merge changes from one branch into another, giving teammates a place to review, discuss, and test the code before it is merged.
A pull request proposes merging one branch into another.
It is the main place for code review, discussion, and approval.
Automated tests usually run on every pull request before it is merged.
33Rebase: A rebase in Git replays a branch's commits on top of another commit, rewriting history to produce a cleaner, linear sequence of changes without merge commits.
Rebase replays your commits on top of another branch or commit.
It creates a linear history with no merge commits.
Rebased commits are new commits with new hashes.
34Repository: A repository is the storage location for a project, holding all of its files plus the complete history of every change recorded by a version control system.
A repository stores a project's files together with their complete change history.
Git keeps that history in a hidden .git directory.
Local repositories live on your machine; remote repositories are hosted for sharing.
35Semantic Versioning: Semantic versioning is a MAJOR.MINOR.PATCH numbering scheme in which each part signals whether a release breaks compatibility, adds features, or fixes bugs.
Versions follow the MAJOR.MINOR.PATCH format, such as 2.4.1.
Bump MAJOR for breaking changes, MINOR for new compatible features, and PATCH for bug fixes.
Lower numbers reset to zero when a higher one increases.
36Squash Merge: A squash merge combines all the commits from a branch into one new commit on the target branch, keeping the main history short and easy to read.
A squash merge turns all of a branch's commits into one commit on the target branch.
It keeps the main branch history clean, with one commit per feature or pull request.
The resulting commit has one parent, so Git does not record the branch as merged.
37Staging Area: The staging area in Git is a holding zone between your files and the next commit, where you place exactly the changes you want that commit to include.
The staging area holds the changes that will go into the next commit.
git add stages changes, and git commit saves only what is staged.
Git stores the staging area in the .git/index file, so it is also called the index.
38Trunk-Based Development: Trunk-based development is a branching strategy where developers merge small changes into one shared main branch at least daily, keeping it always releasable.
Everyone integrates into a single shared branch, usually main.
Branches, if used, live for a day or two at most.
Automated tests on every change keep the trunk releasable.
39Version Control: Version control is a system that records every change to a set of files, so you can see who changed what, return to earlier versions and work in parallel.
Version control records each change to a project's files with its author, date and reason.
You can compare, restore and combine versions instead of copying folders.
Distributed systems such as Git give every developer the full history.