Git worktree는 코딩 에이전트의 격리 경계가 아닙니다

git init -q --initial-branch=main hook-democd hook-demogit commit -q --allow-empty -m initgit branch agent-workgit worktree add -q ../hook-agent agent-work
#

worktree 내부에서는 부모의 `.git/config` 파일을 작성합니다.

마지막 두 줄에 주목하세요. 이것은 에이전트의 커밋이 아닙니다. 그것은 당신의 저장소에 있는 것이며, 다른 무언가가 선택한 작성자 라인을 가지고 있습니다.

### 또 다른 worktree의 stash 사용하기

저장소당 하나의 `refs/stash`가 존재하며, 이는 조정되지 않은 작가들 사이에 공유되는 단일 스택처럼 작동합니다:

한 가지 세부 사항이 핵심적이며, 이것이 이 레포지토리를 떠돌아다니는 일부 버전들이 작동하지 않는 이유입니다: `file.txt`는 브랜치가 생성되기 *전에* 커밋되므로, 두 worktree 모두에서 추적됩니다. 일반적인 `git stash`는 추적되지 않은 파일을 무시하므로, 완전히 새로운 파일에 대해서는 `No local changes to save`를 출력하고, 아무것도 스태시하지 않으며, `pop`은 `No stash entries found`로 실패합니다. 추적된 파일을 사용하거나 `git stash -u`를 사용하세요.

### 형제(sibling) 아래의 refs 재작성하기

모든 worktree는 하나의 `refs/heads`와 하나의 객체 저장소에 작성합니다. `git gc`를 실행하는 에이전트는 부모를 포함하여 전체 저장소에 대해 이를 실행합니다. 브랜치를 강제로 업데이트하거나, 리베이스(rebase)하거나, `git reset --hard`를 사용하는 에이전트가

다른 worktree가 참조하는 ref를 변경하며, 한 에이전트가 버린 커밋은 다른 에이전트의 눈앞에서 참조되지 않은 채 방치될 수 있습니다. 이것들은 특이한 명령어가 아닙니다. 무언가가 혼란에 빠져 정리 정돈을 하려고 할 때 손대는 것들입니다.

### 브랜치 이름 충돌

공유되는 ref는 또한 git이 두 worktree에서 동일한 브랜치를 거부한다는 것을 의미합니다:

`$ git worktree add ../probe mainPreparing worktree (checking out 'main')fatal: 'main' is already used by worktree at '/path/to/repo'`

나머지 부분에 비하면 무해하지만, 사람들이 부딪히는 첫 번째 장벽이며, 그 때문에 사람들은 단순히 git을 만족시키기 위해 worktree당 임시 브랜치를 생성하도록 강요받습니다.

## 문제를 해결하지 못하는 수정 방안들

이 주제가 논의될 때마다 두 가지 완화책이 제시됩니다. 둘 다 효과가 없습니다.

**worktree별 설정.** `extensions.worktreeConfig`

은 기본적으로 비활성화되어 있으며, 이를 켜는 것은 작성자가 `git config --worktree`를 선택적으로 사용할 경우에만 도움이 됩니다. 단순히 `git config`는 특별히 주의하지 않는 것이 실행하는 것인데도 여전히 공유 파일을 작성합니다:

**훅(hooks)을 .git에서 분리하기.** 이 방법은 순환적입니다.

`core.hooksPath`는 설정이며, 설정은 공유되므로 worktree가 원하는 곳으로 가리킵니다:

`--separate-git-dir`도 같은 방식으로 실패합니다. `.git`을 재배치하며, 모든 worktree는 여전히 그것이 재배치된 곳의 내용을 공유합니다.

세 가지 모두 행동하려는 작가에게 제약을 가합니다. 그 어떤 것도 worktree가 *쓸 수 있는* 것을 줄이지는 않습니다.

## 대신 clone을 사용하세요. 비용은 같습니다.

일반적인 반론은 worker별로 clone을 사용하면 히스토리를 복사한다는 것이지만, 로컬 소스의 경우 실제로 그렇게 일어나지 않습니다. 이것이 제가 이전에 잘못 알고 있던 부분이니, 여기 수치를 제시합니다.

git/git의 전체 clone(81,772 커밋, 4,828 추적 파일, 318 MB의 `.git`)을 기준으로 할 때, 작업 디렉토리(working tree)는 58 MB입니다. 각 행은 해당 로컬 소스에서 새로운 체크아웃을 생성합니다.

방법에 대한 참고 사항이 필요한데, 왜냐하면 이것이 답변을 바꾸기 때문입니다. 디스크 용량은 전체 트리에 걸친 누적 변화량으로 측정됩니다. `du`는 호출당 inode를 한 번만 계산하므로, 하드링크된 clone 자체만을 측정할 경우 실제로 추가하지 않은 바이트까지 크레딧을 받을 수 있습니다.

| 하나의 체크아웃 생성 | 벽시계 시간 (Wall time) | 추가 디스크 용량 (Disk added) | `.git` 표시 크기 (apparent size) |
|---|---|---|---|
| `git clone --no-hardlinks` | 1791 ms | 373 MB | 315 MB | 1 |
| `git clone` (local) | 982 ms | 58.9 MB | 318 MB | 1 (하드링크됨) |
| `git clone --shared` | 870 ms | 58.9 MB | 660 KB | 0 |
| `git worktree add` | 826 ms | 58.7 MB | 4 KB | 0 |

가장 아래 세 행을 보세요. 58.7 MB에서 58.9 MB, 그리고 826 ms에서 982 ms입니다. 디스크 관점에서 볼 때 이들은 동일한 작업이며, 그 수치는 소스의 58 MB 트리와 거의 정확하게 일치하는 working-tree 체크아웃을 나타냅니다. 어떤 메커니즘을 선택하든, 파일 한 복사본에 대한 비용만 지불할 뿐, 중요하지 않은 다른 것은 아무것도 아닙니다.

로컬 `git clone`은 객체를 복사하는 것이 아니라 하드링크(hardlinks)합니다. 이것이 `.git`이 318 MB를 보고하면서 실제 디스크에는 59 MB만 추가되는 이유입니다:

`$ stat -f '%i links=%l' reference/.git/objects/pack/*.pack154102172 links=2$ stat -f '%i links=%l' plain-clone/.git/objects/pack/*.pack154102172 links=2 # 동일한 inode`

오직 `--no-hardlinks`만이 복사본에 대한 비용을 지불하며, 아무도 그것을 실수로 실행하지 않습니다. 만약 로컬 clone이 히스토리를 중복한다고 가정했기 때문에 피하고 있었다면, 그렇지 않습니다.

`--shared`는 더 나아가 아무것도 복사하지 않습니다. 이 명령어는 하나의 파일만 작성합니다:

따라서 660 KB의 `.git`이 생깁니다.

이는 일반 클론의 하드링크된 318 MB와 비교했을 때의 수치입니다. 여기서 실제로 이점을 주는 속성은 히스토리 크기에 독립적이라는 점입니다: `--shared`는 소스가 얼마나 많은 히스토리를 가졌는지에 대해서는 O(1)이고, 몇 개의 파일을 체크아웃하는지에 대해서는 O(n)입니다. 테이블에서 볼 수 있듯이 체크아웃 과정이 가장 큰 영향을 미칩니다.

저는 이전에 이 포스트에서 이것을 “킬로바이트와 밀리초”의 비용이라고 설명했습니다. 이는 메타데이터에 해당되는 이야기이며, 실제 작업에는 그렇지 않습니다. 단지 `.git` 킬로바이트 몇 개와 함께 하나의 워킹 트리만 있으면, 1초도 안 되는 시간에 끝납니다.

동일한 59 MB를 가지고는 다음을 얻을 수 있습니다:

`$ cd plain-clone && git config user.zzTest x && git -C ../reference config user.zzTest# -> (not set)$ cd shared-clone && git config user.zzTest x && git -C ../reference config user.zzTest# -> (not set)$ cd worktree && git config user.zzTest x && git -C ../reference config user.zzTest# -> set-from-worktree`

| 상태 | 워킹 트리 | `--shared` 클론 |
|---|---|---|
| 오브젝트 저장소 | 공유됨 | 공유됨, alternates를 통해 |
| ... | 
둘 다 복사하기에 비용이 많이 들고 공유하기 안전한 한 가지 것을 공유합니다. 이 클론은 또한 작가(writer)가 두 명 이상일 경우 문제가 될 수 있는 다섯 가지 요소를 격리합니다.

## `--shared`가 요구하는 것

이는 오브젝트를 빌려 쓰기 때문에, 소스 오브젝트 저장소가 제자리에 남아 있어야 합니다. 따라서 아래에 있는 소스를 삭제하거나 클론이 활성화된 상태에서 소스에 공격적인 `git gc`를 실행하지 마십시오. 그렇지 않으면 클론이 여전히 참조하는 오브젝트가 제거될 수 있습니다. 나중에 독립하고 싶다면, `git clone --dissociate`가 빌려 온 오브젝트들을 복사하여 종속성을 끊어줍니다.

일반 하드링크 클론이 더 안정적이며, 그 이유는 알아두는 가치가 있습니다. 하드링크는 inode를 스스로 살아있게 유지합니다. 만약 소스가 해당 팩파일을 삭제하거나 재패킹하더라도, 클론의 링크가 데이터를 열어두기 때문입니다. `--shared`

이는 참조(reference)가 아닌 경로(path)를 담고 있기 때문에 그러한 보호 기능이 없습니다. 포기하는 것은 O(1) 속성, 영구적인 중복 제거(deduplication), 그리고 파일 시스템을 넘나들 수 있는 능력이며, 이는 작업 공간(workspaces)이 다른 볼륨에 있거나 컨테이너 내부에 바인드 마운트(bind-mounted)되는 순간 중요해지기 시작합니다.

어느 쪽도 엄격하게 더 낫다고 할 수는 없습니다. 둘 다 다르게 실패하며, 모두 참조(refs), 설정(config), 스태시(stash), 그리고 훅(hooks)을 격리합니다.

## worktree가 적절한 경우

Worktrees는 `.git` 디렉터리를 의도적으로 공유하며, 이 공유 자체가 그것이 만들어진 목적입니다:

- 한 사람이 두세 개의 브랜치 사이를 이동할 때. 모든 곳에서 브랜치, 스태시, 설정이 보이는 것이 *필요*합니다.
- 인덱스를 방해하지 않고 다른 브랜치를 빠르게 빌드하거나 테스트할 때.
- 작성자 본인만이 유일한 작성자이고 실행하기 전에 각 명령어가 무엇을 할지 알고 있는 모든 경우.