Server Disk Full — Git Worktree Cuts 90% Instantly
Stop cloning repos for every team member. Git Worktree shares one codebase — disk dropped from 7.7 GB to 0.8 GB. Add new members in 5 seconds, zero extra disk.
One Folder Change. 90% Less Disk.
A practical guide for every team member — read it, follow it, done.
Last updated: 2026-03-21
Quick Summary
- Stop using ~/workspace/your-name/ — switch to /srv/projects/<project>/<your-name>/ instead
- Git Worktree (separate working folders from a single codebase) cuts disk from 7.7 GB down to 0.8 GB — a 90% drop
- Adding a new team member costs zero extra disk — one command, done in 5 seconds
- Everything works exactly the same — you're just opening a different folder in Cursor
Why did the server workflow need to change?
The server disk was running out of space. The culprit? node_modules — that giant folder full of project dependencies — was being cloned separately for every single developer. The same code eating disk 6-7 times over. Git Worktree fixes this completely. All you have to do is open a different folder in Cursor.
Change the folder you open — everything else stays exactly the same. Nothing new to learn.
How did the team work before?
Everyone would SSH into the server through Cursor and open their own folder at ~/workspace/their-name/. Inside, they'd clone every repo — Project-A, Project-B, Project-C. Everyone got the same code, but each person had their own full copy.
├── dev-a/
│ ├── Project-A/ ← dev-a's clone
│ ├── Project-B/ ← dev-a's clone
│ └── Project-C/ ← dev-a's clone
├── dev-b/
│ ├── Project-A/ ← dev-b cloned the same thing
│ ├── Project-B/ ← dev-b cloned the same thing
│ └── Project-C/ ← dev-b cloned the same thing
├── dev-c/
│ └── ... ← dev-c cloned it again
└── ...
Think of it this way
Imagine a project is a textbook.
Old way = Photocopying
Photocopy the entire textbook for everyone. One copy each.
6 people = 6 copies = 7.2 GB for the same code
New way = Library
One copy of the textbook sits in the library.
Everyone reads at their own desk, takes their own notes.
No matter how many people — disk doesn't grow
What problems did the old setup cause?
Three issues made the old system unsustainable — disk space, file permissions, and the inability to scale the team. These numbers come from actual measurements on the server, before and after the switch.
Disk Nearly Full
194 GB total, 143 GB used — node_modules duplicated per person, 1.1 GB per copy
Permissions Wide Open
Every folder had full access — anyone could edit or delete someone else's files. One typo = disaster.
Can't Scale the Team
Adding 1 person = clone + install dependencies for every repo. That's 3-5 GB more disk, every time.
Disk Usage — See the difference
The actual code is just a few MB. What ate the disk was node_modules — photocopied for every single person.
How does Git Worktree fix this?
Git Worktree lets everyone work from one single codebase. Each person gets their own "desk" (worktree) — a separate folder where they can edit files without touching anyone else's work.
The new server structure
│
├── .repos/ ← the library (don't touch!)
│ ├── Project-A.git/
│ ├── Project-B.git/
│ └── Project-C.git/
│
├── Project-A/ ← Project A
│ ├── main/ ← production (read-only)
│ ├── develop/ ← staging (merge point before production)
│ ├── dev-a/ ← dev-a's desk
│ ├── dev-b/ ← dev-b's desk
│ └── dev-c/ ← dev-c's desk
│
├── Project-B/ ← Project B
│ ├── main/ · develop/ · dev-a/ · dev-b/ · ...
│
└── Project-C/ ← Project C
├── main/ · develop/ · dev-a/ · ...
One source of truth = no matter how many people join, disk stays flat. Adding a new member takes one command, done in 5 seconds.
What do you actually need to do?
Just 5 steps. Everything works the same way it did before. You're only changing which folder you open in Cursor. No new tools to learn. Nothing extra to memorize.
01Open your new folder in Cursor
SSH into the server through Cursor like before — but point to the new path:
Old: /home/admin/workspace/dev-a/Project-B/
New: /srv/projects/Project-B/dev-a/
02Install dependencies (first time only)
Tell Cursor AI:
Cursor AI handles the installation automatically. You only need to do this once — unless someone adds a new package later.
03Write code as usual
Give instructions to Cursor AI — for example:
The AI builds the component and writes the code. Review the result, then hit Accept.
04Save your work (Git)
Tell Cursor AI:
The AI saves and pushes your code to GitLab. Replace {{your-name}} with your actual name — e.g., feature/dev-a, feature/dev-b.
Prefer typing commands yourself?
git add .
git commit -m "feat: add login page"
git push origin feature/{{your-name}}
05Create a Merge Request on GitLab
Open GitLab, click "Create Merge Request" (the button that appears after you push), write a short description, and wait for the maintainer to review.
The full flow in one picture
Write code
in your own folder
Commit
save locally
Push
send to GitLab
Merge Request
review + merge
Commit often. Push every day. If the server goes down, your code is safe on GitLab.
Halfway there
You've got the "why" and "how." Up next: the rules to remember + FAQ.
What rules do you need to remember?
Not many. Just two categories — "don't do this" and "always do this." Follow these and you won't run into problems.
Don't
- Don't edit files in the main/ folder — that's production, hands off
- Don't edit files in the develop/ folder — merge through GitLab instead
- Don't open someone else's folder — dev-a stays out of dev-b's space
- Don't touch the .repos/ folder — it's the shared library. If it breaks, everyone breaks.
- Don't merge into main yourself — always go through a Merge Request + review
Do
- Work in your own folder only
- Commit often — don't let changes pile up. Commit after every small feature.
- Push to GitLab every day — protect your code from local failures
- Create a Merge Request when a feature is done — let someone else review before merging
Almost done — just FAQ and the cheat sheet left
If you've read this far, you already understand the new system. Below are common questions and the daily prompts you'll actually use.
What does the team usually ask?
Here are the questions that come up most. If you've got something that isn't covered, ask your Lead Dev.
Do I need to move my code from ~/workspace/?
No. The new folder already has the same code. Just point Cursor to the new path — e.g., /srv/projects/Project-B/dev-a/
If you have uncommitted changes in the old workspace, tell Cursor: "commit my changes and push to GitLab" first. Then open the new folder and tell Cursor: "pull the latest code"
Do I need to run npm install every time?
No. Just once when you first open the new folder. After that, you only need to run it again if someone adds a new package to package.json.
What if two people edit the same file?
No problem. Everyone works in separate folders — dev-a edits page.tsx in /dev-a/ while dev-b edits page.tsx in /dev-b/. They're different copies. If there's a conflict (same file, same line), you'll resolve it during the GitLab merge — not before.
Can I look at someone else's code?
Yes — you can browse, but don't edit. Navigate to /srv/projects/Project-B/dev-b/ (swap in the name of whoever you want to check).
How do I test the develop branch (everyone's combined work)?
Point Cursor to /srv/projects/Project-B/develop/ and tell it: "pull the latest code, install dependencies, and start the dev server" — but remember, develop/ is read-only. Don't edit anything there.
A new person joined the team — what do we do?
Tell the Admin to run one command:
/srv/projects/add-member.sh Project-B {{new-member-name}}Done. The new person can open Cursor and point to their folder right away.
When will the old workspace get deleted?
It stays as a backup for now. Once everyone has fully switched to the new folders, it'll be removed.
Which Cursor prompts will you use every day?
Here are the prompts you'll actually use on a daily basis. Copy-paste them straight into Cursor.
// Check your current branch + what files changed"Show me the git status — what branch am I on and what files did I change?"
// Save your work + push to GitLab"Commit my changes and push to GitLab branch feature/{{your-name}}"
// Pull the latest code from develop"Pull the latest code from develop and merge it into my current branch"
// Start the dev server"Start the dev server for me"
// When you hit an error"How do I fix this error? [paste error message]"
Prefer typing commands yourself? Here they are
git branch # check current branch
git status # see changed files
git add . # stage files
git commit -m "feat: add xxx" # save
git push origin feature/{{your-name}} # push to GitLab
git pull origin develop # pull latest code
npm run dev # start dev server
Commit message format
Your folder paths — point Cursor here
| Team Member | Project-A | Project-B | Project-C |
|---|---|---|---|
| dev-a | /srv/projects/Project-A/dev-a/ | /srv/projects/Project-B/dev-a/ | /srv/projects/Project-C/dev-a/ |
| dev-b | /srv/projects/Project-A/dev-b/ | /srv/projects/Project-B/dev-b/ | /srv/projects/Project-C/dev-b/ |
| dev-c | /srv/projects/Project-A/dev-c/ | /srv/projects/Project-B/dev-c/ | /srv/projects/Project-C/dev-c/ |
| dev-d | /srv/projects/Project-A/dev-d/ | /srv/projects/Project-B/dev-d/ | /srv/projects/Project-C/dev-d/ |
| dev-e | /srv/projects/Project-A/dev-e/ | /srv/projects/Project-B/dev-e/ | /srv/projects/Project-C/dev-e/ |
Start here
Stop using ~/workspace/your-name/
→ Switch to /srv/projects/<project>/<your-name>/
Example: dev-a opens Cursor → /srv/projects/Project-B/dev-a/
Everything works the same. Just a different folder.
Related Articles
AdsPilot AI — Build an AI That Runs Your Ads
Blueprint for Viber teams — AI creates, tests, and optimizes ads across 6 platforms with 9 AI Agents + Thompson Sampling. Starting at $28/month.
Cursor Guide — Tell AI to Build, No Code
A complete Cursor IDE guide covering 9 categories and 38 topics — from basics to advanced. Packed with ready-to-use prompt examples. Written for executives and business owners who aren't developers.
Cursor for Vibe Coding Teams — Command AI, Skip Code
A complete guide to using Cursor for team collaboration on a shared Dev Server — set up AI, manage Secrets, Git Workflow, and prevent Conflicts, all through plain-language prompts without writing code yourself