Parallel agent가 mutable repository state를 공유하면 안전하지 않습니다. Git worktree를 사용하면 repository object database는 재사용하면서 각 Hermes process에 별도 directory와 branch를 줄 수 있습니다.
- Fresh context나 parallel reasoning의 이점이 있는 작업을 delegate합니다.
- 편집하는 worker마다 별도 worktree와 branch를 줍니다.
- Child는 conversation을 물려받지 않으므로 완전한 task context를 전달합니다.
- 병합 전에 integration checkout에서 diff를 검토하고 test를 다시 실행합니다.
1. Context 격리와 filesystem 격리 구분하기
Delegated child에는 독립된 conversation과 terminal session이 있습니다. Parent의 전체 conversation이 아니라 parent가 전달한 goal과 context만 받습니다. 이 특성은 context window를 보호하지만, 두 worker가 하나의 checkout에서 안전하게 작업하도록 만들어 주지는 않습니다.
Filesystem isolation은 별도 worktree가 맡습니다. Worktree마다 index, checked-out file, branch, working directory가 따로 있습니다. 두 agent가 동시에 편집해도 서로의 uncommitted file을 덮어쓰지 않습니다.
Parallel code change에는 두 경계를 함께 적용하세요. Fresh agent context와 dedicated Git worktree가 모두 필요합니다.
2. 결정적인 worktree fixture 실행하기
예제는 임시 repository, baseline commit, 두 worktree를 만듭니다. 한 branch는 documentation을 쓰고 다른 branch는 test note를 씁니다. 병합 전에 changed-file set이 겹치지 않는지 검사합니다.
workspace=$(mktemp -d)
python3 worktree_demo.py --workspace "$workspace" --json
Report에는 두 branch, merged file, isolation status, clean-tree status, non-merge commit 수가 나옵니다. Hermes나 model은 호출하지 않습니다. Provider credential 없이 Git 동작을 재현할 수 있습니다.
Workspace는 비어 있어야 합니다. Script는 임시 repository 내부에만 user.name과 user.email을 설정합니다. 사용자의 global Git configuration은 건드리지 않습니다.
3. 경로가 중요하면 worktree를 직접 만들기
기존 repository에서 assignment마다 branch와 directory를 하나씩 만듭니다.
git worktree add ../project-docs -b agent/docs
git worktree add ../project-tests -b agent/tests
git worktree list
각 Hermes process를 배정된 directory에서 시작하세요. Hermes는 current working directory를 project scope로 취급하므로 context file, terminal command, file operation이 해당 checkout을 따릅니다.
Assignment가 끝나도 review와 integration이 마무리될 때까지 branch를 유지합니다. Worktree를 제거해도 branch는 자동으로 삭제되지 않습니다.
4. Hermes automatic worktree mode 사용하기
Hermes는 session용 isolated branch와 worktree를 자동으로 만들 수 있습니다.
hermes -w -z "Implement the assigned change, run tests, and commit it"
Independent worker마다 terminal을 따로 여세요. Automatic mode는 one-off assignment에 편합니다. Orchestrator가 handoff와 반복 검사를 위해 안정적인 named directory를 요구한다면 manual worktree가 더 다루기 쉽습니다.
Child task에는 repository path, branch 또는 worktree, 허용된 file scope, acceptance criteria, 정확한 test command를 넣어야 합니다. Child는 conversation history가 없으므로 “방금 이야기한 bug를 고쳐라” 같은 지시는 충분하지 않습니다.
5. Summary를 믿지 말고 handoff 검토하기
Worker의 final message는 summary이지 증거가 아닙니다. Integration checkout에서 branch를 병합하기 전에 살펴봅니다.
git diff --stat main..agent/docs
git diff --name-only main..agent/docs
git diff --check main..agent/docs
git log --oneline main..agent/docs
Changed file을 assignment와 비교합니다. 핵심 edit를 읽고 branch에서 project test를 실행하세요. 관련 없는 변경이나 dirty worktree가 있으면 integration 전에 되돌려야 합니다.
Branch가 같은 file을 건드린다면 parallel execution으로 research 시간을 줄일 수는 있어도 merge는 독립적이지 않습니다. 한 명의 owner가 맡은 integration checkout에서 overlap을 해결하세요.
6. 순서대로 병합하고 정리하기
검토된 branch를 integration branch에서 병합합니다. 독립적으로 통과한 branch도 서로 영향을 줄 수 있으므로 모든 merge가 끝난 뒤 full test suite를 실행합니다.
Integration을 마치면 worktree를 제거하고 branch 보존 여부를 결정합니다.
git worktree remove ../project-docs
git worktree remove ../project-tests
git branch -d agent/docs
git branch -d agent/tests
Git은 uncommitted change가 있는 worktree를 강제 옵션 없이 제거하지 않습니다. 이 거부를 safety signal로 받아들이세요. 자동으로 우회하지 말고 directory를 살펴봐야 합니다.
Delegation은 durable queue가 아닙니다. 소유 process를 닫으면 child가 취소되거나 고립될 수 있습니다. 예약된 durable work에는 Cron을, 지속적인 multi-agent dependency에는 Kanban을 사용합니다. Worktree가 해결하는 문제는 mutable checkout isolation이지 orchestration durability가 아닙니다.
7. Isolation contract 테스트하기
예제 디렉터리에서 fixture test를 실행합니다.
python3 -m unittest discover -s tests -v
Suite는 두 isolated branch, 정확한 changed file, clean integration, commit count, 비어 있지 않은 target workspace 거부를 검사합니다. Repository behavior를 mock하지 않고 실제 Git command를 사용합니다.
Fixture는 disjoint file을 배정해 merge conflict를 피합니다. Production work에는 review policy, branch ownership, conflict handling, final test run이 여전히 필요합니다. 11편에서는 이 handoff를 durable Hermes Kanban board에 올립니다.
답글 남기기