Magit의 Git 워크트리 단축키와 AI 에이전트 병렬 작업 흐름 정리

AI 에이전트 때문에 워크트리를 쓰기 시작했는데 Magit가 이렇게 잘 지원하는 줄은 몰랐음. 이제 Magit로 워크트리 관리할 생각임

나도 지금은 Jujutsu 쪽을 쓰고 있음. 한 번 써보길 권함

모노레포나 여러 브랜치를 동시에 다루면 워크트리는 사실상 필수임. 기본 흐름이 불편해서, 숨김 bare 저장소 아래에 브랜치별 디렉터리를 두는 SVN 비슷한 bash 래퍼를 만들어 씀

내 구성도 비슷한데 스크립트가 뭘 해주는지 궁금함. 브랜치가 트리 구조로 쌓이고 변경이 들어오면 위로 rebase와 merge하는데, 오래된 워크트리와 브랜치를 지우는 일만 귀찮음

워크트리에서 파일 복사 비용을 줄이려고 reflink를 쓰고 싶음. git-cow-worktree를 찾았지만 신뢰가 잘 안 감

워크트리는 기존 작업 디렉터리가 없는 bare 저장소에서도 쓸 수 있어서 복사할 원본을 정하기 어렵다고 봄. copy 명령 제안은 Git 메일링 리스트에 올려볼 만함

브랜치와 워크트리를 둘 다 머릿속으로 관리해야 해서 늘 번거롭다고 생각했음. Worktrunk를 쓴 뒤로는 항상 워크트리를 쓰게 됐고 예전 방식으로 돌아갈 생각이 없음

워크트리는 시간 낭비라고 봄. 저장소 복사본을 여러 개 두는 편이 더 단순함

나도 워크트리보다 브랜치 전환이나 전체 클론과 로컬 경로 remote를 씀. 나중에 로컬 저장소로 브랜치를 push하거나 remote로 보낼 수 있어서 더 유연하다고 느낌

그래도 워크트리는 클론보다 생성과 체크아웃이 훨씬 빠르고 디스크도 덜 씀. 한 워크트리의 커밋이 다른 곳에서 보이게 하려고 Git 내부 명령을 따로 돌릴 필요도 없음

AI가 있든 없든 같은 저장소 체크아웃을 여러 개 둬야 하는 상황 자체를 좋아하지 않음. 개발 작업 디렉터리에서 테스트를 돌리기보다 실제 실행 환경에 배포해 돌리는 쪽이 낫다고 봄

이미 다른 워크트리에 체크아웃된 브랜치를 Magit가 거절할 때, 그 워크트리로 이동하거나 다른 쪽 HEAD를 detach하겠다고 물어봐 주면 좋겠음. Magit는 좋아하지만 Elisp로 직접 고치기엔 자신이 없음

Git은 --force를 쓰면 이미 다른 워크트리에 체크아웃된 브랜치도 새 워크트리에 체크아웃할 수 있음

같은 브랜치를 여러 워크트리에 체크아웃해야 하는 경우가 뭔지는 잘 모르겠음. 원하는 건 중복 체크아웃보다 Magit가 기존 워크트리로 이동해 주는 동작일 수도 있음

copy-on-write 클론이 더 유연하고 빠르며 이해하기 쉽다고 봄. 워크트리를 편하게 만드는 도구에 시간을 쓰는 이유를 모르겠음

파일시스템 스냅샷이나 cp --reflink로 로컬 저장소를 복제한다는 뜻인지 궁금함. 에이전트에 비밀값이 노출되지 않게 하는 문제에서는, 필요한 것만 따로 넣는 워크트리 쪽이 더 마음에 듦

태스크마다 Claude Code 같은 도구가 워크트리를 만드는 방식이 손상 위험 없이 안전한지 의문임. auto-worktree 이슈에도 관련 사례가 있음

Jujutsu라면 이 문제를 해결할 수도 있다고 봄

워크트리가 필요할 때는 grm을 써서 관리 작업을 조금 줄임