Git Worktree 없이 AI 코딩 세션을 병행해서 사용하는 방법
AI 코딩 도구를 사용하다 보면 하나의 프로젝트에서 여러 세션을 동시에 활용하고 싶어집니다. 예를 들어 Claude Code를 두 개 실행해서 하나는 UI를 수정하고, 다른 하나는 버그 원인을 분석하게 하는 식입니다.
이 방식은 잘 사용하면 생산성을 높일 수 있습니다. 하지만 아무 기준 없이 같은 프로젝트 폴더에서 여러 AI 세션이 동시에 파일을 수정하게 하면 문제가 생길 수 있습니다. 같은 파일을 동시에 고치거나, 한 세션의 미완성 변경사항을 다른 세션이 기준으로 삼는 상황이 생길 수 있기 때문입니다.
가장 안전한 방법은 Git worktree입니다. worktree 기반 병렬 작업은 이전 글인 바이브코딩에서 여러 AI 코딩 세션을 동시에 사용할 때 안전하게 작업하는 방법에서 정리했습니다.
하지만 worktree는 새 작업 폴더를 만들고, 브랜치를 관리하고, 작업 공간을 나누어야 하므로 부담스럽게 느껴질 수 있습니다. 그렇다면 Git worktree 없이도 여러 AI 코딩 세션을 병행해서 사용할 수 있을까요?
가능합니다. 다만 핵심은 여러 세션이 동시에 파일을 수정하지 않도록 통제하는 것입니다.
Git Worktree가 부담스러운 이유
Git worktree는 하나의 Git 저장소에서 여러 개의 작업 폴더를 만들어 각각 다른 브랜치로 작업할 수 있게 해주는 기능입니다.
예를 들면 다음과 같은 구조를 만들 수 있습니다.
project/
├── main/
├── wt-login-ui/
└── wt-header-fix/각 폴더에서 별도 Claude Code 세션을 실행하면 서로의 파일 변경이 섞이지 않습니다. 병렬 작업에는 매우 안전한 방식입니다.
하지만 실제로는 다음과 같은 이유로 부담이 될 수 있습니다.
| 부담 요소 | 설명 |
|---|---|
| 작업 폴더 증가 | 프로젝트 폴더가 여러 개 생김 |
| 브랜치 관리 필요 | 세션마다 브랜치를 나누어야 함 |
| 명령어가 익숙하지 않음 | git worktree add, remove, prune 등을 알아야 함 |
| 작은 프로젝트에는 과하게 느껴짐 | 간단한 수정에는 절차가 무거울 수 있음 |
| IDE 설정 반복 | 각 작업 폴더에서 환경을 다시 확인해야 할 수 있음 |
따라서 모든 상황에서 worktree를 쓰는 것이 정답은 아닙니다. 특히 개인 프로젝트나 작은 수정 작업이라면 더 단순한 방식이 현실적일 수 있습니다.
핵심 원칙: 병행하되, 동시에 수정하지 않는다
Git worktree 없이 여러 AI 세션을 사용할 때 가장 중요한 원칙은 다음입니다.
여러 세션을 병행해서 사용할 수는 있지만, 실제 파일 수정 권한은 한 번에 하나의 세션에만 준다.
즉, 세션을 여러 개 실행하더라도 모든 세션이 동시에 코드를 고치게 하면 안 됩니다.
대신 역할을 나누는 것이 좋습니다.
| 세션 | 역할 | 파일 수정 여부 |
|---|---|---|
| 세션 1 | 코드 분석 | 수정 금지 |
| 세션 2 | 실제 구현 | 수정 허용 |
| 세션 3 | 리뷰 및 테스트 제안 | 수정 금지 |
이렇게 하면 여러 AI 세션을 활용하면서도 Git 상태가 복잡하게 섞이는 것을 줄일 수 있습니다.
분석 세션, 구현 세션, 리뷰 세션으로 나누기
Git worktree 없이 병행 작업을 하고 싶다면, 세션별 역할을 분리하는 방식이 가장 안전합니다.
분석 세션
분석 세션은 코드를 직접 수정하지 않습니다. 대신 문제 원인을 찾고, 어떤 파일을 수정해야 하는지, 어떤 방식이 안전한지 제안합니다.
예를 들어 다음과 같이 지시할 수 있습니다.
이 세션에서는 파일을 수정하지 마세요.
현재 코드 구조를 분석하고, 문제 원인과 수정 후보만 제안하세요.
수정이 필요한 파일 목록, 예상 영향 범위, 리스크를 정리하세요.분석 세션의 목적은 “무엇을 고칠지”를 정하는 것입니다.
구현 세션
구현 세션은 실제로 파일을 수정하는 세션입니다. 단, 분석 세션이 제안한 범위 안에서만 수정하도록 제한합니다.
예시는 다음과 같습니다.
이 세션에서만 실제 파일을 수정합니다.
아래 분석 결과를 바탕으로 최소 변경만 수행하세요.
수정 가능 파일:
- src/components/LoginForm.tsx
- src/pages/Login.tsx
수정 금지:
- package.json
- lock file
- global.css
- routing
- shared API client
- 관련 없는 컴포넌트
수정 후 변경 파일과 주요 변경 내용을 요약하세요.구현 세션의 목적은 정해진 범위 안에서 최소한으로 고치는 것입니다.
리뷰 세션
리뷰 세션은 구현이 끝난 뒤 변경사항을 검토합니다. 이 세션도 직접 수정하지 않게 하는 것이 좋습니다.
예시는 다음과 같습니다.
이 세션에서는 파일을 수정하지 마세요.
현재 변경사항을 리뷰만 하세요.
확인할 항목:
- 의도하지 않은 파일이 수정되었는지
- 기존 기능이 깨질 가능성이 있는지
- 더 단순한 구현 방법이 있는지
- 테스트가 필요한 부분은 어디인지
수정 제안만 하고 실제 변경은 하지 마세요.리뷰 세션의 목적은 수정 결과가 안전한지 확인하는 것입니다.
같은 폴더에서 동시에 두 세션을 실행해도 되는 경우
원칙적으로 같은 프로젝트 폴더에서 두 개 이상의 Claude Code 세션이 동시에 파일을 수정하는 것은 권장하지 않습니다.
다만 다음 조건을 만족한다면 제한적으로 사용할 수 있습니다.
- 각 세션의 수정 파일이 명확히 다르다.
- 공통 파일을 수정하지 않는다.
package.json,global.css, routing, 설정 파일을 건드리지 않는다.- 각 세션이 수정 가능한 파일 목록을 명확히 알고 있다.
- 작업 후 반드시
git diff를 확인한다.
예를 들어 아래와 같은 병행 작업은 비교적 안전합니다.
| 세션 | 작업 | 수정 가능 파일 |
|---|---|---|
| 세션 A | 로그인 문구 수정 | src/pages/Login.tsx |
| 세션 B | README 정리 | README.md |
| 세션 C | 버튼 테스트 코드 추가 | src/components/Button.test.tsx |
반대로 아래와 같은 작업은 위험합니다.
| 세션 | 작업 | 위험한 이유 |
|---|---|---|
| 세션 A | 전체 UI 리팩토링 | 수정 범위가 너무 넓음 |
| 세션 B | 공통 Button 수정 | 여러 화면에 영향 |
| 세션 C | Tailwind 설정 수정 | 전체 스타일에 영향 |
| 세션 D | package 업데이트 | lock file 충돌 가능성 높음 |
즉, worktree 없이 같은 폴더에서 병행 작업을 하려면 파일 소유권을 명확히 해야 합니다.
수정 금지 파일을 정해두기
AI 코딩 세션을 병행할 때는 특히 다음 파일들을 조심해야 합니다.
package.json
package-lock.json
pnpm-lock.yaml
yarn.lock
vite.config.ts
next.config.js
tailwind.config.js
tsconfig.json
src/router/*
src/store/*
src/api/*
src/styles/global.css이 파일들은 프로젝트 전체에 영향을 줄 가능성이 높습니다.
예를 들어 package.json이 바뀌면 의존성 문제가 생길 수 있고, global.css가 바뀌면 여러 페이지의 UI가 동시에 영향을 받을 수 있습니다. tailwind.config.js나 vite.config.ts 역시 프로젝트 전체 빌드와 스타일에 영향을 줍니다.
따라서 병행 세션에서는 이런 파일을 기본적으로 수정 금지로 두는 것이 좋습니다. 공통 파일을 수정해야 한다면 해당 작업은 별도로 분리해서 하나의 세션에서만 처리하는 것이 안전합니다.
Worktree 없이 사용할 수 있는 간단한 워크플로우
Git worktree를 쓰지 않는다면 아래 흐름이 가장 현실적입니다.
- 먼저 작업을 작은 단위로 나눈다.
- 각 작업의 수정 예상 파일을 정리한다.
- 충돌 가능성이 낮은 작업부터 선택한다.
- 분석 세션은 수정 없이 원인과 방향만 제안한다.
- 구현 세션 하나만 실제 파일을 수정한다.
- 수정 후
git diff를 확인한다. - 문제가 없으면 commit한다.
- 다음 작업을 진행한다.
실제 예시는 다음과 같습니다.
1단계: Claude에게 작업을 나누게 한다.
2단계: 충돌 가능성이 낮은 작업을 고른다.
3단계: 구현 세션에 수정 가능 파일을 제한한다.
4단계: 수정 결과를 diff로 확인한다.
5단계: commit한다.
6단계: 다음 작업을 반복한다.이 방식은 완전한 병렬 개발은 아니지만, AI 세션을 여러 개 활용하면서도 변경사항이 뒤섞이는 위험을 줄일 수 있습니다.
작업을 먼저 나누는 프롬프트
가장 먼저 사용할 수 있는 프롬프트는 다음과 같습니다.
이 프로젝트를 수정하기 전에 먼저 작업을 작은 단위로 나누어 주세요.
각 작업에 대해 아래 항목을 표로 정리하세요.
- 작업명
- 예상 수정 파일
- 충돌 가능성: 낮음 / 중간 / 높음
- 선행 작업 여부
- 병행 작업 가능 여부
아직 파일은 수정하지 마세요.이 프롬프트의 목적은 곧바로 코드를 고치는 것이 아니라, 어떤 작업을 어떤 순서로 처리할지 정하는 것입니다.
예상 결과는 다음과 같은 형태가 됩니다.
| 작업 | 예상 수정 파일 | 충돌 가능성 | 병행 가능 여부 |
|---|---|---|---|
| README 실행 방법 정리 | README.md | 낮음 | 가능 |
| LoginForm 문구 수정 | LoginForm.tsx | 낮음 | 가능 |
| Header 모바일 메뉴 수정 | Header.tsx, Header.css | 중간 | 제한적 가능 |
| 전역 스타일 정리 | global.css | 높음 | 비추천 |
이렇게 먼저 나누어두면 AI에게 무작정 “전체를 개선해줘”라고 지시하는 것보다 훨씬 안전합니다.
단일 작업 실행 프롬프트
작업을 하나 골랐다면 구현 세션에는 아래처럼 지시합니다.
아래 작업만 수행하세요.
작업:
[작업 내용 입력]
수정 가능 파일:
[파일 목록 입력]
수정 금지:
- package.json
- lock file
- global.css
- routing
- shared API client
- 관련 없는 컴포넌트
작업 방식:
1. 관련 파일을 먼저 확인하세요.
2. 최소 변경으로 수정하세요.
3. 수정 후 변경 파일 목록을 요약하세요.
4. 테스트 또는 빌드 명령어가 있으면 실행하세요.예시는 다음과 같습니다.
아래 작업만 수행하세요.
작업:
로그인 화면의 validation 메시지를 더 명확하게 수정하세요.
수정 가능 파일:
- src/components/LoginForm.tsx
수정 금지:
- package.json
- lock file
- global.css
- routing
- shared API client
- 관련 없는 컴포넌트
작업 방식:
1. 관련 파일을 먼저 확인하세요.
2. 최소 변경으로 수정하세요.
3. 수정 후 변경 파일 목록을 요약하세요.
4. 테스트 또는 빌드 명령어가 있으면 실행하세요.핵심은 “이것만 수정하라”는 경계를 명확히 주는 것입니다.
리뷰 전용 프롬프트
작업 후에는 리뷰 세션을 따로 사용할 수 있습니다.
이 세션에서는 파일을 수정하지 마세요.
현재 변경사항을 리뷰만 하세요.
확인할 항목:
- 의도하지 않은 파일이 수정되었는지
- 기존 기능이 깨질 가능성이 있는지
- 더 단순한 구현 방법이 있는지
- 테스트가 필요한 부분은 어디인지
- 공통 파일이 변경되었는지
수정 제안만 하고 실제 변경은 하지 마세요.이때 먼저 사람이 아래 명령어로 변경사항을 확인하는 것이 좋습니다.
git status
git diff그리고 diff 내용을 리뷰 세션에 전달하면 됩니다.
리뷰 결과 문제가 없다면 커밋합니다.
git add .
git commit -m "Improve login validation message"같은 폴더 병행 작업 시 지켜야 할 규칙
Git worktree 없이 같은 폴더에서 병행 작업을 하려면 아래 규칙을 지키는 것이 좋습니다.
- 실제 파일 수정은 한 번에 하나의 세션만 수행한다.
- 여러 세션을 쓰더라도 분석, 구현, 리뷰 역할을 나눈다.
- 각 작업의 수정 가능 파일을 미리 정한다.
package.json, lock file,global.css, routing, 설정 파일은 병행 수정하지 않는다.- 작업 후 반드시
git diff를 확인한다. - 작업 단위마다 commit한다.
- 큰 리팩토링은 병행 작업으로 처리하지 않는다.
이 규칙을 지키면 worktree를 쓰지 않아도 어느 정도 안전하게 AI 코딩 세션을 병행할 수 있습니다.
언제 Worktree 없이 작업해도 괜찮을까?
다음과 같은 경우에는 worktree 없이도 충분합니다.
| 상황 | 추천 방식 |
|---|---|
| 혼자 작업하는 작은 프로젝트 | 같은 폴더에서 순차 작업 |
| 간단한 UI 문구 수정 | 파일 범위 제한 후 진행 |
| README나 문서 수정 | 병행 가능 |
| 특정 컴포넌트 테스트 추가 | 병행 가능 |
| 여러 세션을 참고용으로만 사용 | 분석/리뷰 세션으로 활용 |
반대로 다음 상황에서는 worktree를 쓰는 것이 더 낫습니다.
| 상황 | 추천 방식 |
|---|---|
| 여러 기능을 실제로 동시에 수정 | worktree 권장 |
| 대규모 리팩토링 | worktree 또는 별도 브랜치 관리 필요 |
| 공통 컴포넌트와 페이지를 동시에 수정 | worktree 권장 |
| 여러 명이 같은 프로젝트를 함께 수정 | 브랜치/PR/worktree 기반 권장 |
| 설정 파일이나 의존성을 자주 수정 | worktree 또는 별도 브랜치 권장 |
즉, worktree 없이도 병행은 가능하지만, 진짜 병렬 수정이 필요한 상황에서는 worktree가 더 안전합니다.
정리
Git worktree는 여러 AI 코딩 세션을 안전하게 병렬로 운영할 수 있는 좋은 방법입니다. 하지만 항상 필수는 아닙니다.
작은 프로젝트이거나, 수정 범위가 제한적이거나, 여러 세션을 분석과 리뷰 용도로 활용하는 정도라면 worktree 없이도 충분히 효율적으로 작업할 수 있습니다.
핵심은 다음입니다.
Worktree 없이 병행 작업을 하려면, 여러 세션을 동시에 수정자로 쓰지 말고 분석자, 구현자, 리뷰어로 나누어 사용해야 한다.
AI 코딩 도구는 코드를 빠르게 작성해 주지만, 작업 범위를 나누고 변경사항을 병합 가능한 단위로 관리하는 역할은 여전히 사람에게 있습니다.
가장 현실적인 운영 방식은 다음과 같습니다.
- 작업을 작게 나눈다.
- 수정 가능 파일을 제한한다.
- 구현 세션 하나만 실제로 수정한다.
- 다른 세션은 분석과 리뷰에 사용한다.
- 수정 후 diff를 확인한다.
- 작업 단위마다 commit한다.
이 방식만 지켜도 Git worktree 없이 AI 코딩 세션을 훨씬 안정적으로 병행 사용할 수 있습니다.
When you use AI coding tools, you may want to run multiple sessions in one project. For example, you might run two Claude Code sessions: one improves the UI, while the other analyzes the cause of a bug.
This can improve productivity when used carefully. But if multiple AI sessions edit files in the same project folder without clear rules, problems can appear. Two sessions may edit the same file, or one session may reason from another session's unfinished changes.
The safest method is Git worktree. I covered the worktree-based workflow in How to safely run multiple AI coding sessions in parallel.
But worktrees can feel heavy. You need additional folders, branch management, and a separated workspace. So can you use multiple AI coding sessions without Git worktree?
Yes. The key is to prevent multiple sessions from editing files at the same time.
Why Git Worktree Can Feel Heavy
Git worktree lets one Git repository have multiple working folders, each on a separate branch.
For example:
project/
├── main/
├── wt-login-ui/
└── wt-header-fix/
If each folder runs its own Claude Code session, file changes do not mix. This is a very safe way to handle parallel work.
In practice, though, it can feel like too much for small tasks.
| Friction | Description |
|---|---|
| More folders | The project now has multiple working folders |
| Branch management | Each session needs a separate branch |
| Unfamiliar commands | You need commands like git worktree add, remove, and prune |
| Too heavy for small projects | The process may feel excessive for simple edits |
| Repeated IDE setup | You may need to check environment setup in each folder |
So worktree is not the right answer for every situation. For personal projects or small edits, a simpler workflow can be more practical.
Core Principle: Work in Parallel, but Do Not Edit in Parallel
The most important rule is this:
You can use multiple sessions in parallel, but only one session should have file edit permission at a time.
In other words, even if several sessions are open, not every session should be allowed to change code.
Split the roles instead.
| Session | Role | File editing |
|---|---|---|
| Session 1 | Code analysis | Not allowed |
| Session 2 | Implementation | Allowed |
| Session 3 | Review and test suggestions | Not allowed |
This lets you benefit from multiple AI sessions while keeping Git state easier to reason about.
Split Sessions into Analysis, Implementation, and Review
If you want to work without Git worktree, separating session roles is the safest option.
Analysis Session
The analysis session does not edit files. It finds the cause, identifies which files likely need changes, and suggests a safe direction.
For example:
Do not edit files in this session.
Analyze the current code structure and only suggest causes and possible fixes.
List files that may need changes, expected impact, and risks.
The purpose of this session is deciding what should be changed.
Implementation Session
The implementation session is the only one that edits files. It should stay inside the scope suggested by the analysis session.
Example:
Only this session may edit files.
Based on the analysis below, make the smallest safe change.
Files you may edit:
- src/components/LoginForm.tsx
- src/pages/Login.tsx
Do not edit:
- package.json
- lock file
- global.css
- routing
- shared API client
- unrelated components
After editing, summarize changed files and main changes.
The purpose of this session is making the smallest change inside a defined boundary.
Review Session
The review session checks the result after implementation. It should also avoid direct editing.
Example:
Do not edit files in this session.
Only review the current changes.
Check:
- whether unexpected files changed
- whether existing behavior might break
- whether there is a simpler implementation
- where tests are needed
Only suggest changes. Do not modify files.
The purpose of this session is checking whether the change is safe.
When Multiple Sessions in the Same Folder Are Acceptable
As a rule, it is not recommended to let two or more Claude Code sessions edit files in the same project folder at the same time.
But limited use can be acceptable if these conditions are true:
- Each session has clearly different target files.
- No shared files are edited.
package.json,global.css, routing, and config files are not touched.- Each session knows exactly which files it may edit.
- You always inspect
git diffafter the work.
These examples are relatively safe:
| Session | Task | Editable file |
|---|---|---|
| Session A | Update login copy | src/pages/Login.tsx |
| Session B | Clean up README | README.md |
| Session C | Add button tests | src/components/Button.test.tsx |
These are risky:
| Session | Task | Why it is risky |
|---|---|---|
| Session A | Full UI refactor | Scope is too broad |
| Session B | Edit shared Button |
Affects many screens |
| Session C | Edit Tailwind config | Affects global styling |
| Session D | Update packages | High lock file conflict risk |
If you work in the same folder without worktrees, file ownership must be explicit.
Define Files That Are Off-Limits
Be especially careful with these files:
package.json
package-lock.json
pnpm-lock.yaml
yarn.lock
vite.config.ts
next.config.js
tailwind.config.js
tsconfig.json
src/router/*
src/store/*
src/api/*
src/styles/global.css
These files can affect the whole project.
For example, changing package.json can introduce dependency issues. Changing global.css can affect many pages at once. tailwind.config.js and vite.config.ts can affect the entire build or styling system.
So these files should usually be off-limits during parallel sessions. If a shared file must be changed, separate that task and let one session own it.
A Simple Workflow Without Worktree
If you do not use Git worktree, this workflow is the most practical.
- Split the work into small tasks.
- List the expected files for each task.
- Start with tasks that have low conflict risk.
- Let the analysis session suggest causes and direction without editing.
- Let only one implementation session edit files.
- Check
git diffafter editing. - Commit if the change is clean.
- Move to the next task.
In practice:
Step 1: Ask Claude to split the work.
Step 2: Pick a low-conflict task.
Step 3: Limit editable files in the implementation session.
Step 4: Check the diff.
Step 5: Commit.
Step 6: Repeat with the next task.
This is not full parallel development, but it lets you use multiple AI sessions while reducing the risk of mixed changes.
Prompt for Splitting Work First
Start with this prompt:
Before modifying this project, split the work into small tasks.
For each task, create a table with:
- task name
- expected files to edit
- conflict risk: low / medium / high
- prerequisite task, if any
- whether it can be done in parallel
Do not edit files yet.
The purpose is not to change code immediately. The purpose is to decide what to do and in what order.
Expected output:
| Task | Expected files | Conflict risk | Parallel? |
|---|---|---|---|
| Clean up README run instructions | README.md |
Low | Yes |
| Update LoginForm copy | LoginForm.tsx |
Low | Yes |
| Fix Header mobile menu | Header.tsx, Header.css |
Medium | Limited |
| Clean up global styles | global.css |
High | Not recommended |
This is much safer than telling the AI to "improve everything."
Prompt for Running One Task
After choosing one task, give the implementation session a narrow instruction.
Only perform the task below.
Task:
[Enter task here]
Files you may edit:
[Enter file list here]
Do not edit:
- package.json
- lock file
- global.css
- routing
- shared API client
- unrelated components
Workflow:
1. Inspect the relevant files first.
2. Make the smallest change.
3. Summarize changed files afterward.
4. Run test or build commands if available.
Example:
Only perform the task below.
Task:
Make the validation message on the login screen clearer.
Files you may edit:
- src/components/LoginForm.tsx
Do not edit:
- package.json
- lock file
- global.css
- routing
- shared API client
- unrelated components
Workflow:
1. Inspect the relevant files first.
2. Make the smallest change.
3. Summarize changed files afterward.
4. Run test or build commands if available.
The key is to define the boundary clearly: edit only this.
Prompt for Review Only
After implementation, you can use a separate review session.
Do not edit files in this session.
Only review the current changes.
Check:
- whether unexpected files changed
- whether existing behavior might break
- whether there is a simpler implementation
- where tests are needed
- whether shared files changed
Only suggest changes. Do not modify files.
Before doing that, check the changes yourself:
git status
git diff
Then pass the diff to the review session.
If the review result is clean, commit:
git add .
git commit -m "Improve login validation message"
Rules for Parallel Sessions in One Folder
If you use multiple sessions in the same folder without Git worktree, follow these rules:
- Only one session edits files at a time.
- Split sessions into analysis, implementation, and review roles.
- Define editable files before starting each task.
- Do not edit
package.json, lock files,global.css, routing, or config files in parallel. - Always check
git diffafter the work. - Commit each task separately.
- Do not handle large refactors as parallel work.
These rules make parallel AI coding reasonably safe even without worktree.
When Is It Okay to Work Without Worktree?
Worktree is not necessary in every case.
| Situation | Recommended approach |
|---|---|
| Small solo project | Sequential work in the same folder |
| Simple UI copy change | Limit file scope and proceed |
| README or documentation edit | Can be parallel |
| Test addition for one component | Can be parallel |
| Multiple sessions used only for reference | Use analysis/review sessions |
Use worktree in these cases:
| Situation | Recommended approach |
|---|---|
| Multiple features being edited at the same time | Worktree recommended |
| Large refactor | Worktree or separate branch management needed |
| Shared component and pages changing together | Worktree recommended |
| Multiple people editing the same project | Branch/PR/worktree workflow recommended |
| Frequent config or dependency changes | Worktree or separate branch recommended |
So parallel work is possible without worktree, but if you need true parallel editing, worktree is safer.
Summary
Git worktree is a good way to run multiple AI coding sessions safely. But it is not always required.
If the project is small, the edit scope is limited, or the extra sessions are used for analysis and review, you can work efficiently without worktree.
The key is:
Without worktree, do not make every session an editor. Use sessions as analyst, implementer, and reviewer.
AI coding tools can write code quickly, but the human still owns task boundaries and mergeable change units.
The most practical workflow is:
- Split the work into small tasks.
- Limit editable files.
- Let only one implementation session edit files.
- Use other sessions for analysis and review.
- Check the diff after editing.
- Commit each task separately.
This alone makes AI coding sessions much safer to use without Git worktree.
使用 AI 编码工具时，你可能会想在一个项目里同时使用多个会话。比如同时运行两个 Claude Code 会话：一个修改 UI，另一个分析 bug 原因。
如果使用得当，这种方式可以提升效率。但如果没有明确规则，让多个 AI 会话在同一个项目文件夹里同时修改文件，就容易出问题。它们可能同时修改同一个文件，或者一个会话基于另一个会话尚未完成的修改继续判断。
最安全的方法是 Git worktree。worktree 方式已经在上一篇文章 如何安全并行运行多个 AI 编码会话 中整理过。
但 worktree 有时会显得较重。你需要新建工作文件夹、管理分支、分离工作空间。那么不用 Git worktree，也能并行使用多个 AI 编码会话吗？
可以。关键是不要让多个会话同时修改文件。
为什么 Git Worktree 会显得麻烦
Git worktree 可以让一个 Git 仓库拥有多个工作文件夹，每个文件夹使用不同分支。
例如：
project/
├── main/
├── wt-login-ui/
└── wt-header-fix/
如果每个文件夹运行一个独立的 Claude Code 会话，文件修改就不会混在一起。这是处理并行工作的安全方式。
但在实际使用中，小任务可能会觉得流程太重。
| 麻烦点 | 说明 |
|---|---|
| 工作文件夹增加 | 项目会出现多个工作目录 |
| 需要管理分支 | 每个会话都要拆分分支 |
| 命令不熟悉 | 需要知道 git worktree add, remove, prune 等命令 |
| 对小项目显得过度 | 简单修改也要走较重流程 |
| IDE 设置重复 | 每个工作目录可能都要重新确认环境 |
所以 worktree 并不适合所有情况。对于个人项目或小修改，更简单的方式可能更现实。
核心原则：可以并行，但不要并行修改
不用 Git worktree 时，最重要的原则是：
可以同时使用多个会话，但一次只能让一个会话拥有文件修改权限。
也就是说，即使打开多个会话，也不应该让每个会话都能改代码。
更好的方式是分配角色。
| 会话 | 角色 | 是否修改文件 |
|---|---|---|
| 会话 1 | 代码分析 | 禁止修改 |
| 会话 2 | 实际实现 | 允许修改 |
| 会话 3 | 审查和测试建议 | 禁止修改 |
这样可以利用多个 AI 会话，同时让 Git 状态更容易理解。
分成分析会话、实现会话、审查会话
如果想不用 Git worktree 也并行工作，最安全的方法是分离会话角色。
分析会话
分析会话不直接修改文件。它负责找原因、判断哪些文件可能需要修改，并提出安全方向。
例如：
这个会话不要修改文件。
请分析当前代码结构，只提出问题原因和修改候选方案。
请整理需要修改的文件列表、预计影响范围和风险。
分析会话的目标是决定“要改什么”。
实现会话
实现会话是唯一实际修改文件的会话。它应该只在分析会话提出的范围内修改。
示例：
只有这个会话可以实际修改文件。
请基于下面的分析结果，只做最小修改。
可修改文件：
- src/components/LoginForm.tsx
- src/pages/Login.tsx
禁止修改：
- package.json
- lock file
- global.css
- routing
- shared API client
- 无关组件
修改后请总结修改文件和主要变更。
实现会话的目标是在明确边界内做最小修改。
审查会话
审查会话在实现结束后检查修改结果。这个会话也最好不要直接修改文件。
示例：
这个会话不要修改文件。
只审查当前修改。
检查项目：
- 是否修改了意外文件
- 是否可能破坏已有功能
- 是否有更简单的实现方式
- 哪些地方需要测试
只提出修改建议，不要实际改文件。
审查会话的目标是确认修改是否安全。
什么时候可以在同一个文件夹里开多个会话
原则上，不建议让两个以上 Claude Code 会话在同一个项目文件夹里同时修改文件。
但如果满足以下条件，可以有限使用：
- 每个会话的目标文件明确不同。
- 不修改共享文件。
- 不碰
package.json、global.css、routing、配置文件。 - 每个会话都清楚自己可以修改哪些文件。
- 工作后一定检查
git diff。
下面这些并行任务相对安全：
| 会话 | 任务 | 可修改文件 |
|---|---|---|
| 会话 A | 修改登录文案 | src/pages/Login.tsx |
| 会话 B | 整理 README | README.md |
| 会话 C | 添加按钮测试 | src/components/Button.test.tsx |
下面这些任务风险较高：
| 会话 | 任务 | 风险原因 |
|---|---|---|
| 会话 A | 整体 UI 重构 | 修改范围太宽 |
| 会话 B | 修改共享 Button |
影响多个页面 |
| 会话 C | 修改 Tailwind 配置 | 影响整体样式 |
| 会话 D | 更新 package | lock file 冲突风险高 |
也就是说，如果不用 worktree 在同一文件夹中并行工作，必须明确文件所有权。
先定义禁止修改的文件
并行使用 AI 编码会话时，尤其要小心这些文件：
package.json
package-lock.json
pnpm-lock.yaml
yarn.lock
vite.config.ts
next.config.js
tailwind.config.js
tsconfig.json
src/router/*
src/store/*
src/api/*
src/styles/global.css
这些文件可能影响整个项目。
例如，修改 package.json 可能引入依赖问题。修改 global.css 可能影响多个页面的 UI。tailwind.config.js 和 vite.config.ts 也会影响整体构建和样式系统。
因此，并行会话中默认应禁止修改这些文件。如果必须修改共享文件，最好单独拆出任务，并让一个会话负责。
不用 Worktree 的简单工作流
如果不用 Git worktree，下面这个流程最现实。
- 先把工作拆成小任务。
- 整理每个任务预计会修改的文件。
- 从冲突风险低的任务开始。
- 分析会话只提出原因和方向，不修改。
- 只有一个实现会话实际修改文件。
- 修改后检查
git diff。 - 没问题就 commit。
- 再进入下一个任务。
实际流程可以是：
第 1 步：让 Claude 先拆分任务。
第 2 步：选择冲突风险低的任务。
第 3 步：限制实现会话的可修改文件。
第 4 步：用 diff 检查修改结果。
第 5 步：commit。
第 6 步：重复下一个任务。
这不是完全的并行开发，但可以在使用多个 AI 会话的同时，降低修改混杂的风险。
先拆分任务的提示词
可以先使用这个提示词：
在修改这个项目之前，请先把工作拆成小任务。
请为每个任务用表格整理以下项目：
- 任务名
- 预计修改文件
- 冲突可能性：低 / 中 / 高
- 是否有前置任务
- 是否可以并行处理
现在不要修改文件。
这个提示词的目的不是马上改代码，而是决定做什么以及按什么顺序做。
预期结果类似这样：
| 任务 | 预计修改文件 | 冲突可能性 | 是否可并行 |
|---|---|---|---|
| 整理 README 运行方法 | README.md |
低 | 可以 |
| 修改 LoginForm 文案 | LoginForm.tsx |
低 | 可以 |
| 修复 Header 移动端菜单 | Header.tsx, Header.css |
中 | 有限制 |
| 整理全局样式 | global.css |
高 | 不推荐 |
这比直接让 AI “整体改善一下”安全得多。
执行单个任务的提示词
选定一个任务后，可以这样指示实现会话：
只执行下面这个任务。
任务：
[输入任务内容]
可修改文件：
[输入文件列表]
禁止修改：
- package.json
- lock file
- global.css
- routing
- shared API client
- 无关组件
工作方式：
1. 先查看相关文件。
2. 用最小修改完成。
3. 修改后总结变更文件列表。
4. 如果有测试或构建命令，请执行。
示例：
只执行下面这个任务。
任务：
把登录画面的 validation 消息改得更清楚。
可修改文件：
- src/components/LoginForm.tsx
禁止修改：
- package.json
- lock file
- global.css
- routing
- shared API client
- 无关组件
工作方式：
1. 先查看相关文件。
2. 用最小修改完成。
3. 修改后总结变更文件列表。
4. 如果有测试或构建命令，请执行。
重点是清楚地划定“只修改这些”的边界。
审查专用提示词
任务完成后，可以单独使用审查会话。
这个会话不要修改文件。
只审查当前修改。
检查项目：
- 是否修改了意外文件
- 是否可能破坏已有功能
- 是否有更简单的实现方式
- 哪些地方需要测试
- 是否修改了共享文件
只提出修改建议，不要实际改文件。
此时最好先由人执行以下命令确认修改：
git status
git diff
然后把 diff 内容交给审查会话。
如果审查结果没有问题，就提交：
git add .
git commit -m "Improve login validation message"
同一文件夹并行工作时的规则
不用 Git worktree 在同一个文件夹中并行工作时，建议遵守这些规则：
- 实际文件修改一次只由一个会话执行。
- 即使使用多个会话，也分成分析、实现、审查角色。
- 每个任务开始前先确定可修改文件。
- 不要并行修改
package.json、lock file、global.css、routing、配置文件。 - 工作后必须检查
git diff。 - 每个任务单独 commit。
- 大型重构不要当作并行任务处理。
遵守这些规则，即使不用 worktree，也能相对安全地并行使用 AI 编码会话。
什么时候可以不用 Worktree？
以下情况通常不用 worktree 也足够：
| 情况 | 推荐方式 |
|---|---|
| 独自维护的小项目 | 同一文件夹中顺序处理 |
| 简单 UI 文案修改 | 限制文件范围后进行 |
| README 或文档修改 | 可以并行 |
| 特定组件测试追加 | 可以并行 |
| 多个会话仅作为参考 | 用作分析/审查会话 |
相反，以下情况更适合使用 worktree：
| 情况 | 推荐方式 |
|---|---|
| 多个功能需要真正同时修改 | 推荐 worktree |
| 大规模重构 | 需要 worktree 或独立分支管理 |
| 同时修改共享组件和页面 | 推荐 worktree |
| 多人一起修改同一项目 | 推荐分支/PR/worktree 流程 |
| 经常修改配置文件或依赖 | 推荐 worktree 或独立分支 |
也就是说，不用 worktree 也能并行，但如果需要真正的并行修改，worktree 更安全。
总结
Git worktree 是安全运行多个 AI 编码会话的好方法。但它并不总是必需。
如果项目较小、修改范围有限，或者多个会话主要用于分析和审查，不用 worktree 也可以高效工作。
核心是：
不用 worktree 时，不要让所有会话都成为修改者。应该把它们分成分析者、实现者和审查者。
AI 编码工具可以快速写代码，但人仍然需要负责划分任务范围，并把修改管理成可合并的单位。
最现实的流程是：
- 把任务拆小。
- 限制可修改文件。
- 只让一个实现会话实际修改。
- 其他会话用于分析和审查。
- 修改后检查 diff。
- 每个任务单独 commit。
只要做到这些，即使不用 Git worktree，也能更稳定地并行使用 AI 编码会话。
AIコーディングツールを使っていると、1つのプロジェクトで複数のセッションを同時に活用したくなることがあります。たとえばClaude Codeを2つ起動し、一方にUI修正、もう一方にバグ原因の分析を任せるような使い方です。
うまく使えば生産性は上がります。しかし、明確なルールなしに同じプロジェクトフォルダで複数のAIセッションが同時にファイルを編集すると問題が起きます。同じファイルを同時に変更したり、一方の未完成の変更をもう一方が前提にしてしまうことがあるからです。
最も安全な方法はGit worktreeです。worktreeベースのワークフローは前回の記事 複数のAIコーディングセッションを安全に並行実行する方法 で整理しました。
ただしworktreeは、新しい作業フォルダ、ブランチ管理、分離された作業空間が必要なので、少し重く感じることがあります。では、Git worktreeなしでも複数のAIコーディングセッションを並行して使えるのでしょうか。
可能です。重要なのは、複数のセッションが同時にファイルを編集しないよう制御することです。
Git Worktreeが負担に感じる理由
Git worktreeは、1つのGitリポジトリから複数の作業フォルダを作り、それぞれ別ブランチで作業できる機能です。
例えば次のような構造を作れます。
project/
├── main/
├── wt-login-ui/
└── wt-header-fix/
各フォルダで別々のClaude Codeセッションを実行すれば、ファイル変更は混ざりません。並行作業には非常に安全な方法です。
しかし実際には、小さな作業には重く感じることがあります。
| 負担 | 説明 |
|---|---|
| 作業フォルダが増える | プロジェクトフォルダが複数になる |
| ブランチ管理が必要 | セッションごとにブランチを分ける必要がある |
| コマンドに慣れが必要 | git worktree add, remove, prune などを知る必要がある |
| 小さなプロジェクトには過剰 | 簡単な修正には手順が重い |
| IDE設定の確認が増える | 各作業フォルダで環境を確認する必要がある |
そのため、すべての状況でworktreeが正解というわけではありません。個人プロジェクトや小さな修正なら、もっと単純な方法の方が現実的です。
基本原則：並行はしても、同時編集はしない
Git worktreeなしで複数のAIセッションを使うとき、最も重要な原則は次です。
複数のセッションを並行して使ってもよいが、実際のファイル編集権限は一度に1つのセッションだけに与える。
つまり、複数セッションを開いていても、すべてのセッションがコードを変更してはいけません。
代わりに役割を分けます。
| セッション | 役割 | ファイル編集 |
|---|---|---|
| セッション1 | コード分析 | 禁止 |
| セッション2 | 実装 | 許可 |
| セッション3 | レビューとテスト提案 | 禁止 |
こうすると、複数AIセッションを活用しつつ、Git状態が複雑に混ざるリスクを下げられます。
分析セッション、実装セッション、レビューセッションに分ける
Git worktreeなしで並行作業したいなら、セッションごとに役割を分けるのが最も安全です。
分析セッション
分析セッションはファイルを直接編集しません。問題原因を探し、どのファイルを変更すべきか、どの方向が安全かを提案します。
例えば次のように指示します。
このセッションではファイルを編集しないでください。
現在のコード構造を分析し、問題原因と修正候補だけを提案してください。
修正が必要なファイル一覧、想定影響範囲、リスクを整理してください。
分析セッションの目的は「何を直すか」を決めることです。
実装セッション
実装セッションは実際にファイルを編集する唯一のセッションです。ただし、分析セッションが提案した範囲内だけを変更します。
例：
このセッションだけが実際にファイルを編集します。
下記の分析結果をもとに、最小限の変更だけを行ってください。
編集可能ファイル:
- src/components/LoginForm.tsx
- src/pages/Login.tsx
編集禁止:
- package.json
- lock file
- global.css
- routing
- shared API client
- 無関係なコンポーネント
編集後、変更ファイルと主な変更内容を要約してください。
実装セッションの目的は、決められた範囲内で最小限に直すことです。
レビューセッション
レビューセッションは実装後の変更内容を確認します。このセッションも直接編集しないようにします。
例：
このセッションではファイルを編集しないでください。
現在の変更内容をレビューだけしてください。
確認項目:
- 意図しないファイルが変更されていないか
- 既存機能が壊れる可能性はないか
- より単純な実装方法はないか
- テストが必要な箇所はどこか
修正提案だけを行い、実際の変更はしないでください。
レビューセッションの目的は、修正結果が安全かどうかを確認することです。
同じフォルダで複数セッションを実行してもよい場合
原則として、同じプロジェクトフォルダで複数のClaude Codeセッションが同時にファイルを編集することはおすすめしません。
ただし、次の条件を満たすなら限定的には使えます。
- 各セッションの編集対象ファイルが明確に異なる。
- 共通ファイルを編集しない。
package.json、global.css、routing、設定ファイルを触らない。- 各セッションが編集可能ファイル一覧を明確に知っている。
- 作業後に必ず
git diffを確認する。
次のような並行作業は比較的安全です。
| セッション | 作業 | 編集可能ファイル |
|---|---|---|
| セッションA | ログイン文言修正 | src/pages/Login.tsx |
| セッションB | README整理 | README.md |
| セッションC | ボタンのテスト追加 | src/components/Button.test.tsx |
逆に次の作業は危険です。
| セッション | 作業 | 危険な理由 |
|---|---|---|
| セッションA | UI全体リファクタリング | 編集範囲が広すぎる |
| セッションB | 共通 Button 修正 |
複数画面に影響する |
| セッションC | Tailwind設定修正 | 全体スタイルに影響する |
| セッションD | package更新 | lock file衝突リスクが高い |
つまり、worktreeなしで同じフォルダを使うなら、ファイルの所有権を明確にする必要があります。
編集禁止ファイルを決めておく
AIコーディングセッションを並行利用するときは、特に次のファイルに注意します。
package.json
package-lock.json
pnpm-lock.yaml
yarn.lock
vite.config.ts
next.config.js
tailwind.config.js
tsconfig.json
src/router/*
src/store/*
src/api/*
src/styles/global.css
これらはプロジェクト全体に影響する可能性が高いファイルです。
例えば package.json が変わると依存関係の問題が起きる可能性があります。global.css が変わると複数ページのUIが同時に影響を受けます。tailwind.config.js や vite.config.ts もプロジェクト全体のビルドやスタイルに影響します。
そのため、並行セッションでは基本的に編集禁止にしておくのが安全です。共通ファイルを変更する必要がある場合は、その作業を別タスクに分け、1つのセッションだけに担当させます。
Worktreeなしで使える簡単なワークフロー
Git worktreeを使わないなら、次の流れが現実的です。
- まず作業を小さな単位に分ける。
- 各作業の想定変更ファイルを整理する。
- 衝突リスクが低い作業から選ぶ。
- 分析セッションは編集せず、原因と方向だけ提案する。
- 実装セッション1つだけが実際にファイルを編集する。
- 編集後に
git diffを確認する。 - 問題なければcommitする。
- 次の作業へ進む。
実際には次のような流れです。
ステップ1: Claudeに作業を分解させる。
ステップ2: 衝突リスクが低い作業を選ぶ。
ステップ3: 実装セッションの編集可能ファイルを制限する。
ステップ4: diffで修正結果を確認する。
ステップ5: commitする。
ステップ6: 次の作業を繰り返す。
これは完全な並列開発ではありませんが、複数AIセッションを活用しながら変更が混ざるリスクを減らせます。
先に作業を分けるプロンプト
最初に使えるプロンプトは次の通りです。
このプロジェクトを修正する前に、まず作業を小さな単位に分けてください。
各作業について以下の項目を表で整理してください。
- 作業名
- 想定修正ファイル
- 衝突可能性: 低 / 中 / 高
- 先行作業の有無
- 並行作業可能か
まだファイルは編集しないでください。
このプロンプトの目的は、すぐコードを直すことではなく、何をどの順番で進めるかを決めることです。
想定結果は次のような形です。
| 作業 | 想定修正ファイル | 衝突可能性 | 並行可能か |
|---|---|---|---|
| README実行方法整理 | README.md |
低 | 可能 |
| LoginForm文言修正 | LoginForm.tsx |
低 | 可能 |
| Headerモバイルメニュー修正 | Header.tsx, Header.css |
中 | 限定的に可能 |
| グローバルスタイル整理 | global.css |
高 | 非推奨 |
こうして先に分けておくと、AIにいきなり「全体を改善して」と頼むよりずっと安全です。
単一作業実行プロンプト
作業を1つ選んだら、実装セッションには次のように指示します。
以下の作業だけを実行してください。
作業:
[作業内容を入力]
編集可能ファイル:
[ファイル一覧を入力]
編集禁止:
- package.json
- lock file
- global.css
- routing
- shared API client
- 無関係なコンポーネント
作業方法:
1. 関連ファイルを先に確認してください。
2. 最小限の変更で修正してください。
3. 修正後、変更ファイル一覧を要約してください。
4. テストまたはビルドコマンドがあれば実行してください。
例：
以下の作業だけを実行してください。
作業:
ログイン画面のvalidationメッセージをより明確に修正してください。
編集可能ファイル:
- src/components/LoginForm.tsx
編集禁止:
- package.json
- lock file
- global.css
- routing
- shared API client
- 無関係なコンポーネント
作業方法:
1. 関連ファイルを先に確認してください。
2. 最小限の変更で修正してください。
3. 修正後、変更ファイル一覧を要約してください。
4. テストまたはビルドコマンドがあれば実行してください。
重要なのは「これだけを修正する」という境界を明確にすることです。
レビュー専用プロンプト
作業後にはレビュー専用セッションを使えます。
このセッションではファイルを編集しないでください。
現在の変更内容をレビューだけしてください。
確認項目:
- 意図しないファイルが変更されていないか
- 既存機能が壊れる可能性はないか
- より単純な実装方法はないか
- テストが必要な箇所はどこか
- 共通ファイルが変更されていないか
修正提案だけを行い、実際の変更はしないでください。
このとき、人間が先に次のコマンドで変更内容を確認しておくのがよいです。
git status
git diff
そのdiff内容をレビューセッションに渡します。
レビュー結果に問題がなければコミットします。
git add .
git commit -m "Improve login validation message"
同じフォルダで並行作業するときのルール
Git worktreeなしで同じフォルダを使うなら、次のルールを守ると安全です。
- 実際のファイル編集は一度に1つのセッションだけが行う。
- 複数セッションを使う場合も、分析・実装・レビューに役割を分ける。
- 各作業の編集可能ファイルを先に決める。
package.json、lock file、global.css、routing、設定ファイルを並行編集しない。- 作業後は必ず
git diffを確認する。 - 作業単位ごとにcommitする。
- 大きなリファクタリングを並行作業として処理しない。
このルールを守れば、worktreeなしでもある程度安全にAIコーディングセッションを並行利用できます。
Worktreeなしで作業してよい場合
次のような場合はworktreeなしでも十分です。
| 状況 | 推奨方式 |
|---|---|
| 1人で作業する小さなプロジェクト | 同じフォルダで順次作業 |
| 簡単なUI文言修正 | ファイル範囲を制限して進行 |
| READMEや文書修正 | 並行可能 |
| 特定コンポーネントのテスト追加 | 並行可能 |
| 複数セッションを参考用に使う | 分析/レビューセッションとして活用 |
反対に、次の状況ではworktreeを使う方が安全です。
| 状況 | 推奨方式 |
|---|---|
| 複数機能を実際に同時修正する | worktree推奨 |
| 大規模リファクタリング | worktreeまたは別ブランチ管理が必要 |
| 共通コンポーネントとページを同時修正する | worktree推奨 |
| 複数人で同じプロジェクトを修正する | ブランチ/PR/worktreeベース推奨 |
| 設定ファイルや依存関係を頻繁に変更する | worktreeまたは別ブランチ推奨 |
つまり、worktreeなしでも並行作業は可能ですが、本当に同時編集が必要な状況ではworktreeの方が安全です。
まとめ
Git worktreeは、複数のAIコーディングセッションを安全に並列運用する良い方法です。しかし常に必須ではありません。
小さなプロジェクト、編集範囲が限定された作業、複数セッションを分析やレビューに使う程度なら、worktreeなしでも十分に効率よく作業できます。
重要なのは次の点です。
Worktreeなしで並行作業をするなら、複数セッションを同時に編集者として使わず、分析者・実装者・レビュアーとして分けて使う。
AIコーディングツールはコードを素早く書いてくれますが、作業範囲を分け、変更をマージ可能な単位に管理する役割は人間に残ります。
最も現実的な運用方式は次の通りです。
- 作業を小さく分ける。
- 編集可能ファイルを制限する。
- 実装セッション1つだけが実際に編集する。
- 他のセッションは分析とレビューに使う。
- 編集後にdiffを確認する。
- 作業単位ごとにcommitする。
これだけでも、Git worktreeなしでAIコーディングセッションをかなり安定して並行利用できます。
Cuando usas herramientas de codificación con IA, puede que quieras usar varias sesiones en un mismo proyecto. Por ejemplo, puedes ejecutar dos sesiones de Claude Code: una mejora la UI y otra analiza la causa de un bug.
Esto puede mejorar la productividad si se usa con cuidado. Pero si varias sesiones de IA editan archivos en la misma carpeta del proyecto sin reglas claras, aparecen problemas. Dos sesiones pueden editar el mismo archivo, o una sesión puede razonar desde cambios incompletos de otra.
El método más seguro es Git worktree. El flujo basado en worktree está resumido en el artículo anterior: Cómo ejecutar varias sesiones de codificación con IA de forma segura.
Pero worktree puede sentirse pesado. Necesitas carpetas adicionales, gestión de ramas y espacios de trabajo separados. Entonces, ¿se pueden usar varias sesiones de codificación con IA sin Git worktree?
Sí. La clave es impedir que varias sesiones editen archivos al mismo tiempo.
Por Qué Git Worktree Puede Sentirse Pesado
Git worktree permite que un repositorio Git tenga varias carpetas de trabajo, cada una en una rama diferente.
Por ejemplo:
project/
├── main/
├── wt-login-ui/
└── wt-header-fix/
Si cada carpeta ejecuta su propia sesión de Claude Code, los cambios de archivos no se mezclan. Es una forma muy segura de manejar trabajo paralelo.
En la práctica, sin embargo, puede parecer excesivo para tareas pequeñas.
| Fricción | Descripción |
|---|---|
| Más carpetas | El proyecto pasa a tener varias carpetas de trabajo |
| Gestión de ramas | Cada sesión necesita una rama separada |
| Comandos poco familiares | Hay que conocer git worktree add, remove, prune |
| Demasiado para proyectos pequeños | El proceso puede ser pesado para ediciones simples |
| Configuración repetida de IDE | Puede hacer falta revisar el entorno en cada carpeta |
Así que worktree no es la respuesta correcta en toda situación. Para proyectos personales o cambios pequeños, un flujo más simple puede ser más práctico.
Principio Central: Trabaja En Paralelo, Pero No Edites En Paralelo
La regla más importante sin Git worktree es esta:
Puedes usar varias sesiones en paralelo, pero solo una sesión debe tener permiso para editar archivos a la vez.
En otras palabras, aunque tengas varias sesiones abiertas, no todas deberían poder cambiar código.
Divide los roles.
| Sesión | Rol | Edición de archivos |
|---|---|---|
| Sesión 1 | Análisis de código | No permitido |
| Sesión 2 | Implementación | Permitido |
| Sesión 3 | Revisión y sugerencias de tests | No permitido |
Esto permite aprovechar varias sesiones de IA mientras mantienes el estado de Git más fácil de entender.
Divide Las Sesiones En Análisis, Implementación Y Revisión
Si quieres trabajar sin Git worktree, separar roles es la opción más segura.
Sesión De Análisis
La sesión de análisis no edita archivos. Encuentra la causa, identifica qué archivos probablemente necesitan cambios y propone una dirección segura.
Por ejemplo:
No edites archivos en esta sesión.
Analiza la estructura actual del código y solo sugiere causas y posibles soluciones.
Lista archivos que podrían necesitar cambios, impacto esperado y riesgos.
El objetivo de esta sesión es decidir qué debe cambiar.
Sesión De Implementación
La sesión de implementación es la única que edita archivos. Debe mantenerse dentro del alcance sugerido por la sesión de análisis.
Ejemplo:
Solo esta sesión puede editar archivos.
Con base en el análisis de abajo, haz el cambio mínimo seguro.
Archivos que puedes editar:
- src/components/LoginForm.tsx
- src/pages/Login.tsx
No edites:
- package.json
- lock file
- global.css
- routing
- shared API client
- componentes no relacionados
Después de editar, resume archivos cambiados y cambios principales.
El objetivo es hacer el cambio más pequeño dentro de un límite definido.
Sesión De Revisión
La sesión de revisión comprueba el resultado después de la implementación. También debe evitar editar directamente.
Ejemplo:
No edites archivos en esta sesión.
Solo revisa los cambios actuales.
Comprueba:
- si cambiaron archivos inesperados
- si se puede romper comportamiento existente
- si hay una implementación más simple
- dónde hacen falta tests
Solo sugiere cambios. No modifiques archivos.
El objetivo de esta sesión es comprobar si el cambio es seguro.
Cuándo Es Aceptable Usar Varias Sesiones En La Misma Carpeta
Como regla general, no se recomienda dejar que dos o más sesiones de Claude Code editen archivos en la misma carpeta del proyecto al mismo tiempo.
Pero puede ser aceptable de forma limitada si se cumplen estas condiciones:
- Cada sesión tiene archivos objetivo claramente distintos.
- No se editan archivos compartidos.
- No se toca
package.json,global.css, routing ni archivos de configuración. - Cada sesión sabe exactamente qué archivos puede editar.
- Siempre revisas
git diffdespués del trabajo.
Estos ejemplos son relativamente seguros:
| Sesión | Tarea | Archivo editable |
|---|---|---|
| Sesión A | Actualizar copy de login | src/pages/Login.tsx |
| Sesión B | Limpiar README | README.md |
| Sesión C | Agregar tests de Button | src/components/Button.test.tsx |
Estos son arriesgados:
| Sesión | Tarea | Por qué es arriesgado |
|---|---|---|
| Sesión A | Refactor completo de UI | Alcance demasiado amplio |
| Sesión B | Editar Button compartido |
Afecta muchas pantallas |
| Sesión C | Editar configuración de Tailwind | Afecta estilos globales |
| Sesión D | Actualizar packages | Alto riesgo de conflicto en lock file |
Si trabajas en la misma carpeta sin worktrees, la propiedad de archivos debe ser explícita.
Define Archivos Prohibidos
Ten especial cuidado con estos archivos:
package.json
package-lock.json
pnpm-lock.yaml
yarn.lock
vite.config.ts
next.config.js
tailwind.config.js
tsconfig.json
src/router/*
src/store/*
src/api/*
src/styles/global.css
Estos archivos pueden afectar a todo el proyecto.
Por ejemplo, cambiar package.json puede introducir problemas de dependencias. Cambiar global.css puede afectar muchas páginas a la vez. tailwind.config.js y vite.config.ts también pueden afectar el build o el sistema de estilos completo.
Por eso, estos archivos deberían estar fuera de alcance durante sesiones paralelas. Si hay que cambiar un archivo compartido, separa esa tarea y deja que una sola sesión la controle.
Un Flujo Simple Sin Worktree
Si no usas Git worktree, este flujo es el más práctico.
- Divide el trabajo en tareas pequeñas.
- Lista los archivos esperados para cada tarea.
- Empieza por tareas con bajo riesgo de conflicto.
- Deja que la sesión de análisis sugiera causas y dirección sin editar.
- Deja que solo una sesión de implementación edite archivos.
- Revisa
git diffdespués de editar. - Haz commit si el cambio está limpio.
- Pasa a la siguiente tarea.
En la práctica:
Paso 1: Pide a Claude que divida el trabajo.
Paso 2: Elige una tarea con bajo conflicto.
Paso 3: Limita los archivos editables en la sesión de implementación.
Paso 4: Revisa el diff.
Paso 5: Haz commit.
Paso 6: Repite con la siguiente tarea.
Esto no es desarrollo paralelo completo, pero permite usar varias sesiones de IA reduciendo el riesgo de cambios mezclados.
Prompt Para Dividir El Trabajo Primero
Empieza con este prompt:
Antes de modificar este proyecto, divide el trabajo en tareas pequeñas.
Para cada tarea, crea una tabla con:
- nombre de la tarea
- archivos que se esperan editar
- riesgo de conflicto: bajo / medio / alto
- tarea previa, si existe
- si se puede hacer en paralelo
No edites archivos todavía.
El objetivo no es cambiar código de inmediato. El objetivo es decidir qué hacer y en qué orden.
Resultado esperado:
| Tarea | Archivos esperados | Riesgo de conflicto | ¿Paralelo? |
|---|---|---|---|
| Limpiar instrucciones de README | README.md |
Bajo | Sí |
| Actualizar copy de LoginForm | LoginForm.tsx |
Bajo | Sí |
| Corregir menú móvil de Header | Header.tsx, Header.css |
Medio | Limitado |
| Limpiar estilos globales | global.css |
Alto | No recomendado |
Esto es mucho más seguro que pedirle a la IA que "mejore todo".
Prompt Para Ejecutar Una Tarea
Después de elegir una tarea, dale a la sesión de implementación una instrucción estrecha.
Realiza solo la tarea de abajo.
Tarea:
[Escribe la tarea aquí]
Archivos que puedes editar:
[Escribe la lista de archivos aquí]
No edites:
- package.json
- lock file
- global.css
- routing
- shared API client
- componentes no relacionados
Flujo:
1. Inspecciona primero los archivos relevantes.
2. Haz el cambio más pequeño.
3. Resume después los archivos cambiados.
4. Ejecuta comandos de test o build si existen.
Ejemplo:
Realiza solo la tarea de abajo.
Tarea:
Haz más claro el mensaje de validation en la pantalla de login.
Archivos que puedes editar:
- src/components/LoginForm.tsx
No edites:
- package.json
- lock file
- global.css
- routing
- shared API client
- componentes no relacionados
Flujo:
1. Inspecciona primero los archivos relevantes.
2. Haz el cambio más pequeño.
3. Resume después los archivos cambiados.
4. Ejecuta comandos de test o build si existen.
La clave es definir claramente el límite: edita solo esto.
Prompt Solo Para Revisión
Después de implementar, puedes usar una sesión separada de revisión.
No edites archivos en esta sesión.
Solo revisa los cambios actuales.
Comprueba:
- si cambiaron archivos inesperados
- si se puede romper comportamiento existente
- si hay una implementación más simple
- dónde hacen falta tests
- si cambiaron archivos compartidos
Solo sugiere cambios. No modifiques archivos.
Antes de hacerlo, revisa tú mismo los cambios:
git status
git diff
Luego pasa el diff a la sesión de revisión.
Si la revisión está limpia, haz commit:
git add .
git commit -m "Improve login validation message"
Reglas Para Sesiones Paralelas En Una Carpeta
Si usas varias sesiones en la misma carpeta sin Git worktree, sigue estas reglas:
- Solo una sesión edita archivos a la vez.
- Divide las sesiones en análisis, implementación y revisión.
- Define archivos editables antes de empezar cada tarea.
- No edites en paralelo
package.json, lock files,global.css, routing ni archivos de configuración. - Siempre revisa
git diffdespués del trabajo. - Haz commit por cada tarea.
- No manejes grandes refactors como trabajo paralelo.
Estas reglas hacen razonablemente seguro el uso de sesiones paralelas de IA incluso sin worktree.
Cuándo Está Bien Trabajar Sin Worktree
Worktree no es necesario en todos los casos.
| Situación | Enfoque recomendado |
|---|---|
| Proyecto pequeño en solitario | Trabajo secuencial en la misma carpeta |
| Cambio simple de texto UI | Limitar alcance de archivos y avanzar |
| Edición de README o documentación | Puede ser paralelo |
| Test para un componente concreto | Puede ser paralelo |
| Varias sesiones usadas solo como referencia | Usar sesiones de análisis/revisión |
Usa worktree en estos casos:
| Situación | Enfoque recomendado |
|---|---|
| Varias funciones editadas al mismo tiempo | Worktree recomendado |
| Refactor grande | Worktree o gestión separada de ramas |
| Cambios simultáneos en componente compartido y páginas | Worktree recomendado |
| Varias personas editando el mismo proyecto | Flujo con ramas/PR/worktree recomendado |
| Cambios frecuentes de configuración o dependencias | Worktree o rama separada |
Así que el trabajo paralelo es posible sin worktree, pero si necesitas edición paralela real, worktree es más seguro.
Resumen
Git worktree es una buena forma de ejecutar varias sesiones de codificación con IA de forma segura. Pero no siempre es obligatorio.
Si el proyecto es pequeño, el alcance de edición es limitado o las sesiones extra se usan para análisis y revisión, puedes trabajar eficientemente sin worktree.
La clave es:
Sin worktree, no conviertas todas las sesiones en editoras. Usa las sesiones como analista, implementadora y revisora.
Las herramientas de codificación con IA pueden escribir código rápido, pero la persona sigue siendo responsable de los límites de la tarea y de mantener cambios fáciles de fusionar.
El flujo más práctico es:
- Divide el trabajo en tareas pequeñas.
- Limita los archivos editables.
- Deja que solo una sesión de implementación edite archivos.
- Usa las otras sesiones para análisis y revisión.
- Revisa el diff después de editar.
- Haz commit por tarea.
Solo con esto, usar sesiones de codificación con IA sin Git worktree se vuelve mucho más estable.