Why size matters

Repository size affects clone speed, fetch time, CI cost, and IDE responsiveness. A single 200 MB binary committed once and removed is still in your repo forever. Finding it is the first step to slimming down.

The classic one-liner

git rev-list --objects --all | \
  git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' | \
  awk '/^blob/ {print $3, $4}' | \
  sort -n | tail -20

This lists the 20 largest blobs ever stored, with size and path. The output reveals candidates for cleanup.

The command everyone copies

If you have ever Googled "pretty git log", you have probably copied a variation of this command:

git log --all --graph --decorate --oneline

It draws an ASCII graph of all branches and tags, one commit per line, decorated with reference names. It is the single most useful read-only Git command.

Why blame

Blame answers "who wrote this line and why?" - the gateway to digging through history when something seems wrong, suspicious, or surprisingly clever. The name is misleading; the goal is rarely to assign fault, more often to find context.

The basics

git blame src/checkout.js
git blame -L 40,60 src/checkout.js     # specific line range

Each line shows the SHA, author, date, and content.

Following moved code

Code often moves between files. Default blame stops at the last move. To follow further:

Three strategies, three histories

When integrating a feature branch into main, you have three options. Each produces a different shape of history; each suits different teams.

Merge commit

git checkout main
git merge --no-ff feature/login

Result: a single merge commit on main with the feature branch's commits as its second parent. The feature is visible as a unit; bisect and revert can target the merge.

Pros: preserves the truth of how development happened; reverting the feature is one command.

The problem range-diff solves

Suppose a contributor pushes v1 of a patch series, then v2 after review feedback. As a reviewer, you want to see what changed between the versions, not the cumulative diff. git range-diff shows exactly that: the diff between two ranges of commits.

The basic invocation

git range-diff main..v1 main..v2

This compares the commits in main..v1 with those in main..v2, pairing them by similarity, and shows what changed.

The line-ending problem

Windows uses CRLF (\r\n), Linux and macOS use LF (\n). When developers on different platforms commit to the same repository, files flip back and forth and diffs become unreadable. .gitattributes is the cure.

Why a good .gitignore matters

Every accidentally committed node_modules, .env, or compiled binary is technical debt. A complete .gitignore from day one prevents the problem entirely. GitHub's github/gitignore repo provides community-maintained templates - the snippets below adapt them for common stacks.

Why migrate

Mercurial and Git are sibling systems - both distributed, both content-addressed, both supporting branches and merges. Migrating is mostly a question of tooling: most hosting providers, CI services, and IDEs now invest more in Git than in Mercurial. For teams choosing tooling alignment, the move is straightforward.

The standard tool: fast-export

The hg-fast-export tool emits Mercurial history in Git's fast-import stream format. It preserves authors, dates, branches, tags, and merges.

Why migrate

SVN works. It has worked for two decades. But its centralised model, slow branching, and difficulty integrating with modern tooling push most teams towards Git eventually. The migration is a one-time cost; the workflow improvements are permanent.

Why sign

Git's author and committer fields are unauthenticated metadata - anyone can claim to be anyone. For projects where commit authorship matters (regulated industries, security-sensitive libraries, attestable supply chains), cryptographic signatures bind a commit to a real key. GitHub, GitLab, and similar then display a verified badge.