2026. 7. 7.

Git 커밋 전 .env가 보일 때, push 전에 빼는 순서

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

4 min read
Git 커밋 전 .env가 보일 때, push 전에 빼는 순서 대표 이미지

AI가 만든 웹 프로젝트에서 git status를 봤는데 .env, .env.local, service-role, API_KEY 같은 파일이나 줄이 보이면 push는 멈춰야 합니다. 이 문제는 Git 사용법만의 문제가 아닙니다. 배포 키, 결제 키, 데이터베이스 URL이 공개 저장소에 올라가면 나중에 파일을 지워도 이미 노출된 값은 안전하다고 볼 수 없습니다.

오늘 목표는 겁을 주는 것이 아니라 push 전 5분 안에 판단을 끝내는 것입니다. 먼저 무엇이 staged에 들어갔는지 보고, 비밀값을 인덱스에서 빼고, 다음 커밋부터 다시 섞이지 않게 막습니다. 이미 원격에 올라갔다면 삭제보다 키 재발급이 먼저입니다.

Git push 전에 .env 노출 여부를 상태 확인, staged diff, 인덱스 제거, ignore 규칙으로 나누는 흐름

git-scm.com의 gitignore 문서는 ignore 패턴이 의도적으로 추적하지 않을 파일을 지정한다고 말합니다. 중요한 경계가 있습니다. 이미 Git이 추적하는 파일은 나중에 .gitignore에 적어도 자동으로 추적 해제되지 않습니다. 그래서 .env가 보일 때의 첫 행동은 .gitignore 편집이 아니라 지금 Git이 그 파일을 어떤 상태로 보고 있는지 확인하는 일입니다.

git status에서 파일 상태를 먼저 네 가지로 나눕니다

터미널에서 먼저 현재 상태를 봅니다.

git status

초보자는 여기서 파일 이름만 보고 .gitignore에 넣으면 되겠지라고 판단하기 쉽습니다. 하지만 상태가 다르면 다음 명령도 달라집니다.

보이는 상태의미먼저 할 일
Untracked files 아래 .env아직 커밋 후보가 아님.gitignore에 추가하고 add하지 않음
Changes to be committed 아래 .env이미 staged에 올라감git restore --staged .env로 staged에서 뺌
modified: .env이미 추적 중인 파일이 바뀜git rm --cached .env를 검토
이미 GitHub에 push함원격 기록에 값이 노출됐을 수 있음키 재발급이나 폐기를 먼저 진행

이 표에서 가장 흔한 실수는 staged 상태를 놓치는 것입니다. Changes to be committed 아래에 .env가 있으면 다음 commit에 들어갑니다. push 전이라면 아직 막을 수 있습니다.

Git 상태별로 untracked, staged, tracked, already pushed를 나누고 대응 명령을 고르는 체크리스트

commit 전에는 staged diff에서 키 모양을 직접 봅니다

git status가 파일 목록을 보여 준다면, git diff --staged는 다음 커밋에 들어갈 실제 줄을 보여 줍니다. git-scm.com의 git diff 문서는 --staged가 staged 변경과 마지막 커밋을 비교한다고 설명합니다.

git diff --staged

여기서 아래 같은 줄이 보이면 그대로 commit하지 않습니다.

+ DATABASE_URL=postgres://...
+ OPENAI_API_KEY=sk-...
+ SUPABASE_SERVICE_ROLE_KEY=...
+ GITHUB_TOKEN=...

실제 키 전체를 화면에 오래 남기거나 AI 채팅에 붙이지 마세요. 필요한 것은 값 자체가 아니라 키 이름과 파일 상태입니다. 예를 들어 .env.localOPENAI_API_KEY가 staged에 들어갔다는 사실이면 충분합니다.

이미 커밋 전 점검 글을 본 적이 있다면 AI 코드 저장 전, 바뀐 파일과 위험 변경을 먼저 보는 기준의 파일 범위 확인과 같이 보면 좋습니다. 이번 글은 그중에서도 비밀값만 따로 멈추는 Git 루틴입니다.

staged에만 올라간 .env는 먼저 staged에서 뺍니다

아직 commit하지 않았다면 먼저 staged에서만 뺍니다.

git restore --staged .env
git restore --staged .env.local

이 명령은 보통 파일 자체를 지우려는 목적이 아닙니다. 다음 커밋 후보에서 빼려는 목적입니다. 그다음 .gitignore에 비밀값 파일을 추가합니다.

.env
.env.local
.env.*.local

다시 상태를 확인합니다.

git status
git diff --staged

git diff --staged에 비밀값 줄이 없어야 합니다. 여기까지 확인해야 push 전 점검이 끝납니다. .gitignore를 썼다는 사실보다 staged diff가 깨끗한지가 더 중요합니다.

이미 추적 중인 파일이면 git rm --cached를 구분해서 씁니다

문제가 조금 더 복잡한 경우도 있습니다. .env가 예전 커밋부터 Git에 들어가 있으면 .gitignore를 추가해도 계속 추적됩니다. 이때는 작업 폴더의 파일은 남기고 Git 인덱스에서만 제거해야 합니다.

git rm --cached .env

git-scm.com의 git rm 문서는 --cached가 인덱스에서만 제거하고 작업 트리 파일은 남기는 방식이라고 설명합니다. 그래서 이 명령은 파일을 컴퓨터에서 삭제하는 명령과 다릅니다. 하지만 초보자라면 바로 실행하기 전에 현재 상태를 AI에게 물어보는 편이 안전합니다.

상황:
.env가 Git에 이미 추적되는 것 같습니다.

확인한 출력:
[git status 결과에서 .env가 보이는 줄]
[git diff --staged에서 비밀값은 가리고 키 이름만 남긴 줄]

원하는 결과:
로컬 .env 파일은 유지하고, 다음 커밋부터 Git 추적에서는 빼고 싶습니다.

요청:
실행할 명령을 한 번에 하나만 제안해 주세요.
git rm --cached가 맞다면 파일이 로컬에서 삭제되는지 여부도 설명해 주세요.
Git 비밀값 문제를 AI에게 물을 때 status, staged diff, 원하는 결과, 명령 하나만 요청하는 프롬프트 카드

AI에게 줄 때도 실제 키 값은 지웁니다. 키 값 대신 [가림]이라고 적습니다. Git 충돌 표시가 떴을 때, 남길 줄과 버릴 줄을 가르는 법에서처럼 AI에게 맡길 자료는 전체 파일이 아니라 판단에 필요한 구간이어야 합니다.

이미 push했다면 삭제보다 키 교체가 먼저입니다

가장 중요한 경계는 이미 원격 저장소에 push한 뒤입니다. docs.github.com의 민감정보 제거 문서는 비밀값이 저장소에 커밋됐다면 먼저 해당 비밀값을 폐기하거나 재발급해야 한다고 안내합니다. 저장소 기록을 고치는 일은 영향이 크고, 복제본이나 캐시까지 모두 통제한다고 볼 수도 없습니다.

따라서 이미 push했다면 순서를 바꿉니다.

  1. 해당 서비스에서 키를 폐기하거나 새 키로 교체합니다.
  2. 애플리케이션과 배포 환경변수를 새 값으로 바꿉니다.
  3. 저장소에서 파일을 제거하고 ignore 규칙을 추가합니다.
  4. 필요하면 GitHub의 민감정보 제거 절차나 저장소 관리자에게 기록 정리를 요청합니다.

docs.github.com의 secret scanning 설명처럼 GitHub는 지원되는 비밀값 형식을 감지하고 경고하거나 push protection으로 막을 수 있는 경우가 있습니다. 하지만 이 기능을 로컬 검토의 대체물로 보면 안 됩니다. 지원되지 않는 형식, 개인 서버 키, 수업용 토큰, .env에 직접 넣은 임시 값은 빠질 수 있습니다.

마지막 push 전에는 세 줄만 다시 확인합니다

수정이 끝났다면 마지막으로 아래 세 줄을 봅니다.

git status
git diff --staged
git log --oneline -n 3

git status에서는 .env가 commit 후보에 없어야 합니다. git diff --staged에는 비밀값 이름이나 값이 없어야 합니다. 최근 커밋 메시지는 내가 의도한 변경을 설명해야 합니다.

그다음에야 push합니다.

git push origin main

브랜치 이름이 다르면 현재 브랜치에 맞게 바꿉니다. 오늘 기억할 기준은 단순합니다. .env가 보이면 push가 아니라 상태 확인입니다. staged diff에서 비밀값이 보이면 빼고, 이미 push했다면 파일 삭제보다 키 교체를 먼저 합니다. 이 순서만 지켜도 AI 코딩 프로젝트에서 가장 비싼 Git 실수 하나를 줄일 수 있습니다.

참고 출처

다음으로 읽을 기사

같은 흐름으로 이어 읽기 좋은 기사만 추려 보여줍니다.

댓글 0

이 글을 읽은 독자들의 생각을 나눠보세요.

비밀번호(선택)

첫 번째 댓글을 남겨보세요

여러분의 생각이 다른 독자에게 도움이 됩니다.