.gitignore 기본 사용법

.gitignore 기본 사용법에서 먼저 볼 부분

.gitignore는 Git이 추적하지 않을 파일과 폴더를 정하는 설정 파일입니다. 임시 파일, 설치 폴더, 환경 변수 파일을 제외할 때 사용합니다.

Git은 기본적으로 변경된 파일을 추적하려고 합니다. 하지만 모든 파일을 저장소에 올리는 것이 좋은 것은 아닙니다. 설치된 패키지, 빌드 결과, 개인 설정 파일은 다시 만들 수 있거나 민감한 정보를 담을 수 있습니다.

.gitignore는 저장소 루트에 두는 경우가 많습니다. 파일 이름이나 폴더 이름을 적어두면 Git이 해당 항목을 새로 추적하지 않습니다.

이미 Git이 추적 중인 파일은 .gitignore에 추가해도 바로 제외되지 않을 수 있습니다. 이때는 추적 상태를 따로 제거해야 하므로, 프로젝트 초반에 .gitignore를 먼저 준비하는 것이 좋습니다.

환경 변수 파일에는 API 키나 비밀번호가 들어갈 수 있습니다. 이런 파일은 절대 공개 저장소에 올리지 않는다는 기준을 처음부터 잡아야 합니다.

기본 .gitignore 예시

# 설치된 패키지
node_modules/

# 환경 변수
.env
.env.local

# 빌드 결과
dist/
build/

# 운영체제 임시 파일
.DS_Store

이 예제는 그대로 복사해서 확인하는 것보다 한 줄씩 바꿔보는 쪽이 더 도움이 됩니다. 태그 이름, 선택자, 변수 이름, 함수 실행 위치를 조금씩 바꾸면 어떤 부분이 결과에 영향을 주는지 직접 확인할 수 있습니다.

잘못 작성했을 때 나타나는 흐름

Git 글은 명령어를 외우기보다 작업 전 상태, 기록할 파일, 원격 저장소 반영 순서로 나누어 보는 것이 좋습니다.

문제가 생겼을 때는 먼저 현재 브랜치와 변경 파일을 확인하고, 그다음 커밋 또는 원격 상태를 확인하는 순서가 안전합니다.

GitHub와 배포 글은 설정 화면과 DNS가 함께 얽히므로 한 번에 여러 설정을 바꾸기보다 하나씩 확인하는 편이 좋습니다.

브라우저에서 직접 확인하는 순서

먼저 화면에 나타나는 결과를 보고, 그다음 코드에서 방금 수정한 부분을 확인하세요. 결과가 예상과 다르다면 콘솔 오류, 파일 경로, 선택자 이름, 태그 닫힘, 실행 순서 중 하나가 흔한 원인입니다.

초보 단계에서는 정답 코드를 한 번에 외우기보다 실패한 코드와 수정한 코드를 나란히 비교하는 방식이 좋습니다. 이 글의 예제를 기준으로 작은 값을 바꿔보면 다음 글을 읽을 때도 기준이 더 선명해집니다.

실습 후 점검할 항목

• node_modules 같은 설치 폴더 제외하기
• .env 파일을 저장소에 올리지 않기
• 빌드 결과물이 필요한지 확인하기
• 이미 추적 중인 파일은 별도로 추적 해제하기