재밌는 Coding

1. 시험환경 (Environment)

◎ OS: Ubuntu (v.22.04)
◎ Platform: GitHub
◎ Tool: ssh-keygen

2. 문제 인식 (Problem)

◎ 완성된 프로젝트를 실제 서비스하기 위해 AWS EC2나 온프레미스 우분투(Ubuntu) 서버에 접속하고, 이곳에 GitHub 코드를 다운로드(git pull) 받으려면 권한 인증이 필요하다.

◎ 이때 윈도우 로컬 PC에서 하던 것처럼 우분투 서버 터미널에 내 '개인 GitHub 계정(ID/PW 또는 Personal Access Token)'을 직접 입력하여 로그인하는 것은 보안상 매우 위험한 행동이다.

3. 원인 분석 (Cause)

◎ 이러한 문제가 발생하는 원인은 서버 환경과 로컬 환경의 성격이 다르기 때문이다. 로컬 PC는 '나 혼자' 쓰는 공간이지만, 배포 서버는 여러 개발자가 함께 접속하는 '공용 공간'이기 때문이다.

◎ 공용 서버가 만약 해킹이라도 당한다면 서버에 연동된 내 개인 계정의 모든 프라이빗 저장소(Repository) 코드까지 전부 유출되는 2차 피해가 발생할 수 있다.

◎ 따라서 배포 서버에는 내 전체 계정 권한을 주는 것이 아니라, '현재 서비스할 딱 하나의 저장소(Repository)'에만 접근할 수 있는 서버 전용 열쇠(독립된 권한)를 발급해주어야 한다.

4. 해결방법 (Solution)

1) 서버에서 SSH 키 쌍(비밀키-공개키) 생성

  ① 우분투 터미널을 열고 키를 보관할 폴더에서 ssh-keygen 명령어를 실행한다.

ssh-keygen  -t  ed25519  -a  100  -f  [key명]

    - ed25519는 기존 RSA 방식보다 성능과 보안이 뛰어난 최신 알고리즘이다.

    - 명령어 실행 후 비밀번호(passphrase)를 묻는 프롬프트가 나오면, 자동 배포를 위해 엔터를 두 번 눌러 생략한다.

    - 생성이 완료되면 비밀키 파일과 공개키(.pub) 파일 2개가 생성된다.

2) 웹 브라우저 GitHub에서 설정

  ① 권한을 부여할 대상인 GitHub 프로젝트 저장소로 이동한 뒤, 상단 탭의 Settings 메뉴를 클릭한다.

  ② 좌측 사이드바 메뉴에서 Deploy keys를 클릭하고, 우측 상단의 Add deploy key 버튼을 클릭한다.

  ③ 우분투에서 생성한 2개의 파일 중 반드시 공개키(.pub 확장자)의 내용을 cat 명령어로 출력하여 전체 복사한다.

# 명령어(서버에서 실행)
cat  [SSH_key명].pub

    - 복사한 ssh-ed25519로 시작하는 긴 텍스트를 GitHub의 Key 입력란에 그대로 붙여넣는다.

    - Title에 'Ubuntu-Production-Server'처럼 알아보기 쉬운 이름을 적고 Add key를 눌러 저장한다.

5. 요약 및 마무리 (Summary)

◎ 설정이 완료되면 우분투 서버는 내 개인 계정 로그인 없이도 SSH 주소를 통해 해당 저장소의 코드를 Pull 받을 수 있다.

◎ 이처럼 Deploy Key(배포 키)를 활용하면 서버에 개인 계정을 노출하지 않으면서도 특정 Repository를 안전하게 연결할 수 있다. 이는 실무에서 CI/CD(지속적 통합/배포) 자동화 파이프라인을 구축할 때 반드시 거쳐야 하는 필수 보안 세팅이다.

1. 시험환경 (Environment)

◎ OS: Windows 11 / macOS
◎ Version Control: Git
◎ Platform: GitHub / GitLab / Bitbucket
◎ Terminal: VS Code Terminal / bash / PowerShell

2. 문제 인식 (Problem)

◎ 실무에서 다수의 개발자가 참여하는 대규모 프로젝트 저장소(Repository)를 내 PC로 복제(git clone)할 때, 다운로드 시간이 너무 오래 걸리거나 디스크 용량을 과도하게 차지하는 문제가 발생할 수 있다.

◎ 나는 오직 develop 브랜치나 특정 기능 개발용 브랜치(feature/login) 코드만 확인하고 당장 작업을 시작하면 되는데, 불필요한 다른 팀원들의 작업 브랜치 수백 개까지 전부 다운로드받으면서 시간을 낭비하게 된다.

3. 원인 분석 (Cause)

◎ 이러한 리소스 낭비가 발생하는 원인은 기본 명령어인 git clone [주소]의 동작 방식 때문이다.

◎ Git은 기본적으로 저장소를 복제할 때, 단순히 메인 브랜치의 파일만 가져오는 것이 아니라 원격 저장소에 존재하는 '모든 브랜치'와 수년 치의 '전체 커밋 히스토리'를 통째로 내 PC로 다운로드한다. 파일 크기가 크거나 히스토리가 깊은 프로젝트일수록 이 기본 동작은 비효율적이다.

4. 해결방법 (Solution)

1) 단일 브랜치 Clone 명령어 구조

  ① 터미널을 열고 아래와 같은 구조로 명령어를 입력한다.

    - 옵션 --branch feature/payment : 복제할 타겟 브랜치의 이름 지정 (단축 명령어 -b로 쓸 수도 있다.)

    - 옵션 --single-branch : 지정한 브랜치의 히스토리만 단독으로 가져옴 (다운로드 속도와 용량을 줄여준다.)

    - 옵션 . (마침표) : 새로운 폴더를 생성하지 않고, 터미널이 열려있는 '현재 폴더'에 파일들을 복제

git clone --branch [브랜치명] --single-branch [저장소주소] .

2) 실무 적용 예시

  ①  myservice-frontend 저장소에서 feature/payment 브랜치만 현재 폴더에 복제하려면 아래와 같이 입력한다.

# 1. 새로운 빈 폴더를 만들고 진입합니다.
mkdir payment-test && cd payment-test

# 2. 특정 브랜치만 현재 폴더(.)에 복제합니다.
git clone --branch feature/payment --single-branch https://github.com/myservice-frontend.git .

5. 요약 및 마무리 (Summary)

◎ --branch 옵션과 --single-branch 옵션을 조합하여 내가 정확히 원하는 단 하나의 브랜치만 콕 집어서 복제하는 방법을 사용하였다.

◎ Clone 명령어를 최적화하는 방식을 비교하면 다음과 같다.

1. 시험환경 (Environment)

◎ OS: Windows 11 / macOS
◎ Version Control: Git
◎ Platform: GitHub
◎ Terminal: VS Code Terminal / bash / PowerShell

2. 문제 인식 (Problem)

◎ 이전 포스팅에서 진행 중이던 프로젝트를 git remote add origin 명령어로 GitHub에 연결하는 정석적인 방법을 알아보았다. 하지만 Git에 익숙하지 않은 경우 이 과정이 복잡해 보일 수 있다.

  - 참고 URL : 

◎ 특히 GitHub에서 Repository를 생성할 때 무심코 README.md 생성 옵션에 체크를 한 경우, 내 PC의 코드와 GitHub의 초기 파일 상태가 달라서 Push 할 때 충돌(Merge Conflict) 에러가 발생하는 경우가 많다.

◎ 복잡한 에러 해결 과정 없이, 직관적이고 확실하게 내 코드를 GitHub에 등록하는 쉬운 방법을 알아보자.

3. 원인 분석 (Cause)

◎ 이러한 충돌이 발생하는 원인은 내 PC의 로컬 .git 기록과 GitHub에 새로 만들어진 원격 저장소의 초기 기록이 서로 달라서 병합을 거부하기 때문이다.

◎ 이러한 경우 복잡하게 두 기록을 억지로 연결(remote add)하려고 애쓰지 말자. 발상을 전환하여 GitHub과 완벽하게 연결된 '깨끗한 새 폴더'를 내 PC에 먼저 만들어 두고, 그 안에 기존에 작업하던 파일들을 물리적으로 복사해서 덮어씌우는 방식을 사용하면 충돌 원인을 원천 차단할 수 있다.

4. 해결방법 (Solution)

① GitHub에 로그인하여 우측 상단의 New 버튼을 눌러 새로운 저장소를 생성한다.

  - 이 방법은 README.md를 포함해서 생성해도 아무런 문제가 없다.

  ② Local PC에서 앞으로 사용할 새로운 프로젝트 폴더(예: MyNewProject)를 새로 만든다.

  ③ 새로 만든 빈 폴더에서 터미널을 열고, GitHub 저장소의 코드를 그대로 내려받아(Clone) 연결을 설정한다.

# 주의: 명령어 맨 뒤에 띄어쓰기를 하고 마침표(.)를 반드시 찍어야 합니다!
# 점(.)을 찍어야 새로운 하위 폴더를 만들지 않고 현재 폴더에 깔끔하게 복제됩니다.
git clone [자신의-github-repository-주소] .

  ④ 기존에 작업하고 있던 원래 프로젝트 폴더 안의 모든 파일과 소스 코드를 복사(Ctrl+C)하여, 방금 clone 명령어를 실행했던 '신규 프로젝트 폴더' 안에 그대로 붙여넣기(Ctrl+V) 한다.

  ⑤ 파일 덮어쓰기가 완료되었다면, 신규 폴더의 터미널에서 변경된 내용을 GitHub로 최종 업로드한다.

# 1. 복사해 온 모든 파일을 Git의 추적 목록에 추가
git add .

# 2. 첫 번째 작업 내역을 커밋으로 기록
git commit -m "initial commit: 기존 프로젝트 파일 이관"

# 3. GitHub 원격 저장소로 밀어 올리기
git push

  ⑥ GitHub에 프로젝트가 등록 되었는지 확인한다.

5. 요약 및 마무리 (Summary)

◎ 이 방법은 Git 명령어와 에러 대처에 익숙하지 않은 경우 확실한 해결책이다. 로컬 커밋 기록이 날아간다는 단점이 있지만, 프로젝트를 안전하게 GitHub에 등록하고 새 출발을 하고 싶을 때 매우 유용하게 사용할 수 있다.

1. 시험환경 (Environment)

◎ OS: Windows 11 / macOS
◎ Version Control: Git
◎ Platform: GitHub
◎ IDE: Visual Studio Code
◎ Terminal: bash / zsh / PowerShell

2. 문제 인식 (Problem)

◎ GitHub에서 새로운 원격 저장소(Repository)를 생성하면 화면에 복잡한 터미널 명령어들을 제공한다.

◎ 막 폴더를 생성한 '완전한 빈 프로젝트'인지, 아니면 며칠 동안 이미 코드를 작성하며 로컬 커밋을 남겨둔 '진행 중인 프로젝트'인지에 따라 입력해야 할 Git 명령어의 순서와 종류가 완전히 달라진다. 상황에 맞지 않는 명령어를 무작정 복사해서 붙여넣으면 기존의 Git 기록이 망가지는 문제가 발생할 수 있다.

3. 원인 분석 (Cause)

◎ 두 상황의 명령어 흐름이 달라지는 근본적인 원인은 내 PC(로컬 폴더)에 Git 초기화(.git 폴더 생성)가 되어 있는가의 여부 때문이다.

◎ 아무것도 없는 빈 프로젝트는 Git의 추적을 처음 시작(git init)하고 첫 번째 커밋을 만드는 과정부터 전부 수행해야 한다.

◎ 반면, 이미 로컬에서 자체적으로 커밋을 쌓아가며 진행 중이던 프로젝트는 앞선 과정을 모두 건너뛰고, GitHub의 원격 저장소 주소(Remote)를 내 PC에 연결하여 코드 기록을 밀어 올리는(Push) 작업만 수행하면 된다.

4. 해결방법 (Solution)

1) 완전한 빈 프로젝트를 새로 시작할 때

  ① 아직 git init조차 하지 않은 텅 빈 폴더에서 시작하는 경우이다. 파일을 만들고, Git을 초기화한 뒤 GitHub에 연결한다.

# 1. 로컬 저장소 초기화 (Git 추적 시작, .git 폴더 생성)
git init

# 2. 파일 상태를 Staging에 올리고 첫 커밋 생성
git add .
git commit -m "first commit"

# 3. 기본 브랜치 이름을 master에서 main으로 변경
git branch -M main

# 4. GitHub 원격 저장소 주소를 'origin'이라는 이름으로 연결
git remote add origin https://github.com/계정명/저장소명.git

# 5. 원격 저장소로 푸시 (-u 옵션은 향후 git push만 쳐도 되게끔 기본 경로를 설정함)
git push -u origin main

2) 이미 진행 중인 프로젝트를 연결할 때

  ① Vite나 Create React App(CRA)으로 프로젝트를 생성했거나, 이미 로컬에서 git add와 git commit을 하면서 자체적으로 개발을 진행해 오던 경우이다.

# (이미 내 PC에 커밋 기록이 존재하므로 init과 commit 과정은 생략합니다.)

# 1. 원격 저장소 주소를 'origin'이라는 이름으로 연결
git remote add origin https://github.com/계정명/저장소명.git

# 2. 기본 브랜치 이름을 main으로 확실히 지정 (선택적이나 권장)
git branch -M main

# 3. 그동안 쌓인 로컬 커밋 내역을 GitHub로 밀어 올림
git push -u origin main

5. 요약 및 마무리 (Summary)

◎ 프로젝트 상황에 따른 초기 연결 명령어의 차이는 다음과 같다.

1. 시험환경 (Environment)

◎ OS: Windows 11 / macOS
◎ Version Control: Git
◎ IDE: Visual Studio Code
◎ Terminal: bash / zsh / PowerShell

2. 문제 인식 (Problem)

◎ 프로젝트를 GitHub에 올리기 전, 중요한 API 키가 담긴 .env 파일이나 용량이 너무 큰 node_modules 폴더를 제외하기 위해 .gitignore 파일에 해당 이름들을 작성해 넣었다.

◎ 그런데 터미널에 git status를 입력해 보면, 분명 .gitignore에 추가한 파일들임에도 여전히 '수정됨(modified)' 상태로 커밋 대기 목록에 나타나는 상황이 발생한다. 아무리 .gitignore 파일을 껐다 켜고 다시 저장해도 Git은 이 파일들을 계속 추적하고 있다.

3. 원인 분석 (Cause)

◎ 이러한 현상이 발생하는 근본적인 원인은 .gitignore 파일의 동작 원리 때문이다.

◎ .gitignore는 Git이 '아직 추적하지 않은 새로운 파일(Untracked files)'에 대해서만 무시하라는 명령어이다.
만약 .gitignore에 파일명을 적기 전에 실수로라도 한 번 git add .를 했거나 이미 커밋을 해버렸다면, Git은 이미 그 파일을 자신의 메모리(캐시, Index)에 등록하여 '추적 중(Tracked)'인 상태로 만든다.

◎ Git의 입장에서는 "이 파일은 예전부터 내가 관리하던 파일인데, 이제 와서 무시하라고? 이미 늦었어!"라며 .gitignore의 명령을 거부하고 계속 변경 사항을 추적한다.

4. 해결방법 (Solution)

1) Git 캐시 전체 삭제 (로컬 파일은 보존)

  ① 터미널을 열고 아래 명령어를 입력한다.

    - 옵션 -r : 폴더 안의 하위 경로까지 모두(recursive) 적용한다는 의미

    - 옵션 --cached : 내 PC의 실제 물리적 파일은 지우지 말고, 오직 Git의 추적(캐시)만 지우라는 옵션

git rm -r --cached .

실행 결과: 터미널에 rm '파일명' 문구가 수백 개씩 올라갑니다. (실제 파일이 지워진 것이 아니라 Git의 추적 목록에서만 빠진 것이니 안심하셔도 됩니다.)

2) 파일 다시 추가 (Staging)

  ① 이제 Git의 캐시가 비었으므로, 현재 프로젝트 파일들을 다시 "Staging Area"로 올린다. 이때 새롭게 적용된 .gitignore의 규칙이 적용되어 불필요한 파일들은 제외하고 추가된다.

git add .

3) 변경 사항 커밋

  ① 캐시를 정리하고 새롭게 .gitignore를 적용한 상태를 커밋하여 확정한다.

git commit -m "chore: Git 캐시 삭제 및 .gitignore 재적용"

5. 요약 및 마무리 (Summary)

◎ .gitignore가 작동하지 않을 때의 상황과 해결책을 요약하면 다음과 같다.

  - 원인: 이미 Git이 추적(Track)을 시작한 파일은 뒤늦게 .gitignore에 추가해도 무시되지 않음

  - 해결책: git rm -r --cached . 명령어로 PC의 원본 파일은 살려둔 채 Git 캐시만 초기화 뒤, 다시 git add와 git commit 진행

◎ 협업 상황에서 누군가가 설정 파일을 커밋해 버려서 뒤늦게 .gitignore를 수정해야 하는 일이 빈번하게 발생한다. 이 캐시 초기화 명령어 (rm cached ➔ add ➔ commit)를 숙지해 두면 Git의 추적 상태를 초기화할 수 있다.

1. 시험환경 (Environment)

◎ OS: Windows (윈도우)
◎ Version Control: Git
◎ Platform: GitHub
◎ Terminal: VS Code Terminal / CMD / Git Bash

2. 문제 인식 (Problem)

◎ 분명히 크롬 등 웹 브라우저에서는 작업하려는 올바른 GitHub 계정으로 잘 로그인되어 있는데, 막상 VS Code 터미널이나 CMD에서 git pull이나 git push를 실행하면 아래와 같은 에러가 발생하는 경우가 있다.

  - 저장소 주소도 맞고 브라우저에서도 잘 보이는데, 터미널에서만 저장소를 찾을 수 없다며(Repository not found) 접근을 거부당하는 상황이다.

> git pull
remote: Repository not found.
fatal: repository 'https://github.com/*********/*****************.git/' not found

3. 원인 분석 (Cause)

◎ 이 에러는 내 PC(로컬 터미널)가 사용 중인 Git 인증 정보와 현재 접근하려는 저장소(Repository)의 권한이 서로 불일치하기 때문에 발생한다.

◎ 윈도우 운영체제는 사용자가 한 번 깃허브에 로그인하면 편의를 위해 그 "자격 증명(Credential)"을 윈도우 시스템 깊숙이 저장해 둔다.

◎ 따라서 사용자가 웹 브라우저에서 다른 계정으로 로그아웃/로그인을 하더라도, 터미널은 예전에 윈도우에 저장해 둔 '과거의 계정'으로 접근을 시도하면서 에러를 뱉어내는 것이다.

4. 해결방법 (Solution)

1) 기존 자격 증명(Credential) 삭제하기

  ① 윈도우 좌측 하단 검색창에서 "자격 증명 관리자"를 검색하여 실행한다.

      - (또는 [제어판] → [사용자 계정]  → [자격 증명 관리자] 메뉴로 이동한다.)

  ② "Windows 자격 증명" 탭에서 'git:https://github.com' 관련 항목을 찾아 "제거"한다.

  ③ 이제 윈도우(터미널)에서 이전 깃허브 계정의 정보가 깨끗하게 삭제된 것이다.

2) 다시 로그인하여 권한 얻기

  ① 다시 터미널로 돌아가서 git pull (또는 git push)을 실행한다.

    - 이전과 달리 GitHub 로그인 팝어방이 뜨는 것을 확인할 수 있다.

  ② 이때, 작업 저장소(Repository)에 접근 권한이 있는 게정으로 로그인을 진행한다.

  ③ 로그인한 새 계정 정보로 "Windows 자격 증명"이 자동으로 업데이트 되며, Git 명령어들이 정상 동작한다.

4. 요약 및 마무리

◎ 이 문제의 핵심은 "터미널(로컬 환경)의 인증 정보가 웹 브라우저의 실제 권한 계정과 일치하도록 동기화하는 것"이다.

◎ 회사 계정과 개인 계정을 번갈아 사용하다 보면 이 에러를 매우 자주 마주치게 된다. 터미널에서 권한 에러가 발생한면 윈도우의 '자격 증명 관리자'를 가장 먼저 확인하도록 하자.

1. 시험환경 (Environment)

◎ OS: Windows 11 / macOS
◎ Version Control: Git
◎ Platform: GitHub
◎ Terminal: Git Bash / VS Code Terminal

2. 문제 인식 (Problem)

◎ 하나의 PC로 회사 업무와 개인 프로젝트를 동시에 진행하다 보면 커밋(Commit) 계정이 섞이는 경우가 발생한다.

◎ 예를 들어, 내 PC의 기본 Git 계정이 "회사용"으로 세팅되어 있는데, 개인 프로젝트 폴더에서 무심코 코드를 커밋해 버리는 경우이다. 이렇게 되면 GitHub 개인 저장소에 '회사 이메일'로 커밋이 찍히게 되는 경우가 발생한다.

3. 원인 분석 (Cause)

◎ Git은 커밋할 때마다 현재 설정된 '누가 작성했는지(user.name)'와 '어떤 이메일인지(user.email)'를 기록한다.

◎ 1대의 PC에서 여러 깃허브 계정을 충돌 없이 분리해서 쓰려면, Git의 설정 범위를 이해해야 한다. PC 전체에 공통으로 적용되는 기본 계정(Global)과 특정 프로젝트 폴더에만 예외적으로 적용되는 개별 계정(Local)을 명확히 나누어 설정해야 한다.

4. 해결방법 (Solution)

1) 기본값 설정하기 (전역 설정: --global 옵션)

  ① 내 PC의 모든 Git 저장소(Repository)에서 기본으로 사용할 이름과 이메일을 설정한다. 주로 더 자주 사용하는 계정(회사 계정 또는 주력 개인 계정)을 전역으로 설정해 두는 것이 편리하다.

  # Git Commit을 식별할 PC 전체 기본 이름 설정
  git  config  --global  user.name  "기본이름"
 
  # GitHub에 등록된 PC 전체 기본 이메일 설정
  git  config  --global  user.email  "기본이메일@example.com"

2) 특정 프로젝트만 다른 계정 사용하기 (저장소별 개별 설정)

  ① 터미널에서 예외를 적용할 개인 프로젝트 폴더로 이동한다.

 cd  내_특정프로젝트_폴더경로

  ② 이번에는 --global 옵션을 제외하고 해당 저장소 전용 이름과 이메일을 설정합니다.

  # 글로벌 옵션을 제외하고 현재 폴더에만 적용
  git config user.name "개인계정이름"
  git config user.email "개인계정이메일@example.com"

  ③ 현재 프로젝트 폴더 안에 숨겨진 .git/config 파일에 정보가 별도로 저장되며, 전역(Global) 설정보다 우선적으로 덮어쓰기(Override) 되어 적용된다.

3) 설정 결과 확인
  ① 설정이 올바르게 적용되었는지 원하는 프로젝트 폴더 터미널에서 아래 명령어로 확인할 수 있다.

  # 특정 항목만 정확하게 확인하고 싶을 때
  git config user.name
  git config user.email
 
  # 설정된 전체 리스트 확인
  git config --list

5. 요약 및 마무리 (Summary)

◎ Git 계정 설정의 규칙은 다음과 같다.

  --global 포함: PC 전체의 기본 계정 설정
  --global 제외: 현재 폴더(프로젝트)만의 전용 계정 설정 (기본값 무시하고 우선 적용)

1. 시험환경 (Environment)

◎ OS: Windows 11 / macOS
◎ Version Control: Git
◎ IDE: Visual Studio Code
◎ Terminal: bash / zsh / PowerShell

2. 문제 인식 (Problem)

◎ 프로젝트에서 더 이상 사용하지 않는 파일을 삭제해야 할 때가 있다. 보통 탐색기 등에서 파일을 우클릭하여 '삭제(Delete)'를 누르거나 키보드의 Del 키를 눌러 파일을 지울것이다.

◎ 하지만 이렇게 지우고 나서 터미널에 git status를 쳐보면 붉은색 글씨로 deleted: 파일명이라고 표시된다. 깃(Git)이 파일이 삭제된 것은 알아차리지만, 이 삭제 내역을 커밋(Commit)에 포함시키려면 git add . 또는 git add 파일명 명령어를 한 번 더 입력해야 한다.

3. 원인 분석 (Cause)

◎ 이러한 현상은 Git이 내부적으로 관리하는 3단계 작업 영역(Working Directory ➔ Staging Area ➔ Repository) 구조 때문이다.

◎ 윈도우 탐색기 등에서 직접 파일을 지우는 행위(또는 리눅스 기본 명령어인 rm을 사용하는 행위)는 오직 첫 번째 단계인 '작업 디렉토리(Working Directory)'에서만 파일을 물리적으로 삭제한 것이다.

◎ Git의 입장에서는 "어? 내 작업 폴더에 있던 파일이 사라졌네?"라고 인지는 하지만, "이 삭제라는 변경 사항을 다음 커밋에 포함시킬까?"에 대한 확답(Staging)을 받지 못했기 때문에 삭제 내역을 대기실(Staging Area)로 올리지 않고 기다리는 것이다.

4. 해결방법 (Solution)

1) 일반적인 삭제 (Delete 키 또는 rm 명령어)

  ① 물리적인 파일만 삭제되며, 커밋을 위해 반드시 git add가 추가로 필요하다.

  # 1. 파일 직접 삭제 (OS 명령어)
  rm 불필요한파일.js
 
  # 2. 삭제된 상태 확인 (붉은색으로 unstaged 상태 표시됨)
  git status
 
  # 3. 삭제 내역을 Staging Area에 수동으로 올리기
  git add 불필요한파일.js

2) Git 명령어로 삭제 (git rm)

  ① git rm 명령어는 '작업 디렉토리에서 물리적 파일 삭제' + '삭제 내역을 Staging Area에 올리기(git add)'를 한 번에 처리해 주는 명령어다.

  # 1. 물리적 삭제와 Git Staging을 동시에 처리
  git rm 불필요한파일.js
 
  # 2. 상태 확인 (초록색으로 삭제 내역이 staged 상태 표시됨 - 바로 커밋 가능!)
  git status
 
  # 3. 커밋
  git commit -m "chore: 불필요한 파일 삭제"

3) 로컬 파일은 살려두고 Git에서만 지우기 (git rm --cached)
  ① 실수로 API 키가 들어있는 .env 파일이나 node_modules 폴더를 git add .로 올려버렸을 때가 있다. 이때 git rm을 쓰면 내 PC에 있는 .env 파일까지 물리적으로 삭제된다.

  ② 내 PC(Working Directory)의 물리적 파일은 그대로 보존하면서, 오직 Git의 추적(Staging Area)에서만 파일을 빼내고 싶을 때는 반드시 --cached 옵션을 붙여야 한다.

  # 물리적인 .env 파일은 내 PC에 그대로 남겨두고, Git의 추적 목록에서만 제거
  git rm --cached .env
 
  # 이후 .gitignore 파일에 .env를 추가하고 커밋하면 안전합니다.

5. 요약 및 마무리 (Summary)

◎ 상황에 따른 올바른 파일 삭제 명령어와 깃의 상태 변화를 요약하면 다음과 같다.