Part 2: How to Create Git Worktrees and Manage Multiple Branches

Part 2 Git Worktree guide.

Worktree workflows

Worktree and Stashing

Worktrees reduce the need to stash because I do not have to constantly switch one folder between branches.

But stash is still useful inside a specific worktree if I have unfinished work.

Example:

git stash push -u -m "WIP before testing integration merge"

Then later:

git stash list
git stash apply stash@{0}

The difference is that with worktrees, stash becomes less of a daily branch-switching crutch and more of a temporary safety tool.

Worktree and Merging

The merge rule stays the same.

Stand on the branch that should receive the changes.

Example from the integration worktree:

cd ../datainsidedata-integration
git merge feat/add-post

This means:

integration/did-merge receives feat/add-post

Then:

git merge feat/community-projects

This means:

integration/did-merge receives feat/community-projects

Worktrees do not change Git merge logic. They make it easier to stand in the right place.

Worktree and Pull Requests

Worktrees also support a cleaner PR process.

Example release flow:

feat/add-post
→ merged into integration/did-merge

feat/community-projects
→ merged into integration/did-merge

feat/builder-staging
→ merged into integration/did-merge

integration/did-merge
→ PR into main

Open a PR:

cd ../datainsidedata-integration
gh pr create --base main --head integration/did-merge

After merge, update the main worktree:

cd ../datainsidedata-website
git switch main
git pull origin main

Updating Worktrees

Each worktree is its own working folder, so update it from inside that folder.

Example:

cd ../datainsidedata-add-post
git pull

Another:

cd ../datainsidedata-community-projects
git pull

For integration:

cd ../datainsidedata-integration
git pull

If the branch has no upstream yet:

git push -u origin branch-name

Listing Worktrees

Check all connected worktrees:

git worktree list

This helps prevent confusion about which branch is checked out where.

Removing a Worktree

When a worktree is no longer needed, remove it safely:

git worktree remove ../datainsidedata-staging

If the folder was manually deleted, clean up Git’s worktree records:

git worktree prune

Use prune when Git still remembers a worktree folder that no longer exists.

Moving a Worktree

If a worktree folder needs to move:

git worktree move ../old-folder-name ../new-folder-name

This keeps Git aware of the new location.

Best Practices

Use worktrees for long-lived or high-context branches.

Good candidates:

content branch
staging branch
integration branch

Avoid using worktrees for tiny one-line changes unless the overhead is worth it.

Keep branch names clear.

Examples:

feat/add-post
feat/community-projects
feat/builder-staging
integration/did-merge

Keep worktree folder names clear.

Examples:

datainsidedata-add-post
datainsidedata-community-projects
datainsidedata-builder-staging
datainsidedata-integration

Do not manually copy repo folders as a branch-management strategy.

• Use git worktree add instead.
• Run git worktree list often.
• Keep .env backed up manually.
• Keep generated output ignored.

Commit and push inside the worktree where the work belongs.

Common Mistakes

Trying to check out the same branch in two worktrees:

Git usually blocks this.

Forgetting which folder is on which branch:

git branch --show-current

Assuming .env is shared:

It is not automatically shared across worktrees.

Assuming generated files matter:

They can usually be rebuilt.

Deleting a worktree folder manually and forgetting to prune:

git worktree prune

Copying folders manually instead of using Git-managed worktrees:

This can recreate the original confusion.

When Worktrees Are Better Than Switching Branches

Worktrees are better when:

branches have different file structures
generated files cause branch-switching noise
multiple features are active at the same time
one branch powers a staging campaign
one branch prepares integration releases
different VS Code windows are useful

When Normal Branch Switching Is Still Fine

Normal branch switching is fine when:

the change is small
the branches have similar file structures
there is no generated output confusion
the working tree is clean
only one feature is active

Result

Using worktrees gives the DataInsideData workflow a cleaner structure.

Instead of constantly switching one folder between unrelated branches, each major branch can live in its own workspace.

That makes it easier to:

write content
build Builder Showcase
maintain staging
test integration
run a public campaign
protect main

The biggest lesson is that worktrees are not just convenience. They are workflow architecture.

Summary

Situation

I was switching between multiple DataInsideData branches and seeing files carry over, disappear, or show up unexpectedly in VS Code Source Control.

Task

I needed a cleaner way to manage branch-specific work without constantly reshaping one local folder.

Action

I learned to use git worktree so each major branch could have its own local folder and VS Code window.

Result

The workflow became easier to reason about.

Feature work, staging work, content work, integration testing, and campaign testing could happen in separate spaces while still sharing one Git repository history.

Final Mental Model

Branch
→ a line of commits

Working tree
→ the folder currently checked out for editing

Git worktree
→ an additional Git-managed working folder for another branch

Feature worktree
→ focused development

Staging worktree
→ public testing preparation

Integration worktree
→ release candidate testing

Main worktree
→ stable base

Final Worktree Workflow

• Create a worktree for each major branch.
• Open each worktree in its own VS Code window.
• Commit work inside the correct worktree.
• Merge feature branches into the integration worktree.
• Deploy staging from the campaign or integration branch.
• Open a PR from integration into main.
• Pull main after the PR is merged.
• Remove old worktrees when they are no longer needed.

Quick Command Reference

List worktrees:

git worktree list

Add an existing branch as a worktree:

git worktree add ../folder-name branch-name

Create a new branch and worktree:

git worktree add -b new-branch-name ../folder-name main

Remove a worktree:

git worktree remove ../folder-name

Clean up stale worktree records:

git worktree prune

Check current branch:

git branch --show-current

Open in VS Code:

code ../folder-name

This turns multi-branch development from one shifting folder into a set of clean, purpose-built workspaces.

---

Data Inside Data™.

Tech Hands, a Science Mind, and a Heart for Community.