Git 입문: 버전 관리가 필요한 이유부터 add, commit, HEAD, reset까지

About this offer

개발을 하다 보면 final.txt , final_진짜.txt , final_진짜최종.txt 처럼 파일을 복사해서 이전 상태를 남기고 싶을 때가 있다. 작은 작업에서는 버틸 수 있지만 파일이 많아지고 수정 횟수가 늘어나면 무엇을 언제 왜 바꿨는지 추적하기가 급격히 어려워진다. Git은 이런 문제를 해결하는 분산 버전 관리 시스템(Distributed Version Control System) 이다. 단순히 파일을 백업하는 도구가 아니라, 프로젝트의 변경 이력을 버전 단위로 기록하고 과거 상태를 확인하거나 다시 돌아갈 수 있게 해준다. 이 글에서는 Git을 처음 접할 때 꼭 이해해야 하는 흐름을 중심으로 정리한다. Git과 GitHub는 같은 것이 아니다 처음에는 Git과 GitHub를 같은 것으로 생각하기 쉽다. Git : 내 컴퓨터에서 버전을 관리하는 프로그램 GitHub : Git 저장소를 인터넷에 보관하고 협업할 수 있게 해주는 서비스 GitHub가 없어도 Git은 사용할 수 있다. 반대로 GitHub와 비슷한 서비스로 GitLab, Bitbucket 등도 존재한다. 즉 구조는 다음과 같다. 내 컴퓨터 └─ Git ├─ 버전 생성 ├─ 과거 버전 확인 ├─ 브랜치 관리 └─ 병합 인터넷 ├─ GitHub ├─ GitLab └─ Bitbucket Git을 먼저 이해하고 그다음 원격 저장소 서비스를 연결한다고 생각하면 훨씬 덜 헷갈린다. 저장소를 만드는 git init Git으로 관리할 프로젝트 폴더에서 다음 명령을 실행한다. git init 실행하면 프로젝트 내부에 .git 디렉터리가 생성된다. my-project/ ├─ .git/ ├─ src/ └─ README.md .git 에는 커밋, 브랜치, 태그, 설정 등 Git 저장소의 핵심 정보 가 들어 있다. 일반적인 프로젝트 파일처럼 임의로 수정하거나 삭제하면 저장소 이력이 손상될 수 있으므로 직접 건드리지 않는 편이 좋다. 현재 상태는 다음 명령으로 확인할 수 있다. git status Git의 핵심 구조: Working Directory → Staging Area → Repository Git을 이해할 때 가장 중요한 구조다. Working Directory │ │ git add ▼ Staging Area │ │ git commit ▼ Repository (.git) Working Directory 현재 직접 파일을 만들고 수정하는 프로젝트 공간이다. 예를 들어 app.js 를 수정하면 우선 Working Directory에 변경이 생긴다. Staging Area 다음 커밋에 포함할 변경사항을 고르는 대기 공간 이다. 수정된 모든 파일을 무조건 하나의 버전으로 만들 필요는 없다. 여러 변경 중 관련 있는 것만 선택해서 하나의 커밋으로 묶을 수 있다. git add app.js 여러 파일을 한 번에 추가하려면 다음처럼 사용할 수 있다. git add . 다만 무조건 git add . 부터 누르기보다 git status 와 변경 내용을 먼저 확인하는 습관이 좋다. Repository Staging Area에 올라온 변경사항을 커밋하면 저장소에 새로운 버전이 만들어진다. git commit -m "회원 로그인 화면 추가" 정리하면 다음과 같다. 파일 수정 = 아직 버전 아님 git add = 이번 버전에 넣을 변경 선택 git commit = 선택한 변경을 하나의 버전으로 기록 처음 커밋할 때 사용자 정보 설정하기 Git을 처음 설치한 환경에서는 커밋 작성자 정보가 없어 오류가 발생할 수 있다. 전역 설정은 다음처럼 한다. git config --global user.name "Your Name" git config --global user.email "you@example.com" 현재 설정을 확인하려면 다음 명령을 사용할 수 있다. git config --global --list 회사 계정과 개인 계정을 분리해야 한다면 저장소별 설정도 가능하다. git config user.name "Work Name" git config user.email "work@example.com" --global 을 빼면 현재 저장소에만 적용된다. 커밋은 파일이 아니라 프로젝트의 스냅샷이다 커밋은 단순히 "수정한 파일 하나를 저장한다"는 개념보다 프로젝트가 그 시점에 어떤 상태였는지를 기록한 스냅샷 에 가깝다. 예를 들어 다음과 같이 프로젝트가 변했다고 해보자. A ── B ── C A: 프로젝트 생성 B: 로그인 기능 추가 C: 로그인 오류 수정 각 커밋은 이전 커밋과 연결되어 하나의 히스토리를 만든다. 커밋 목록은 다음 명령으로 확인한다. git log 간단하게 보고 싶다면 다음 옵션이 편하다. git log --oneline 브랜치 흐름까지 확인하려면 다음 조합이 유용하다. git log --oneline --graph --decorate --all Commit ID는 버전을 식별한다 각 커밋에는 고유한 Commit ID 가 있다. 7f3a2d1 로그인 기능 추가 0a91bc7 초기 프로젝트 구성 실제 Git의 객체 ID는 해시로 만들어진다. 일반적으로 로그에서는 앞부분만 줄여서 표시한다. 커밋의 내용이나 부모 커밋, 작성자, 메시지 같은 정보가 달라지면 다른 커밋 객체가 되므로 ID도 달라진다. 이 때문에 마지막 커밋 메시지만 수정해도 커밋 ID가 바뀔 수 있다. git commit --amend -m "회원 로그인 기능 추가" --amend 는 기존 커밋 자체를 덮어쓰는 것이 아니라 수정된 내용을 가진 새 커밋을 만들고 브랜치가 새 커밋을 가리키게 하는 동작 으로 이해하면 좋다. 이미 원격 저장소에 공유한 커밋을 amend하면 다른 사람의 히스토리와 달라질 수 있으므로 주의한다. HEAD는 현재 내가 바라보고 있는 위치다 Git을 이해할 때 자주 등장하는 것이 HEAD 다. 보통 HEAD 는 현재 체크아웃한 브랜치를 가리킨다. A ── B ── C ↑ main ↑ HEAD 현재 main 브랜치에서 새 커밋 D를 만들면 main 이 D로 이동하고, HEAD는 계속 main 을 따라간다. A ── B ── C ── D ↑ main ↑ HEAD 이 구조를 이해하면 브랜치, checkout, reset이 훨씬 쉬워진다. 과거 버전 확인하기: checkout과 switch 예전부터 널리 사용된 명령은 git checkout 이다. git checkout <commit-id> 특정 과거 커밋으로 이동하면 HEAD가 브랜치가 아닌 커밋 자체를 직접 가리키는 Detached HEAD 상태가 될 수 있다. 요즘 Git에서는 역할을 더 명확하게 나누기 위해 브랜치 이동에는 git switch , 파일 복구에는 git restore 를 사용할 수 있다. git switch main 특정 커밋을 단순히 확인하려면 다음처럼 명시적으로 사용할 수 있다. git switch --detach <commit-id> 초보 단계에서는 다음 차이만 기억해도 충분하다. git switch main → main 브랜치로 이동 git switch --detach <commit> → 특정 과거 커밋을 임시로 확인 과거 상태를 둘러본 뒤 작업을 이어갈 때는 다시 브랜치로 돌아온다. git switch main reset은 HEAD가 가리키는 브랜치를 이동시킨다 switch 또는 checkout 이 현재 바라보는 위치를 바꾸는 것 이라면, reset 은 현재 브랜치 자체의 위치를 이동시키는 데 사용한다. A ── B ── C ── D ↑ main 다음 명령을 실행했다고 해보자. git reset --hard B 그러면 개념적으로는 다음처럼 된다. A ── B ── C ── D ↑ main C , D 가 즉시 물리적으로 사라진다고 생각하기보다는 main이 더 이상 해당 커밋을 가리키지 않게 됐다 고 이해하는 편이 정확하다. --hard 는 특히 조심해야 한다 git reset --hard <commit-id> --hard 는 브랜치 위치뿐 아니라 Working Directory와 Staging Area도 해당 커밋 상태로 맞춘다. 따라서 커밋하지 않은 변경사항이 사라질 수 있다. 실수한 상황에서 의미를 모르고 반복해서 reset, checkout, force push를 실행하기보다 현재 상태를 먼저 확인하는 것이 중요하다. reflog는 내가 이동한 기록까지 보여준다 커밋 로그에서 보이지 않게 된 커밋도 reflog 를 통해 다시 찾을 수 있는 경우가 많다. git reflog 예를 들어 실수로 reset을 했다면 이전 HEAD 위치가 reflog에 남아 있을 수 있다. abc1234 HEAD@{0}: reset: moving to HEAD~2 def5678 HEAD@{1}: commit: 결제 기능 수정 이전 커밋 ID를 확인한 뒤 필요하면 복구할 수 있다. git reset --hard def5678 Git이 안전하다는 말은 "아무 명령이나 실행해도 괜찮다"는 뜻이 아니다. 커밋과 참조 이동 기록을 잘 이해하면 복구 가능한 경우가 많다 는 의미에 가깝다. 공유한 히스토리는 함부로 다시 쓰지 않는다 로컬에서 아직 나만 사용하는 커밋이라면 reset이나 amend를 비교적 자유롭게 사용할 수 있다. 하지만 이미 원격 저장소에 push해서 다른 사람과 공유한 커밋은 상황이 다르다. 히스토리를 다시 쓴 뒤 다음과 같은 강제 push를 하면 다른 사람의 작업과 충돌할 수 있다. git push --force 협업 저장소에서는 일반적으로 강제 push를 최소화하고, 정말 필요하다면 팀 규칙을 먼저 확인하는 편이 안전하다. 불가피하게 강제 갱신이 필요할 때는 --force-with-lease 가 상대적으로 안전한 선택이 될 수 있지만, 이것도 히스토리를 변경하는 명령이라는 점은 같다. 기본 흐름을 한 번에 정리하기 새로운 프로젝트에서 가장 기본적인 작업 흐름은 다음과 같다. # 저장소 초기화 git init # 현재 상태 확인 git status # 파일 수정 후 스테이징 git add README.md # 버전 생성 git commit -m "README 작성" # 히스토리 확인 git log --oneline --graph --decorate 이 흐름을 반복하면 프로젝트의 변경 이력이 차곡차곡 쌓인다. 수정 ↓ git add ↓ Staging Area ↓ git commit ↓ 새로운 버전 Git 명령을 전부 암기하는 것보다 어떤 영역이 어떻게 이동하는지 를 이해하는 것이 훨씬 중요하다. 핵심 정리 Git은 분산 버전 관리 시스템 이고 GitHub는 Git 저장소를 호스팅하는 별도의 서비스다. git init 을 실행하면 프로젝트를 관리하는 .git 디렉터리가 생성된다. Git의 기본 흐름은 Working Directory → Staging Area → Repository 다. git add 는 다음 커밋에 포함할 변경을 선택하고, git commit 은 그 변경을 하나의 버전으로 만든다. 각 커밋에는 고유한 Commit ID가 있고 커밋 정보가 바뀌면 ID도 달라진다. HEAD 는 현재 바라보는 브랜치 또는 커밋을 나타낸다. git reset --hard 는 커밋하지 않은 변경을 잃을 수 있으므로 의미를 이해하고 사용해야 한다. git reflog 는 HEAD 이동 기록을 확인해 실수한 reset 등을 복구할 때 유용하다.