빈 명령어 치환 후에도 git branch가 성공할 수 있는 이유

📝 원래 일본어로 forge.workstyle.tech에 게시되었습니다.

요약하자면, 따옴표가 없는 빈 명령어 치환은 단어 분리(word splitting)를 거치면서 사라질 수 있습니다. 이 경우 git branch 명령은 시작 지점을 생략한 채로 성공할 수 있으며, 따라서 &&는 계속해서 git reset --hard를 실행하게 됩니다. 명령어 치환에는 반드시 따옴표를 사용하고, 작업 트리를 초기화하기 전에 백업을 확인해야 합니다.

임시 저장소(disposable repository)를 사용하여 발견한 점

프로세스를 실행하기 전에 저는 임시 저장소를 사용하여 세션 중 하나를 실행해 보았습니다. 그곳에서 백업 목적지를 생성하는 부분이 실패하더라도 git branch 명령어 자체는 여전히 성공할 수 있다는 것을 알게 되었습니다.

간단히 말해, 재현 과정은 다음과 같습니다:

$ git branch orphan/x $(false)    # 종료 코드=0. 브랜치가 HEAD에 생성되어 &&를 통과함
$ git branch orphan/x "$(false)"   # fatal: Not a valid object name: '' → 중단 (종료 코드 128)

$(false)의 결과는 비어 있습니다. 따옴표로 감싸지 않으면, 그 빈 결과가 단어 분리 때문에 사라집니다. 셸에 실제로 전달되는 명령어는 단순히 git branch orphan/x입니다.

이 형태는 시작 지점이 생략된 유효한 git branch 명령으로 간주됩니다. HEAD를 가리키는 브랜치가 생성되고, 종료 코드는 0입니다. 따라서 &&가 진행되어 다음의 reset --hard가 실행됩니다.

이렇게 되면 백업이 성공한 것처럼 보이지만, 실제로는 목적지가 전혀 생성되지 않았습니다. 실제 절차에서는 실제로 백업하지 않은 채로 작업 트리의 변경 사항을 잃을 위기에 처했던 것입니다.

반면에, 이를 `

실제 위험은 변수가 빈 값으로 평가되더라도, 해당 명령이 여전히 인자(argument)가 생략된 형태의 유효한 명령어로 남아 있다는 점입니다.

이 경우, 시작 커밋을 생략하더라도 git branch는 성공합니다. 따라서 명령어가 시각적으로 거의 동일해 보일지라도, 특정 백업 커밋에서 브랜치를 분기하는 원래 의도된 동작과는 완전히 다르게 작동합니다.

유사한 주의가 필요한 다른 명령어로는 git checkout -B, git reset, 그리고 rm -rf $DIR/ 등이 있습니다. 인자가 생략되었을 때 여전히 작동하지만 의미가 달라지는 명령에, 빈 값이 될 수 있는 값을 직접 전달하면, 실패가 종료 코드(exit code)로 나타나지 않습니다.

&& 연산자는 앞선 명령이 실패할 경우 후속 명령의 실행을 막기 위한 것입니다. 하지만 그 실패가 명령어의 종료 코드에 반영되지 않는다면, 실행 흐름을 막을 것이 아무것도 없습니다. 오류 메시지가 출력되는 것만으로는 프로세스가 실제로 중단될지 알 수 없습니다.

제가 놓친 부분

이 지침들을 읽고 승인된 세션이 세 번 있었습니다. 모두가 이 결함을 놓쳤습니다. 심지어 한 사람은

• 따옴표를 사용한 명령어 치환(command substitutions)을 통해 빈 값도 인수로 유지되도록 함.
• 작업 트리를 초기화(resetting the working tree)하기 전에 백업이 성공했는지 확인하도록 함.
• 일회용 저장소(disposable repository)에서 실패 사례를 테스트할 수 있도록 함.
• 오류가 발생하면 파괴적인 후속 명령어(destructive follow-up commands) 실행을 중단하고 구체적인 이유를 보여주도록 함.

관련 기사:

• https://forge.workstyle.tech/blog/who-is-rolling-back-whom/ (누가 누구를 롤백하는가?)
• https://forge.workstyle.tech/blog/parallel-claude-code-sessions-teamwork/ (병렬 클로드 코드 세션 팀워크)
• https://forge.workstyle.tech/blog/root-cause-over-band-aid-debugging/ (임시방편 디버깅보다 근본 원인 분석)