Built-in shorthand

Beyond aliases, Git has a host of built-in shorthand notations that save typing once you know them. Most appear in the man pages but are easy to overlook.

What cherry-pick does

git cherry-pick takes a commit from one branch and applies it as a new commit on the current branch. The original commit is unchanged; the new commit has the same content but a fresh SHA, parent, and committer date.

The basic operation

git checkout release/1.4
git cherry-pick <sha>

This is how hotfixes commonly travel: develop a fix on main, cherry-pick onto release/x.y branches.

Two-dot versus three-dot

The single most-confused syntax in Git: .. versus ... in git diff and git log. They mean different things in different commands. Get this right and a whole class of confusion vanishes.

For git log

git log main..feature      # commits on feature but not on main
git log main...feature     # commits on either, but not both

Two-dot is the asymmetric difference; three-dot is the symmetric difference.

Defining "bad merge"

A bad merge can mean: you merged the wrong branch, you resolved conflicts incorrectly, the merge introduced a regression, or you merged before review was complete. Each has a different fix. The key is acting fast and using the right tool.

Case 1: not yet pushed

If the merge is local-only, undo it cleanly:

git reset --hard ORIG_HEAD

ORIG_HEAD records the pre-merge HEAD; this command rewinds the branch to before the merge. Add HEAD@{1} if ORIG_HEAD has been overwritten.

The cardinal rule

Anything committed to Git is permanent until you actively rewrite history. Anything pushed to a remote should be considered exposed - even if you delete it five seconds later, it may have been cloned, mirrored, indexed, or scraped. Treat every secret leak as a compromise.

Layer 1: never commit secrets

Use environment variables for runtime configuration. Use a secrets manager (Vault, AWS Secrets Manager, 1Password, Doppler) for storage. Commit only example files showing the structure:

The case for pre-push tests

A broken push wastes everyone's time - CI runs, fails, the team gets a notification, the author scrambles to fix. A pre-push hook running the test suite catches the issue before the push leaves your machine.

The simplest pre-push hook

# .git/hooks/pre-push
#!/usr/bin/env bash
set -e
npm test --silent

chmod +x .git/hooks/pre-push

Now git push runs npm test; failure aborts the push.

Why pre-commit hooks

The cheapest place to catch a lint error is on the developer's machine, before the commit even forms. Pre-commit hooks run lint, format, and quick checks; if they fail, the commit is rejected. CI catches what slips through, but pre-commit catches the 95% of issues that should never reach CI.

What "bare" means

A bare repository contains only the contents of .git - no working tree, no checkout. It is what you push to and clone from. Every Git server (GitHub, GitLab, your own) ultimately stores bare repositories.

Creating one

mkdir myproject.git
cd myproject.git
git init --bare

The .git suffix on the directory is a convention indicating bareness. The directory contents look like the inside of any .git: HEAD, config, objects/, refs/.

The goal

You want to move a directory from one repo to another, keeping the full commit history of the moved files. Plain copy-paste loses provenance; git filter-repo preserves it.

Step 1: extract the subset

git clone <source-repo> source-extract
cd source-extract
git filter-repo --path packages/widget --path-rename packages/widget:

This rewrites the clone to contain only files under packages/widget, moved to the root. Every commit that touched those files is preserved; commits that did not are dropped.

When you want to detach

You forked a repo, pushed your work, and now want to publish independently. Or your team is migrating to a new Git host. Or you cloned a vendor's repo and want to make it your own. In all these cases, you need to detach the local repo from its origin.