Loading...
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.
เราเล่าจากการทดลองจริงในแล็บ ไม่ใช่ทฤษฎี — และให้หลักฐานพูดแทน
จุดเจ็บ: ระบบมักพังตอนที่ไม่มีใครดู กว่าจะรู้ตัวก็เสียหายไปแล้ว
เดิมพัน: ระบบล่มเงียบ ๆ คือฝันร้ายของทุกทีม เพราะความเสียหายโตขึ้นทุกนาทีที่ไม่รู้
สิ่งที่เราทำในแล็บ: 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.
A practical guide for every team member — read it, follow it, done.
Last updated: 2026-03-21
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.
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.
Imagine a project is a textbook.
Photocopy the entire textbook for everyone. One copy each.
6 people = 6 copies = 7.2 GB for the same code
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
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.
194 GB total, 143 GB used — node_modules duplicated per person, 1.1 GB per copy
Every folder had full access — anyone could edit or delete someone else's files. One typo = disaster.
Adding 1 person = clone + install dependencies for every repo. That's 3-5 GB more disk, every time.
The actual code is just a few MB. What ate the disk was node_modules — photocopied for every single person.
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.
One source of truth = no matter how many people join, disk stays flat. Adding a new member takes one command, done in 5 seconds.
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.
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/
Tell Cursor AI:
Cursor AI handles the installation automatically. You only need to do this once — unless someone adds a new package later.
Give instructions to Cursor AI — for example:
The AI builds the component and writes the code. Review the result, then hit Accept.
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.
git add .
git commit -m "feat: add login page"
git push origin feature/{{your-name}}
Open GitLab, click "Create Merge Request" (the button that appears after you push), write a short description, and wait for the maintainer to review.
Commit often. Push every day. If the server goes down, your code is safe on GitLab.
You've got the "why" and "how." Up next: the rules to remember + FAQ.
Not many. Just two categories — "don't do this" and "always do this." Follow these and you won't run into problems.
If you've read this far, you already understand the new system. Below are common questions and the daily prompts you'll actually use.
Here are the questions that come up most. If you've got something that isn't covered, ask your Lead Dev.
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"
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.
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.
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).
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.
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.
It stays as a backup for now. Once everyone has fully switched to the new folders, it'll be removed.
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// Save your work + push to GitLab// Pull the latest code from develop// Start the dev server// When you hit an errorgit 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
| 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/ |
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.
สิ่งที่ได้ และหลักคิด
ของจริงที่เอาไปใช้ต่อได้ ไม่ใช่แค่ไอเดีย หลักคิดของเราคือทำให้เป็นระบบที่ทำซ้ำได้และไม่พึ่งความจำคน
อยากเห็นระบบแบบนี้ทำงานกับงานของคุณ — ดู ViberQC และลงชื่อรอรอบทดลองที่ hilogiclabs.com
Join Hi Logic Labs for premium Content, Templates and a quality Community
Sign Up
Blueprint for Viber teams — AI creates, tests, and optimizes ads across 6 platforms with 9 AI Agents + Thompson Sampling. Starting at $28/month.
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.
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