TOPIC

Git

커밋, 푸시, 충돌

2026. 7. 16.

Git detached HEAD에서 만든 커밋을 새 브랜치에 연결하고, 이미 이동했다면 reflog로 찾아 보존한 뒤 log와 status로 확인하는 순서입니다.

2026. 7. 10.

AI가 고칠 파일이 늘어나면 진행 중 작업과 섞이기 쉽습니다. Git worktree로 별도 브랜치와 폴더를 만들고, AI 수정은 그곳에서 test와 diff로 검증하는 순서를 안내합니다.

2026. 7. 9.

AI에게 코드를 맡기기 전 수정 중인 파일이 많다면 바로 요청하지 말고 git status, stash push, stash list, restore 기준을 먼저 잡아야 합니다. 현재 작업을 잃지 않고 AI 수정만 검토하는 순서입니다.

2026. 7. 7.

AI가 만든 프로젝트에서 .env나 API 키가 git status에 보이면 push 전에 staged diff, 인덱스 제거, .gitignore, 키 재발급 경계를 나눠야 합니다.

2026. 7. 7.

AI가 만든 코드를 pull하거나 merge하다가 <<<<<<< HEAD가 보이면 파일을 덮어쓰기 전에 git status, 충돌 구간, 남길 의도, 실행 확인, git add 순서로 정리해야 합니다.

2026. 7. 7.

Git merge conflict에서 <<<<<<< 표시가 보이면 AI에게 전체 파일을 맡기기 전 현재 코드, 원격 코드, 공통 목적, 검증 명령을 분리해야 합니다.

2026. 7. 2.

로컬에서는 npm test가 통과하는데 GitHub Actions에서만 실패하면 코드 전체보다 Node 버전, package.json engines, setup-node 값을 먼저 맞춰야 합니다. 3분 안에 실패 원인을 좁히는 순서입니다.

2026. 7. 2.

AI가 만든 코드가 로컬에서 돌아가도 PR 설명이 비어 있으면 리뷰가 늦어집니다. GitHub PR 설명 칸에 목적, 바뀐 파일, 테스트, 위험, 리뷰 질문을 7줄로 적는 순서를 정리합니다.

2026. 6. 19.

git push rejected나 non-fast-forward 오류가 처음 뜨면 force push부터 치지 말고 원격 변경, 내 수정, 브랜치, 충돌 가능성, AI에게 줄 정보를 3분 안에 확인해야 합니다.