Configuration layers

Git reads config from multiple files in order: system, global (~/.gitconfig), local (.git/config), worktree (when enabled), and command-line (-c). Later layers override earlier. Inspect with git config --list --show-origin.

Conditional includes

Apply different settings per directory tree — different signing keys for work and personal, for example:

The fork-and-PR pattern

Most platforms expect this flow: fork the upstream repo, clone your fork, branch for the change, push, open a pull request. Git treats it as a triangular workflow with two remotes.

Setup

git clone [email protected]:you/project.git
cd project
git remote add upstream https://github.com/org/project.git
git fetch upstream
git checkout -b fix/typo upstream/main

Branching off upstream/main rather than origin/main ensures you start from the canonical tip, not your possibly-stale fork.

Monorepo realities

A monorepo holds many projects in one repository — better refactors, atomic cross-project changes, single dependency graph. The cost: scale. Repos can grow to gigabytes and millions of files, where naive Git becomes painful. The good news: modern Git has tools designed for exactly this.

Why multiple remotes

Real workflows often involve more than one remote: an origin for your fork, an upstream for the canonical repo, plus mirrors, deploy targets, and per-environment forks. Git treats remotes as named bundles of fetch and push refspecs, and you can have as many as you like.

Why sparse

Sparse checkout populates only a subset of a repo's working tree, while keeping all metadata and history. For monorepos, this can mean checking out 1% of files and ignoring the other 99%, drastically speeding up git status, IDE indexing, and disk usage.

Cone mode

Modern Git (2.25+) introduces "cone mode" which restricts patterns to whole directories rather than arbitrary globs, in exchange for far better performance.

Beyond git stash pop

Stash is more capable than the basic save/pop you usually see. Used well, it is a personal scratchpad for context switches that beats committing WIP into the branch.

Two formats, two purposes

git archive produces a tar or zip snapshot of a tree — code without history, perfect for releases. git bundle produces a portable transport file containing objects and refs — perfect for offline transfer of an entire repo or update.

Notes without rewriting

git notes attaches arbitrary metadata to existing commits without changing their SHAs. Reviews, build statuses, sign-offs, performance metrics — anything you want associated with a commit can live in notes. They are stored in the special ref refs/notes/commits by default.

Diffing diffs

git range-diff (introduced in Git 2.19) compares two ranges of commits, pairing them by similarity and showing the inter-version changes. It is indispensable when reviewing patch series rerolls or comparing rebased branches.

Basic invocation

git range-diff main..topic-v1 main..topic-v2
git range-diff topic-v1...topic-v2
git range-diff origin/main...HEAD

The triple-dot form takes a single argument: the symmetric difference around a base. Useful when both topic branches share that base.

Series-driven development

Many projects review patches by series, not by branch. You publish v1, get feedback, revise, send v2, repeat until merged. Git provides first-class tools for this loop.