Not because I write C. Because Make is a task runner that is already installed on every machine.

The Basics#

.PHONY: build test deploy clean

build:
	docker compose build

test:
	docker compose run --rm app npm test

deploy: build
	rsync -a --delete ./dist/ server:/opt/app/
	ssh server "cd /opt/app && docker compose up -d"

clean:
	docker compose down -v
	rm -rf dist node_modules

Now:

make build
make test
make deploy
make clean

.PHONY tells Make these targets are commands, not files. Without it, if you have a directory called build, Make would say “build is up to date” and do nothing.

Dependencies#

The power of Make is in the dependency graph. deploy depends on build:

deploy: build
	rsync -a --delete ./dist/ server:/opt/app/

When you run make deploy, it runs build first. If build fails, deploy never runs. This is what npm scripts cannot do cleanly.

Variables#

SERVER := myserver
REMOTE_DIR := /opt/app
IMAGE := myapp:latest

build:
	docker build -t $(IMAGE) .

push: build
	docker push $(IMAGE)

deploy: push
	ssh $(SERVER) "cd $(REMOTE_DIR) && docker pull $(IMAGE) && docker compose up -d"

Override from the command line:

make deploy SERVER=staging-server

Multi-Stage Builds With File Targets#

Make tracks file timestamps. This is useful for caching:

node_modules: package.json package-lock.json
	npm ci
	touch node_modules

dist: node_modules $(shell find src -type f)
	npm run build

.PHONY: serve
serve: dist
	python3 -m http.server 8080 -d dist

node_modules only rebuilds if package.json or package-lock.json changed. dist only rebuilds if source files changed. Make compares file timestamps automatically.

Help Target#

Add a self-documenting help target:

.DEFAULT_GOAL := help

help: ## Show this help
	@grep -E '^[a-zA-Z_-]+:.*?## .*$$' $(MAKEFILE_LIST) | \
		awk 'BEGIN {FS = ":.*?## "}; {printf "  \033[36m%-15s\033[0m %s\n", $$1, $$2}'

build: ## Build the Docker image
	docker compose build

test: ## Run the test suite
	docker compose run --rm app npm test

deploy: ## Deploy to production
	./deploy.sh

clean: ## Remove all build artifacts
	rm -rf dist node_modules

Now make with no arguments prints:

  build           Build the Docker image
  test            Run the test suite
  deploy          Deploy to production
  clean           Remove all build artifacts

Environment-Specific Configs#

ENV ?= development

ifeq ($(ENV),production)
  COMPOSE_FILE := docker-compose.yml -f docker-compose.prod.yml
else
  COMPOSE_FILE := docker-compose.yml
endif

up:
	docker compose $(addprefix -f ,$(COMPOSE_FILE)) up -d

# Usage:
# make up           → development
# make up ENV=production  → production

Parallel Execution#

Make can run independent targets in parallel:

make -j4 lint test typecheck

As long as these targets do not depend on each other, Make runs all four simultaneously. This is free parallelism with no extra scripting.

A Real Project Makefile#

.PHONY: help dev build test lint deploy clean
.DEFAULT_GOAL := help

IMAGE := myapp
TAG := $(shell git rev-parse --short HEAD)

help:
	@grep -E '^[a-zA-Z_-]+:.*?## .*$$' $(MAKEFILE_LIST) | \
		awk 'BEGIN {FS = ":.*?## "}; {printf "  \033[36m%-15s\033[0m %s\n", $$1, $$2}'

dev: ## Start development server
	docker compose up -d
	docker compose logs -f app

build: ## Build production image
	docker build -t $(IMAGE):$(TAG) -t $(IMAGE):latest .

test: ## Run tests
	docker compose run --rm app npm test

lint: ## Run linter
	docker compose run --rm app npm run lint

deploy: build ## Deploy to production
	docker push $(IMAGE):$(TAG)
	ssh server "docker pull $(IMAGE):$(TAG) && docker compose up -d"
	@echo "Deployed $(TAG)"

clean: ## Clean up everything
	docker compose down -v
	docker image prune -f

The Makefile is not trendy. It does not have a package ecosystem or a plugin system. But it works everywhere, it handles dependencies, it supports parallelism, and it does not require installing anything. For project automation, that is hard to beat.

Git worktrees fix this entirely: they let you check out several branches at once, each in its own directory, all sharing one repository.

What Is a Worktree?#

A worktree is a separate working directory that shares the same .git data. Each worktree can have a different branch checked out simultaneously:

# You are on main in /home/user/project
git worktree add ../project-hotfix hotfix/urgent-fix

Now you have two directories:

/home/user/project          → main branch
/home/user/project-hotfix   → hotfix/urgent-fix branch

Both share the same git history. Commits in one are visible in the other. But they have completely independent working directories.

The Workflow#

My typical day looks like this:

# Main work
cd ~/projects/app

# Someone needs a review - create a worktree
git worktree add ~/reviews/pr-142 origin/feature/new-api

# Review in a completely separate directory
cd ~/reviews/pr-142
npm install  # only needed first time
npm test

# Done reviewing, remove it
cd ~/projects/app
git worktree remove ~/reviews/pr-142

The key advantage: my main working directory is completely untouched. No stashing, no branch switching, no reinstalling dependencies.

Practical Patterns#

Parallel testing#

Run tests on two branches at the same time:

git worktree add /tmp/test-main main
git worktree add /tmp/test-feature feature/new-thing

# In two terminals
cd /tmp/test-main && npm test
cd /tmp/test-feature && npm test

Long-running branches#

If you maintain a staging branch alongside main:

git worktree add ~/staging staging

Keep it around permanently. Push to staging by working in that directory. No branch switching ever.

CI simulation#

Test your CI pipeline locally against a clean checkout:

git worktree add /tmp/ci-test HEAD
cd /tmp/ci-test
npm ci
npm run lint
npm test
npm run build

This catches the classic “works on my machine” issues where you have uncommitted files or stale build artifacts that mask problems.

Managing Worktrees#

# List all worktrees
git worktree list

# Output:
# /home/user/project         abc1234 [main]
# /home/user/project-hotfix  def5678 [hotfix/urgent-fix]
# /tmp/ci-test               abc1234 (detached HEAD)

# Remove a worktree
git worktree remove /home/user/project-hotfix

# Clean up stale worktree references
git worktree prune

Gotchas#

You cannot check out the same branch in two worktrees. Git prevents this because having the same branch in two places would make it ambiguous which working directory a commit applies to.

If you need to work on the same branch in two places, create a local tracking branch:

git worktree add ../experiment experiment-copy
cd ../experiment
git checkout -b experiment-local origin/experiment

The other thing to watch out for is node_modules. Each worktree needs its own node_modules because paths are different. The first npm install in a new worktree takes time. After that, it is fast because the npm cache is shared.

vs. git stash#

Stash is fine for quick interruptions. If someone asks you a question and you need to check something on another branch for thirty seconds, stash works.

But for anything that takes more than a minute, worktrees are better. They do not mess with your working directory, they let you have multiple contexts open in different editor windows, and they do not have the failure mode where you forget to pop the stash and lose track of what you were doing.

I keep a ~/worktrees/ directory for temporary ones and let them accumulate during the week. Friday afternoon I run git worktree list and clean up anything I am done with.