Git Course

Welcome to the complete Git course — your roadmap from absolute beginner to a confident, production-grade version control engineer who ships safely every day.

Version control is a system that records every change to your files so you can travel back in time, compare versions, and collaborate with teammates without overwriting each other.

Git is a fast, distributed version control system created by Linus Torvalds in 2005 to manage the Linux kernel — every developer keeps a full copy of the project history on thei…

Git is used by 95% of professional developers because it lets teams branch fearlessly, review changes line-by-line, automate testing on every push, and roll back instantly when…

Installing Git takes under two minutes on macOS, Windows or Linux and gives you the same command-line tool used inside GitHub, GitLab, Bitbucket and Azure DevOps.

Git configuration sets your identity, default branch name, editor, alias shortcuts and merge tool — values stored in ~/.gitconfig that follow you across every repository.

Running git init creates a hidden .git folder that turns any directory into a fully tracked Git repository ready for its first commit.

The working directory is the regular folder on disk where you actually edit files — Git watches it and reports which files have changed since the last commit.

The staging area (also called the index) is a draft of your next commit — a place to carefully assemble exactly which changes belong together before you snapshot them.

A commit is an immutable snapshot of your staged changes plus a message, an author, a timestamp and a parent — together they form the chain that is your project history.

git status is the most-typed Git command in the world — it answers: which files changed, which are staged, and what branch am I on?

git log walks the commit chain backwards from HEAD, showing who shipped what and when — essential for code archaeology and incident investigation.

Undo in Git is layered: restore undoes file edits, reset moves the branch pointer, and revert safely creates an inverse commit on shared history.

.gitignore tells Git which files (build outputs, secrets, node_modules, .env) to never track — protecting both your repository size and your security.

Best practices like Conventional Commits, short-lived branches, atomic commits and signed commits separate hobby repositories from production-grade engineering.

A branch in Git is just a tiny pointer to a commit — creating one is instantaneous and lets you explore an idea without disturbing main.

git branch feature/login and git switch -c feature/login create a new branch — the second also moves you onto it in one step.

git switch replaces the older git checkout for moving between branches — Git updates your working directory to match that branch's snapshot.

A clean branch workflow is: pull main, branch off, commit small chunks, push, open a PR, react to review, merge — repeat several times a day.

Feature branching means every change — even a one-line typo fix — gets its own short-lived branch so it can be reviewed and tested in isolation.

git merge combines two branch histories into one — Git either fast-forwards the pointer or creates a merge commit with two parents.

A fast-forward merge happens when main hasn't moved since you branched — Git just slides the pointer forward, leaving a perfectly linear history.

A merge conflict happens when two branches change the same lines — Git inserts markers and asks you to choose.

Resolving conflicts means reading both sides, picking what should survive, deleting the markers, then git add the file and committing to complete the merge.

git rebase replays your commits on top of another branch's tip — producing a clean, linear history at the cost of rewriting commit SHAs.

git cherry-pick copies a single commit from one branch onto another — perfect for back-porting a bug fix from main to a release branch.

git stash shelves your work-in-progress so you can switch branches with a clean tree, then pop it back later.

Deleting merged branches with git branch -d and pruning stale remotes with git fetch --prune keeps your team's branch list readable.

Naming branches feature/*, fix/*, hotfix/*, release/* tells humans and CI bots exactly how to treat the branch.

Strategies like Git Flow, GitHub Flow and Trunk-Based Development each trade off release cadence vs branch complexity — pick one and document it.

Collaboration with Git means everyone holds a full copy of history and synchronises through a shared remote — usually GitHub or GitLab.

git pull is shorthand for git fetch + git merge (or --rebase) — it brings your branch up to date with the remote.

git push uploads your local commits to the remote and updates the remote branch pointer — the moment your teammates can see your work.

git fetch downloads new commits from the remote without touching your working directory — letting you inspect changes before merging.

A pull request is a hosted conversation around a topic branch: discussion, line-by-line review, automated CI checks and a final merge button.

Code review is where engineering culture lives — it catches bugs, spreads knowledge, and gives juniors a structured place to learn from seniors.

A fork is your own server-side copy of someone else's repository — the standard pattern for contributing to open source projects you don't have write access to.

The open source workflow is fork → branch → commit → push → pull request — millions of contributions to React, Vue, Linux and Kubernetes follow this exact path.

A healthy team workflow combines short branches, fast PRs, green CI, automated deploys and observable production — Git sits at the heart of all of it.

Squash, rebase, merge commits, protected branches, required reviewers and signed commits all combine into a strategy your team agrees on once and lives with daily.

Pair programming with Git uses the Co-authored-by: trailer in the commit message so both engineers receive credit for the work.

GitHub and GitLab let you grant Read, Triage, Write, Maintain or Admin permissions per team — least privilege keeps production safe.

Best practices: protect main, require PR reviews, enforce status checks, ban force-push, sign commits, and keep PRs small.

Large teams use code owners files, monorepos, ring-based deploys and merge queues to keep hundreds of engineers shipping to the same trunk safely.

Enterprises layer SSO, SAML, audit logs, secret scanning, branch protection and compliance gates on top of Git — making collaboration both fast and safe.

GitHub is the world's largest Git hosting platform — 100M+ developers use it for code, code review, issues, projects, CI/CD and package hosting.

Creating a repository on GitHub takes 30 seconds and gives you a remote URL plus a default main branch ready for your first push.

git remote add origin wires your local repo to a remote URL — from then on git push and git pull sync the two.

SSH keys let you push to GitHub without typing a password — generate with ssh-keygen -t ed25519 and paste the public key into your GitHub settings.

Over HTTPS, GitHub now requires a personal access token (PAT) or the GitHub CLI helper instead of your account password.

Issues are the lightweight tickets where bugs, features and discussions live — every commit can reference an issue with #123 for full traceability.

GitHub Projects is a flexible kanban / table view that turns issues and PRs into a planning board — agile boards without leaving the repo.

GitHub Actions runs YAML workflows on every push or PR — perfect for tests, linters, security scans, builds and deploys.

Discussions are forum-style conversations attached to a repository — the right home for Q&A, RFCs and community announcements.

Releases are tagged snapshots of your code with notes and downloadable assets — the way semver versions like v1.4.0 reach your users.

Repository management covers settings, secrets, environments, branch protection, code owners and webhooks — the levers that turn a repo into a product.

Contributing to open source teaches you to read large codebases, follow community style guides, and engage respectfully with maintainers in PR reviews.

GitHub Advanced Security adds secret scanning, Dependabot, CodeQL static analysis and signed commits — all driven by Git history.

Optimization means small clones, shallow fetches, Git LFS for binaries, archived old branches and a clear CODEOWNERS file.

Real workflows combine PRs, Actions, Environments, required reviewers and merge queues — exactly how Vercel, Stripe and Shopify ship to production.

Git Flow uses long-lived develop, release/* and hotfix/* branches around main — great for products with scheduled releases.

Trunk-based development means short branches and many merges per day to a single main trunk — the model used by Google, Facebook and most SaaS companies.

A monorepo holds many projects in one Git repo — tools like Nx, Turborepo and Bazel make builds, tests and deploys scale across thousands of packages.

Semantic Versioning (MAJOR.MINOR.PATCH) communicates breaking, additive and bug-fix changes — automated by tools like semantic-release driven from commit messages.

Release management turns a sequence of merged PRs into a versioned, tagged, documented release — usually automated end-to-end.

Continuous Integration runs tests on every push; Continuous Deployment ships every green commit to production — Git is the trigger and the audit log.

Automated deploys push your code from a green CI run to staging or production with zero human steps — and roll back automatically if health checks fail.

Git hooks are scripts in .git/hooks that run at lifecycle events — pre-commit, commit-msg and pre-push enforce style and tests locally.

git rebase -i lets you reorder, squash, edit or drop commits on a branch — the power tool for cleaning up history before a PR lands.

Squashing collapses many WIP commits into one tidy commit — most teams squash on merge so main reads like a clean changelog.

git bisect performs a binary search over your commit history to find the exact commit that introduced a bug — minutes instead of hours.

Submodules embed one Git repo inside another at a pinned SHA — useful for shared libraries, but heavier than monorepos or package managers.

Tags are immutable named pointers to specific commits — annotated tags also carry a message and a signature, ideal for releases.

Deployment workflows like blue/green, canary and rolling all use Git tags or branches as the source of truth for what is live where.

Enterprise architectures combine self-hosted GitHub Enterprise, mirror caches, runners and policy engines to serve thousands of developers globally.

Internally Git is a content-addressed snapshot store — every file, directory and commit is keyed by the SHA of its content.

Git has four object types: blob (file), tree (directory), commit (snapshot) and tag — together they form the entire history.

A commit points to one tree (the root directory snapshot); each tree points to blobs (files) and sub-trees — a recursive snapshot at every commit.

Git uses SHA-1 (migrating to SHA-256) to address every object — change one byte and the SHA changes, which is why history is tamper-evident.

Git stores loose objects in .git/objects/xx/yyyy...

Pack files are zlib-compressed bundles of related objects with delta compression — they shrink a 100MB checkout into a few MB on disk.

Performance tricks include partial clones, sparse checkouts, commit-graph files and the file system monitor — essential at monorepo scale.

Large repos benefit from Git LFS for binaries, scalar enlistments, sparse-checkout and shallow clones — Microsoft uses these on a 300GB Windows monorepo.

git gc repacks loose objects, prunes unreachable ones older than two weeks, and rewrites the reflog — keeping repositories fast over years of use.

Debug Git issues with GIT_TRACE=1, git fsck, git reflog and git cat-file — the same tools support engineers use.

Use git reflog to find any commit you've ever had checked out, then git switch -c rescue to bring it back as a branch.

Sign commits with GPG or sigstore, scan for secrets pre-commit, ban force-push to main, and require 2FA on every contributor account.

Mirror clones (git clone --mirror) plus offsite encrypted snapshots give you bulletproof Git backups even if GitHub goes down.

Scaling a repo means commit-graph caches, parallel fetch, pack file partitioning and a CDN-fronted Git server — all transparent to the developer.

Production Git systems run behind load balancers, with mirror caches per region, audit logs streamed to SIEM, and health checks driving auto-failover.

Enterprise teams pair Git with SSO, audit logs, signed commits and CODEOWNERS so hundreds of engineers can ship safely against the same trunk.

Modern SaaS teams branch off main, ship dozens of PRs per day, deploy automatically on merge, and roll back via Git revert if metrics drop.

Frontend teams pair Git with Storybook, Chromatic visual reviews and preview deploys per PR — every change visible before merge.

Backend teams add database migration files, contract tests and feature flags to every Git branch so risky changes can be released dark first.

Full-stack workflows synchronise frontend and backend changes inside a single PR using monorepos and atomic version bumps.

Agile sprints map naturally to Git: each user story becomes a branch, each PR a deliverable, each tag a release — all visible on the project board.

DevOps treats Git as the single source of truth — Infrastructure-as-Code, GitOps and ArgoCD all reconcile production from Git commits.

Release engineers own the train: tagging versions, generating changelogs from commits, and orchestrating staged rollouts driven by Git tags.

A hotfix branches from the production tag, applies the smallest possible fix, ships through expedited CI and is then merged back into main.

During an incident, git revert on the bad merge plus a re-deploy is the fastest, safest rollback — no manual file edits needed.

Multi-team collaboration uses CODEOWNERS, ring-based deploys, internal forks and merge queues to keep dozens of teams unblocked.

Startups stay lean with trunk-based development, GitHub Actions, Vercel previews and one-click rollbacks — Git is the entire ops department.

Open source engineers maintain healthy projects with issue templates, contribution guides, signed commits, semantic-release and welcoming reviews.

A production release pipeline turns every green merge to main into a versioned tag, container image, deploy and changelog — fully driven by Git.

Enterprise systems integrate Git with Jira, ServiceNow, Slack and SSO so every commit, PR and deploy is auditable end-to-end.

Hands-on exercises: initialise a repo, stage selectively, write a Conventional Commit message, push, open a PR and merge it — repeat until automatic.

Branching challenges: rebase a feature onto a moving main, cherry-pick a fix into a release, and split one big commit into three using interactive rebase.

Merge conflict drills: resolve overlapping line edits, deletes vs renames, and three-way conflicts using git mergetool.

Collaboration drills: review a PR with constructive feedback, request changes, approve, and use the merge queue safely.

GitHub-specific drills: write an Actions workflow, protect main, configure required checks, and publish a release with auto-generated notes.

Common Git interview questions span working tree vs index vs HEAD, fast-forward vs three-way merge, rebase vs merge, and recovery from force-push.

A mock Git interview asks you to walk through a real scenario at the whiteboard: a teammate force-pushed, CI failed, the prod tag is missing — what now?

Real scenarios: rolling back a bad deploy, splitting a monolith, cherry-picking a security patch into three release branches at once.

Workflow challenges compare Git Flow, GitHub Flow and Trunk-Based Development — pick the right one for a given team size and release cadence.

Debugging drills: use git bisect to find a regression, git blame to find an author, and git fsck to recover a corrupted repo.

OSS tasks: fork a project, add a test, run the linter, sign your commits with DCO, open a PR and respond to review feedback.

Recovery drills: rescue a deleted branch from reflog, undo a force-push from a teammate's local clone, and restore a lost commit.

CI/CD drills: write a workflow that runs on PRs, gate merges on green checks, build and push a Docker image on tag, and deploy to a preview environment.

Simulations put you on a 5-engineer team for one sprint — open PRs, review each other's code, resolve conflicts and ship a clean release tag.

Enterprise assessments measure your fluency with monorepos, CODEOWNERS, signed commits, audit trails and incident recovery — the senior bar.