git worktree error 129가 공백 경로에서 나오면 인자부터 확인한다

git worktree add가 공백이 든 경로에서 usage를 길게 출력하고 exit 129로 끝났다면, Git이 공백 경로를 지원하지 않는다고 바로 결론내리지 않는다. 같은 경로 전체를 큰따옴표로 묶어 한 인자로 전달한 raw Git 명령부터 비교한다. 이 명령이 성공하면 폴더 이름보다 셸·스크립트·GUI가 경로를 여러 인자로 나눠 전달했는지 확인해야 한다.

git worktree add "/Users/me/My Project/task worktree" -b task-test

1. usage와 exit code를 함께 기록한다

터미널에서 실패한 명령을 다시 실행한 뒤 exit code를 확인한다.

git worktree add "/Users/me/My Project/task worktree" -b task-test
echo $?

Git 공식 문법에서 add 뒤의 <path>는 하나의 인자다. 오류 문장 대신 다음과 같은 usage가 나오고 echo $?가 129라면 Git이 명령 형식을 해석하지 못한 상황부터 의심한다.

usage: git worktree add [<options>] <path> [<commit-ish>]

2. 공백 경로를 한 인자로 전달하면 되는지 비교한다

macOS 터미널에서 비민감 시험 폴더를 만든다. 아래 네 줄을 순서대로 실행하면 $repo와 $wt가 실제 공백 경로를 가리킨다.

base="$(mktemp -d)"
repo="$base/source repo"
wt="$base/work tree"
git init "$repo"

첫 커밋이 있어야 새 worktree를 만들 수 있다. 시험 파일을 하나 저장하고 커밋한다.

git -C "$repo" config user.name "Worktree Test"
git -C "$repo" config user.email "worktree-test@example.invalid"
printf 'baseline\n' > "$repo/README.txt"
git -C "$repo" add README.txt
git -C "$repo" commit -m baseline

이제 대상 경로를 큰따옴표로 묶어 실행한다.

git -C "$repo" worktree add "$wt" -b space-test

실제 결과는 exit 0이었다.

Preparing worktree (new branch 'space-test')
HEAD is now at 3fde8b8 baseline

git worktree list --porcelain에도 다음처럼 공백이 든 경로가 등록됐다.

worktree /private/tmp/seoin-s22-l0khKZ/work tree
HEAD 3fde8b85009e5626ab6abdbc240ca2fd864997bc
branch refs/heads/space-test

이 결과가 뜻하는 범위는 명확하다. 적어도 이 환경의 raw Git은 공백이 든 경로 자체를 거부하지 않았다. 모든 GUI와 Windows 환경이 같다는 뜻은 아니다.

3. Bash에서 경로가 쪼개지면 exit 129가 난다

같은 저장소에서 두 번째 대상 경로를 만들고, Bash가 공백 경로 변수를 따옴표 없이 확장하도록 실행했다.

wt2="$base/another work tree"
/bin/bash -c 'git -C "$1" worktree add $2 -b broken-bash' _ "$repo" "$wt2"
echo $?

이번에는 Git이 usage를 출력하고 exit 129로 끝났다. $wt2가 공백에서 나뉘어 <path> 하나가 아니라 여러 인자로 전달됐기 때문이다. 실패 뒤 worktree 목록에도 새 대상은 없었다.

따라서 스크립트 안의 변수는 다음처럼 큰따옴표로 묶는다.

git worktree add "$target_path" -b "$branch_name"

zsh에서는 같은 시험 결과가 달랐다

현재 zsh에서 따옴표 없는 $wt를 같은 방식으로 확장한 시험은 exit 0이었다. 셸마다 기본 단어 분리 동작이 다르므로 “따옴표가 없으면 항상 129”라고 외우면 안 된다. 실제 실행 셸과 앱이 만든 인자 배열을 확인해야 한다.

GUI에서만 실패하면 수집할 정보

1. 앱 이름과 버전을 기록한다.
2. 앱이 선택한 저장소 경로와 새 worktree 경로를 개인정보 없이 적는다.
3. 앱 로그에 실제 Git 명령 또는 인자 배열이 있으면 저장한다.
4. 같은 경로를 큰따옴표로 묶은 raw Git 명령과 결과를 비교한다.
5. raw Git도 실패하면 전체 usage 앞에 나온 첫 오류 문장과 git --version을 함께 확인한다.

Windows GUI의 실제 실패 화면과 호출 로그는 이번 회차에 확보하지 못했다. 따라서 특정 앱이 공백 경로를 잘못 처리한다고 단정하지 않는다. 현재 확인된 답은 공백 경로는 raw Git에서 성공했고, Bash에서 경로가 여러 인자로 분리됐을 때 같은 usage와 exit 129가 재현됐다는 것이다.

다른 오류 문구라면 질문을 나눈다

큰따옴표로 묶은 명령이 usage 대신 a branch named ... already exists로 끝나면 공백 경로 문제가 아니다. 기존 브랜치로 worktree를 만드는 순서처럼 -b를 빼고 기존 ref를 마지막 인자로 전달해야 한다.

fatal: invalid reference: HEAD가 나온다면 경로 인자보다 저장소 루트와 첫 커밋부터 확인한다. Codex worktree의 invalid reference HEAD 확인 순서에서 선택 폴더와 HEAD 존재 여부를 나눠 볼 수 있다.

자주 묻는 질문

exit 129면 경로에 공백이 있다는 뜻인가?

아니다. exit 129와 usage는 Git이 받은 명령 형식을 해석하지 못했다는 단서다. usage 앞에 나온 첫 오류 문장, 실제 인자 배열, Git 버전을 함께 봐야 원인을 좁힐 수 있다.

폴더 이름에서 공백을 없애면 해결인가?

임시 우회가 될 수 있지만 호출부가 인자를 잘못 조립하는 문제는 남는다. 먼저 같은 경로를 한 인자로 전달해 성공하는지 확인하고, 스크립트라면 변수를 큰따옴표로 묶는다. GUI라면 실제 호출 로그가 있을 때만 앱 원인으로 좁힌다.

검증 기준

• 마지막 업데이트일: 2026-09-20
• 주요 근거: Git 공식 git-worktree 문서
• 확인 환경: macOS, Git 2.38.1, 비민감 임시 저장소
• 정상 비교: 공백 경로 전체를 한 인자로 전달해 exit 0, worktree 등록 확인
• 실패 비교: Bash에서 공백 경로 변수를 따옴표 없이 전달해 usage와 exit 129, 신규 등록 없음
• 미확인: Windows GUI의 실제 명령 인자와 오류 화면
• 대표이미지는 실제 앱 화면이 아니라 하나로 유지된 경로 인자와 여러 조각으로 분리된 인자를 비교한 개념도다.
• 대표·공유 이미지, strict SEO92/AEO86, gpt-5.6-sol low 독립 최종검수를 통과했다. 발행 전에는 fresh 수량·보호·cadence를 다시 확인한다.