Git 기본 명령과 파일 상태

Git으로 버전을 남기는 과정은 결국 "작업한 파일을 골라서(add) 스냅숏으로 기록(commit)" 하는 일의 반복이다. 이 흐름과 각 단계에서 파일이 어떤 상태인지 알면 대부분의 git status 메시지를 읽을 수 있다.

Git이란: 분산 버전 관리

버전 관리 시스템(VCS) 은 파일의 변경 이력을 기록해 두고, 원하는 시점으로 되돌리거나 여러 사람의 변경을 합치게 해 주는 도구다. 이력을 어디에 두느냐로 세 가지로 나뉜다.

Git은 분산 버전 관리 시스템이고, 다른 VCS와 구분되는 성질이 몇 가지 있다.

Git은 도구이고 GitHub·GitLab은 Git 저장소를 호스팅하며 PR·이슈 같은 협업 기능을 얹은 서비스다.

세 개의 영역

Staging Area와 Repository는 .git 폴더 안에서 관리되는 논리적 공간이다. 즉 .git 폴더를 지우면 모든 버전 기록이 사라지니 주의해야 한다.

원격까지 네 곳: 명령은 코드를 옮기는 일

흔히 코드가 "내 컴퓨터"와 "GitHub" 두 곳에 있다고 생각하지만, 로컬에만 세 곳이 있어 코드는 모두 네 곳에 있다. Git 명령 대부분은 이 네 곳 사이에서 변경을 옮기는 일이다.

flowchart LR
    wd["Working Directory"] -->|"add"| sa["Staging Area"]
    sa -->|"commit"| lr["Local Repo"]
    lr -->|"push"| rr["Remote Repo"]
    sa -->|"restore --staged"| wd
    rr -->|"fetch"| lr
    lr -->|"switch / checkout / merge"| wd
    rr -->|"pull (= fetch + merge)"| wd

clone: Remote Repo 전체를 처음 복사해 와 네 곳을 만든다

git restore와 git switch는 하는 일이 너무 많던 git checkout을 나눈 명령이다. 과거 자료의 git checkout -- <파일>, git reset <파일>은 각각 git restore <파일>, git restore --staged <파일>과 같다. 이미 만든 커밋을 되돌리는 revert·reset은 Git 되돌리기와 이력 다루기에 있다.

파일의 상태(라이프 사이클)

• untracked: 한 번도 커밋(또는 add)된 적 없는, Git이 추적하지 않는 파일
• tracked: Git이 추적하는 파일
  • unmodified (committed): 마지막 커밋과 동일한 상태
  • modified: 마지막 커밋 이후 수정된 상태
  • staged: 수정 사항이 Staging Area에 올라가 다음 커밋을 기다리는 상태

커밋된 내용은 언제든 되살릴 수 있지만, 한 번도 커밋되지 않은 변경은 Git이 복구해 줄 수 없다. (git restore <file>로 작업 내용을 되돌리면 그 변경은 영영 사라지니 주의한다.)

기본 명령어

저장소 만들기: git init

$ git init
Initialized empty Git repository in /Users/me/first/.git/

현재 폴더에 .git 디렉터리가 생기고, 터미널 프롬프트에 (main) 처럼 현재 브랜치가 표시된다.

참고: 기본 브랜치 이름은 오랫동안 master였다. GitHub는 2020년 10월부터 새 저장소의 기본 브랜치를 main으로 만들고(GitHub Changelog), Git 2.x의 git init은 설정이 없으면 여전히 master를 만들면서 힌트 메시지를 띄운다. 다음 메이저 버전인 Git 3.0부터는 main이 기본이 될 예정이다(출시일 미정, Git BreakingChanges). 지금 바로 맞추려면 git config --global init.defaultBranch main (Git 2.28+)으로 설정한다. 이름이 바뀐 배경은 master/slave 같은 용어가 노예제를 떠올리게 한다는 문제 제기이고, GitHub는 이런 문화적 민감성(cultural sensitivity)을 고려해 기본값을 바꿨다. 저장소를 다른 서비스로 미러링할 계획이라면 양쪽의 기본 브랜치 이름을 맞춰 두는 편이 안전하다(원격 저장소와 GitHub의 미러링 참고). 이 창고의 Git 노트 예시는 모두 main을 쓴다.

스테이징: git add

$ git add a.txt            # 파일 하나
$ git add a.txt b.txt      # 여러 파일
$ git add my_folder/       # 폴더 전체
$ git add .                # 현재 디렉터리의 모든 변경

파일의 일부만 고르기: git add -p

한 파일에 성격이 다른 수정 두 개가 섞여 있으면 커밋을 나누기 어렵다. -p(--patch)를 붙이면 변경을 헝크(hunk) 라는 덩어리 단위로 하나씩 보여 주며 스테이징할지 묻는다.

git restore -p(되돌리기), git reset -p(스테이징 취소), git stash -p도 같은 방식으로 일부만 고른다.

add -p는 추적 중인 파일의 변경만 보여 준다. 새 파일의 일부만 담으려면 먼저 git add -N <파일>(intent-to-add)로 "빈 파일이 추가될 예정"이라고 알린 뒤 git add -p <파일>을 쓴다.

git add .이나 git commit -am은 무엇이 들어가는지 보지 않고 담는다. 디버그 코드나 다른 작업이 섞여 들어가는 가장 흔한 경로이므로, add -p로 헝크를 확인하며 담고 git commit -v로 커밋 직전에 diff를 한 번 더 보는 습관이 커밋을 논리적 단위로 나누는 데도 도움이 된다(항상 켜려면 commit.verbose true).

커밋: git commit

$ git commit -m "Add login form"
$ git commit -am "Fix typo"      # 추적 중인 파일의 수정을 add 없이 바로 커밋 (새 파일은 안 들어간다)

커밋 메시지는 이 버전에서 무엇이 바뀌었는지 드러나도록 쓴다. -m 없이 실행하면 에디터(기본 Vim)가 열리고, 메시지를 쓴 뒤 Esc → :wq 로 저장·종료한다.

상태 확인: git status

$ git status
On branch main
Changes to be committed:            # Staging Area에 있는 변경
  (use "git restore --staged <file>..." to unstage)
        deleted:    b.txt
        new file:   c.txt
 
Changes not staged for commit:      # 수정됐지만 아직 add 안 함
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   a.txt
 
Untracked files:                    # Git이 추적하지 않는 새 파일
  (use "git add <file>..." to include in what will be committed)
        d.txt

git status -sb는 같은 내용을 한 줄씩 짧게 보여 준다(앞 칸이 staged, 뒤 칸이 unstaged 상태). status 출력은 위의 세 영역과 그대로 대응한다. 안내 문구에 나오는 git restore --staged(스테이징 취소)와 git restore(작업 내용 되돌리기)도 함께 기억해 두면 좋다.

차이 보기: git diff

git diff는 어느 두 영역을 비교하느냐에 따라 결과가 다르다. "diff가 비어 있다"는 대부분 이미 add한 변경을 그냥 git diff로 봤기 때문이다.

이력 보기: git log

$ git log                       # 전체 이력
$ git log --oneline             # 한 줄 요약
$ git log --oneline --all --graph   # 모든 브랜치를 그래프로

이력을 조건으로 걸러 찾는 방법(작성자·기간·메시지·코드 검색, blame, bisect)은 Git 이력 검색에 있다.

커밋 해시

로그의 각 커밋 앞에 붙는 40자리 16진수가 커밋 해시(SHA-1) 이다. 전 세계 어디서 만든 커밋이든 충돌 없이 구분할 만큼 큰 값이라서, 평소에는 git log --oneline에 보이는 앞 7자리 정도만 써도 충분하다. Git은 SHA-256 저장소도 지원하며, Git 3.0부터는 새 저장소의 기본 해시를 SHA-256(64자리)으로 바꿀 예정이다(Git BreakingChanges).

파일 옮기기와 추적 그만하기

$ git mv old.txt new.txt          # 이름 바꾸기 = 옮기고 옛 경로 삭제를 한 번에 스테이징
$ git rm a.txt                    # 파일을 지우고 삭제를 스테이징
$ git rm --cached secret.env      # 파일은 남기고 Git 추적만 끊는다

Git은 파일만 추적하고 빈 폴더는 추적하지 않는다. 빈 폴더를 저장소에 남기려면 안에 .gitkeep 같은 빈 파일을 하나 둔다(이름은 관례일 뿐 Git이 특별히 다루지 않는다).

.gitignore는 아직 추적하지 않는 파일에만 적용된다. 이미 커밋한 파일을 나중에 .gitignore에 넣어도 계속 추적된다. 이때는 추적을 끊고 다시 커밋한다.

$ git rm -r --cached .            # 인덱스를 비우고 (파일은 그대로)
$ git add .                       # .gitignore를 반영해 다시 담는다
$ git commit -m "Stop tracking ignored files"

이력에 남은 내용은 그대로이므로, 비밀 값이었다면 되돌리기와 이력 다루기의 민감 정보 절차를 따른다. 어떤 규칙 때문에 무시되는지는 git check-ignore -v <파일>로 본다.

추적 중인 파일의 로컬 수정만 숨기려고 git update-index --assume-unchanged나 --skip-worktree를 쓰는 팁이 돌지만, 공식 문서는 이 용도로 쓰지 말라고 한다(원래 성능 힌트·희소 체크아웃용이라 pull·switch 때 예기치 않게 동작한다). 로컬 설정은 추적하지 않는 별도 파일(config.local 등)로 분리한다.

자주 쓰는 셸 명령

Git Bash/터미널에서 함께 쓰는 기본 명령이다.

$ pwd               # 현재 위치
$ ls                # 목록 보기
$ cd ..             # 상위 디렉터리로 이동
$ mkdir dir         # 폴더 생성
$ touch a.txt       # 빈 파일 생성
$ rm -rf dir        # 폴더와 하위 파일 모두 삭제 (주의)

핵심 정리

• Git은 모든 클론이 전체 이력을 가지는 분산 버전 관리 시스템이고, 변경분이 아니라 스냅숏을 기록한다.
• 버전 기록 = add로 고르고 commit으로 남긴다.
• git status의 세 구역(staged / not staged / untracked)은 Staging Area · Working Directory · 미추적 파일에 대응한다.
• .git 폴더가 곧 저장소다. 지우면 이력이 사라진다.
• git diff는 add 전, git diff --staged는 add 후의 변경이다.
• 코드는 작업 디렉터리·스테이징·로컬 저장소·원격 저장소 네 곳에 있고, 명령은 그 사이를 옮긴다.

관련 노트: Git 브랜치, 원격 저장소와 GitHub, 자주 쓰는 Git 설정 옵션, Git의 내부 구조, Git 이력 검색, stash, worktree, clean, Git 되돌리기와 이력 다루기