Working on applications and services with many moving parts is hard and time consuming: you might be responsible for long running test suits. You might be responsible of peer reviewing multiple Merge Requests at a time or even, you might be responsible of fixing a critical bug found in production that can't wait. These are all scenarios we have faced before and have used git-switch to help move between branches. However, this is very limiting since you can only work on one branch at the time and your dev environment will have to change across branches. There is a better way.
What is Worktree
git-worktree is a way to work on multiple branches at a time in a non-blocking pattern. We can checkout multiple branches and we can open each on it's on Integrated Development Environment (IDE) or Code Editor.
# Checkout a new branch based on the current branch
git worktree add /path/to/new-branch
# Way to create a new branch where branch and dir name are different
git worktree add /path/to/branch -b my-new-branch
# To work on an exisiting branch
git worktree add /path/to/branch existing-branch
# Deliting a worktree
git worktree remove /path/to/branch
Git worktrees are synced to the main repo (where the checkout) happened which means we can manage them from there. Further, object references (refs) are also shared across the main worktree (repo where the checkout happened) and other worktrees.
Important
Git manages the worktrees for us. This means that it maintains metadata to remove and cleanout stale worktrees. To avoid this, we have to use the lock feature of worktree and/or configure the git-gc (Garbage Collection) utility.
git worktree add /path/to/new-branch --lock
# Or
git worktree lock --reason "I am not done with you" /path/to/new-branch
So, now that we know how to create a new worktree, how can worktree help us where switch can't?
Switch VS Worktree
Checkout Process
- git-switch
# git-checkout
git add .
git commit -m "Committing before moving to another branch"
# git push -u origin current-branch
# Checkout a new branch based on main
git switch -c hotfix/broken-link main
# Or
git add .
git stash
git switch -c hotfix/broken-link main
- git-worktree
# By default, worktrees checkout the new branch from the main branch unless specifid otherwise.
git worktree add ../urgent-fix --reason "To fix a broken link in our UI" --checkout hotfix/broken-link
We can reduce the amount of time we take to get started on the new branch as we don't have to stage or commit anything.
Non-Blocked Workflows.
Because you can only checkout one branch at a time with git-switch, if you are running for example, a deployment , you can't make changes to the source code without risking introducing syntax errors that the deployment command line interface (CLI) will pick up and crash the deployment.
git worktree add ../deployment-test --reason "To test my deployment for failure" --checkout my-working-branch
make -f ../deployment-test/Makefile
Using worktrees allows us to delegate the deployment testing to another worktree with our working branch checked out while we can continue to work on the current copy we are on in the main worktree.
Quick Experimentation
Using git-switch to set an experimentation branch can be time consuming and expensive as mentioned before. Additionally, if we are experimenting with new packages and configurations, these are things that are not usually tracked and are added to the .gitignore file to avoid accidental commits. To avoid these issues, we can leverage git-worktree.
# Checkout a throw-away branch for a quick experiment
git worktree add ../my-experiment --checkout working-branch --detach
# Remove the branch when done
git worktree remove ../my-experiment
Conclusion
As developers, we are always moving fast and living dangerously. It is always a positive when we can find ways to help us continue to do so with reduced risks. Git worktrees is a great way to speed up your workflow and experiment in a non-blocking, non-destructive manner.
Hope you found this guide useful and as awesome as I did.