Wrap things up
| Time to read: |
|---|
| 2 minutes |
Command summary
The table below summarizes all the git worktree subcommands described in this section.
| Subcommand | Syntax | Description |
|---|---|---|
| add | git worktree add {PATH} {BRANCH} | Creates a new worktree at the given path to work on a specific branch, commit, or relative log index. |
| list | git worktree list | Displays all worktrees with their paths, HEAD SHAs, and branch names. |
| remove | git worktree remove {FOLDER} | Deletes a worktree folder, with protection for pending changes unless --force is used. |
| prune | git worktree prune | Removes all prunable worktrees (those with deleted folders or unreferenced branches). |
| move | git worktree move {SOURCE_FOLDER} {DESTINATION_FOLDER} | Moves a worktree folder to a new location. |
| lock | git worktree lock [--reason {REASON}] {FOLDER} | Prevents a worktree from being modified or deleted. |
| unlock | git worktree unlock {FOLDER} | Allows modifications again to a locked worktree. |
| repair | git worktree repair {PATH} ... | Attempts to repair workspaces located at specified paths. |
My personal workflow
Obviously each flow can be very personal and project-specific.
Nevertheless, most of the time I always have a minimum of three worktrees:
- repository-name is my original clone and default worktree for ongoing development;
- repository-name__prod is the worktree for the project production level code. This can be the main branch or any other branch matching what's currently in production.
- repository-name__lab is a worktree dedicated to expimental branches.
Depending on project size I can also have the following worktrees:
- repository-name__int is the project has some kind of integration branch, often a pre-production staging for the code to be delivered.
- repository-name__temp is a spare space to handle quick tasks, like a dependency update.
I rarely create a worktree on the fly for large projects. It's faster to just switch branch.
If you just start to use worktrees, keep things simple and grow with time. Maybe start with your initial clone and a separate worktree to handle bugfixes.
And with time you will be more at ease with worktrees and will start to add what can help you to improve your own workflow.
At the end of the day, the is the only goal: ensure you are kept in the flow and do not loose time when you need to switch branches. Changing your worktree will soon become a natural and more efficient choice.