Reviewing a pull request properly means running it, not just reading the diff. Switching your working copy back and forth costs your uncommitted state every time. Worktrees sidestep that.
Check out the PR next to your work#
git fetch origin
git worktree add ../myapp-pr-42 pr-42-branch
You get a second directory on the PR branch while your main checkout stays exactly as it was.
Give it its own environment#
A Laravel app needs more than the code:
cd ../myapp-pr-42
composer install
cp ../myapp/.env .env
Then change what must not clash: APP_URL and port if you serve both at once, and DB_DATABASE to a throwaway database so the PR’s migrations do not touch your dev data:
php artisan migrate --seed
php artisan serve --port=8001
Tear it down cleanly#
git worktree remove ../myapp-pr-42
The branch stays until you delete it; the directory and database go.
When it pays#
One PR a month is fine to stash and switch. A team merging daily needs the review to be cheap, and cheap means the PR runs in its own directory while your own work never moves.
Share this post
Keep reading
Annotating Commits with git notes: Metadata Without Rewriting History
Some things belong on a commit but not in it: review links, benchmark results, the ticket nobody remembered to reference. git notes adds them after the fact, no rebase required.
Backing Up Your Git Server So It Actually Restores
Every clone is a partial backup - but hooks, config and server state live outside the repo. Mirror, bundle, copy off-site, and rehearse the restore.
Branch Protection Rules That Stick
Three rules cover most of the risk on main: review required, tests green, no force-push. More than that tends to get routed around.
