TAG

#git

같은 태그로 묶인 기사 아카이브입니다.

2026. 7. 16.

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

2026. 7. 10.

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

2026. 7. 10.

Vercel에서 배포 성공을 봤는데 공개 도메인에는 예전 화면이 남아 있다면 코드를 다시 고치기 전에 Git commit, Deployment, Production 도메인, 깨끗한 브라우저 화면을 순서대로 연결해 보세요.

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. 7.

로컬에서는 통과하는데 Vercel 배포에서만 Module not found가 뜰 때, npm 재설치 전에 파일명 대소문자와 Git 추적 상태를 3분 안에 확인하는 순서입니다.

2026. 6. 19.

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

2026. 6. 18.

AI 코딩 도구가 만든 코드가 실행되는 것처럼 보여도 바로 저장하지 말고, 변경 파일과 diff, 요구사항 일치 여부를 3분 안에 확인해야 합니다.

2026. 6. 17.

AI 코딩 도구가 고친 코드를 붙였더니 화면이나 빌드가 더 망가졌다면, 다시 고쳐달라고 하기 전에 diff를 보고 한 파일만 되돌리는 3분 루틴이 필요합니다.