Git Deep Dive Roadmap

Git is a distributed version control system — every clone is a full copy of the repository with complete history. Install: git is pre-installed on macOS/Linux, Windows users install Git for Windows (includes Git Bash). Essential global config: git config --global user.name 'Your Name', git config --global user.email 'you@example.com' (this info goes into every commit — use your real identity), git config --global core.editor 'code --wait' (use VS Code as commit message editor), git config --global init.defaultBranch main. SSH keys — generate with ssh-keygen -t ed25519, add the public key to GitHub/GitLab — avoids typing passwords on every push. GitHub CLI (gh) for creating repos and PRs from the terminal.

The basic Git loop: make changes → stage them → commit them. git init creates a .git directory (the entire repository). git status shows the working tree state — untracked, modified, staged. git add file stages specific files, git add . stages everything in the current directory. git commit -m 'message' creates a snapshot with the staged changes. git log shows the commit history (--oneline for compact, --graph for branch visualization, --all to include all branches). git diff shows unstaged changes, git diff --staged shows staged changes ready to commit. Each commit has a SHA (40-char hash), author, date, and message — it's an immutable snapshot, not a diff. Commit early, commit often — you can always clean up later with rebase.

The staging area (also called the index) is the most misunderstood Git concept — and the most powerful. It's a buffer between your working directory and the repository. git add -p (interactive patch) stages specific hunks within a file — you can commit half your changes and leave the rest for a separate commit. This is how you write clean, focused commit history even when you made multiple changes at once. git diff shows what's changed but not staged, git diff --staged shows what's staged but not committed. git reset HEAD file unstages a file without losing changes. Understand the three states: modified (working dir), staged (index), committed (repository).

Branches are lightweight pointers to commits — creating one is nearly instant. git branch name creates a branch, git switch name (or git checkout name) moves to it, git switch -c name creates and switches in one step. git branch -a lists all branches (local and remote). git branch -d name deletes a merged branch, -D force-deletes. HEAD is a pointer to the current branch (or a commit in detached HEAD state). Branches are cheap — use them liberally. Branch naming conventions: feature/add-login, fix/null-pointer, chore/update-deps. Protected branches (main, production) should require PRs. Never commit directly to main in a team environment.

git merge integrates one branch into another. Fast-forward merge — if the target branch hasn't diverged (no new commits on main since the branch was created), Git just moves the pointer forward (linear history). Three-way merge — if both branches have new commits, Git creates a merge commit with two parents. Merge conflicts occur when the same lines were changed differently on both branches — Git marks the conflict with <<<<<<, =======, >>>>>>>, you edit to the correct state, then git add + git commit. git mergetool opens a visual merge tool (VS Code, vimdiff, P4Merge). Understand that merge commits preserve full history but create a non-linear graph — some teams prefer rebase for linear history.

Remotes are references to other copies of the repository (usually on GitHub/GitLab). git remote add origin url adds a remote named 'origin' (convention — the canonical upstream). git push origin main pushes your commits to the remote. git fetch downloads remote changes without modifying local branches. git pull is fetch + merge (or rebase if configured). git clone copies an entire remote repository including history. Tracking branches — local branch 'main' tracks 'origin/main' (set with --set-upstream or -u on first push). git push --force-with-lease (safer force push — fails if someone else pushed since you last fetched — never force push to main). Remote-tracking branches (origin/main) are local read-only snapshots of the remote's state.

Git is the tool; GitHub is the collaboration platform. Issues: create issues for bugs and features, use labels, milestones, and assignees, close issues from commit messages (Fixes #42). Pull Requests: open a PR from a feature branch, write a clear description, request reviewers. Code review: leave line comments, request changes, approve — understand the difference between blocking and non-blocking feedback. PR conventions: draft PRs for work-in-progress, PR templates (.github/pull_request_template.md), linked issues. Branch protection rules: require PR reviews before merging, require status checks (CI) to pass, prevent direct pushes to main. Fork workflow: fork a repo, clone your fork, add upstream as a remote, sync with upstream via fetch + rebase, open PRs from your fork.

Knowing how to undo is what separates confident Git users from anxious ones. git restore file (discards unstaged working tree changes — irreversible!), git restore --staged file (unstages without losing changes). git revert SHA creates a new commit that is the inverse of the specified commit — safe for shared branches (preserves history). git reset moves the branch pointer backward — --soft (keep changes staged), --mixed (keep changes unstaged — default), --hard (discard changes — dangerous). git reset HEAD~3 goes back 3 commits. Reflog is your safety net — git reflog shows every HEAD movement for 90 days, including 'deleted' commits — nothing is truly gone until garbage collected.

git rebase moves commits to a new base — takes your branch's commits and replays them on top of another commit. Result: linear history without merge commits. git rebase main (while on feature branch) replays feature commits onto the tip of main — no merge commit, cleaner history. Interactive rebase (git rebase -i HEAD~n) lets you edit the last n commits — squash (combine into one), fixup (squash without keeping message), reword (change message), edit (amend a commit), reorder, drop. Golden rule: never rebase commits that have been pushed to a shared branch — you rewrite history, breaking everyone else's local copy. Use rebase for local cleanup before pushing a PR.

git stash saves your uncommitted changes (staged and unstaged) to a stack and reverts the working tree to HEAD — useful when you need to switch branches without committing half-done work. git stash pop restores the latest stash and removes it from the stack. git stash apply keeps the stash entry (can apply to multiple branches). git stash list shows all stash entries with their index. git stash drop stash@{n} removes a specific entry. git stash clear removes all. Name stashes with git stash push -m 'description'. Include untracked files with -u. git stash branch name creates a new branch from the stash — the cleanest way to promote a stash into a proper branch.

Git stores complete history — use it. git log --oneline --graph --all --decorate visualizes the entire branch structure. git log --author='name', --since='2 weeks ago', --grep='keyword' for filtering. git log -S 'string' (pickaxe) — find commits that added or removed a specific string. git log -- path/to/file for a single file's history. git blame file shows the last commit that modified each line (who broke it). git show SHA:path/to/file shows a file at any commit. git diff main...feature shows all changes on feature since it diverged from main (three dots). git bisect automates binary search for the commit that introduced a bug — git bisect start, git bisect bad, git bisect good SHA, repeat until found.

Tags mark specific commits as important — typically release versions. Lightweight tag — git tag v1.0.0 (just a name for a commit, like a branch that doesn't move). Annotated tag — git tag -a v1.0.0 -m 'Release message' (a full Git object with tagger, date, and message — preferred for releases). git push origin --tags pushes all tags to remote (tags are not pushed automatically with git push). git push origin v1.0.0 pushes a specific tag. Delete locally: git tag -d v1.0.0, remotely: git push origin --delete v1.0.0. Semantic versioning (semver): MAJOR.MINOR.PATCH — bump MAJOR for breaking changes, MINOR for new features, PATCH for bug fixes. GitHub Releases use tags as their anchor.

Git hooks are scripts that run automatically at specific points in the Git workflow — stored in .git/hooks/ (not committed by default). Client-side hooks: pre-commit (runs before commit is created — perfect for linting, formatting, tests on staged files), commit-msg (validates commit message format — enforce Conventional Commits), pre-push (run tests before push). Server-side hooks: pre-receive, update, post-receive (reject bad pushes, send notifications). husky is the standard tool to manage Git hooks in JavaScript projects — install hooks that are committed to the repo (not .git/hooks). lint-staged runs linters/formatters only on staged files — fast. GitHub Actions are server-side CI but hooks handle local enforcement.

Workflow choice determines how your team ships code. GitFlow (Vincent Driessen) — main, develop, feature/*, release/*, hotfix/* — complex, suited for versioned software releases (mobile apps, libraries). GitHub Flow — main is always deployable, short-lived feature branches, merge via PR, deploy immediately — simple, suited for continuous deployment web apps. Trunk-Based Development — everyone commits to main (or very short-lived feature branches), feature flags for incomplete features — fastest CI/CD, requires discipline. Conventional Commits (feat:, fix:, docs:, chore:, breaking change: BREAKING CHANGE in footer) enable automated changelog generation and semantic-release for automated versioning. Most teams use a variant of GitHub Flow or Trunk-Based.

git cherry-pick SHA copies a specific commit onto the current branch — useful for porting a hotfix to multiple release branches without merging everything. git worktree add path branch checks out a second branch into a separate directory — work on two branches simultaneously without stashing or cloning again (ideal for reviewing a PR while continuing work on a feature). Git LFS (Large File Storage) stores large binary files outside the main Git object store — tracked files are replaced by pointer files, actual content stored on LFS server. Configure with git lfs track '*.psd'. git bundle creates a portable file containing the repository — useful for offline transfer. git archive exports files without Git metadata.