Git이란? — 왜 개발자라면 반드시 써야 할까
Git은 분산 버전 관리 시스템(DVCS)입니다. 쉽게 말하면, 파일의 변경 이력을 기록해두고 언제든 과거 시점으로 되돌아갈 수 있게 해주는 도구입니다.
"final_진짜최종_v3_수정완료.zip" 같은 파일명을 만들어본 적 있다면, 그게 바로 Git이 해결하는 문제입니다.
Git은 '버전 관리 시스템'이고, GitHub은 Git 저장소를 호스팅하는 '서비스'입니다. Git은 도구, GitHub은 플랫폼입니다.
Git vs GitHub vs GitLab
| 구분 | Git | GitHub | GitLab |
|---|---|---|---|
| 종류 | 버전 관리 도구 | 호스팅 서비스 | 호스팅 서비스 |
| 동작 위치 | 내 컴퓨터 (로컬) | 클라우드 | 클라우드 / 자체 서버 |
| 비용 | 무료 | 무료 / 유료 | 무료 / 유료 |
| 핵심 기능 | 버전 관리 | 협업 + PR + Issues | 협업 + CI/CD 내장 |
Git을 배워야 하는 이유는 명확합니다. 혼자 개발해도 이력 관리에 필수이고, 팀 협업에서는 아예 Git 없이 일할 수 없습니다. 개발자 채용 공고에 "Git 사용 경험"이 빠지는 곳은 없습니다.
Git 설치하기 (Windows / Mac / Linux)
OS별 설치 방법
# Windows — 공식 사이트에서 설치 파일 다운로드
# https://git-scm.com/download/win
# 설치 시 기본 옵션 그대로 Next 클릭하면 됩니다.
# Mac — Homebrew 사용
brew install git
# Mac — Xcode Command Line Tools (Homebrew 없을 때)
xcode-select --install
# Linux (Ubuntu / Debian)
sudo apt update && sudo apt install git
# Linux (CentOS / Fedora)
sudo yum install git설치 확인 & 초기 설정
# 설치 확인
git --version
# → git version 2.47.1 (예시)
# 초기 설정 (필수! 커밋에 기록될 이름과 이메일)
git config --global user.name "홍길동"
git config --global user.email "hong@example.com"
# 설정 확인
git config --listuser.name과 user.email은 커밋 기록에 남는 정보입니다. GitHub 계정과 동일한 이메일을 사용하면 커밋이 프로필에 연결됩니다.
기본 명령어 7가지 — 이것만 알면 시작할 수 있다
| 순서 | 명령어 | 설명 | 예시 |
|---|---|---|---|
| 1 | git init |
새 Git 저장소 생성 | git init |
| 2 | git clone |
원격 저장소를 내 컴퓨터로 복사 | git clone https://github.com/user/repo.git |
| 3 | git status |
현재 상태 확인 (변경된 파일 목록) | git status |
| 4 | git add |
변경 파일을 스테이징 (커밋 준비) | git add . (전체) 또는 git add 파일명 |
| 5 | git commit |
변경 사항을 기록 (스냅샷 저장) | git commit -m "로그인 기능 추가" |
| 6 | git push |
로컬 커밋을 원격 저장소에 업로드 | git push origin main |
| 7 | git pull |
원격 저장소의 변경 사항을 가져오기 | git pull origin main |
실전 흐름: 파일 수정 → 커밋 → 푸시
# 1. 파일 수정 후 상태 확인
git status
# 2. 변경된 파일 스테이징
git add .
# 3. 커밋 (메시지와 함께)
git commit -m "feat: 회원가입 폼 유효성 검사 추가"
# 4. 원격 저장소에 푸시
git push origin main커밋 메시지는 '무엇을 왜 변경했는지'를 한 줄로 표현하세요. "수정", "업데이트" 같은 모호한 메시지는 나중에 아무 도움이 안 됩니다.
브랜치 완벽 이해 — 왜 쓰고, 어떻게 쓰나?
브랜치는 '평행 우주'라고 생각하면 됩니다. 각 브랜치에서 독립적으로 작업하고, 완성되면 합치는 구조입니다.
브랜치(Branch)는 독립적인 작업 공간입니다. main 브랜치를 건드리지 않고 새 기능을 개발하거나 버그를 수정할 수 있습니다.
브랜치 기본 명령어
# 브랜치 목록 보기
git branch
# 새 브랜치 생성
git branch feature/login
# 브랜치 전환
git checkout feature/login
# 또는 (최신 방식)
git switch feature/login
# 생성 + 전환 한 번에
git checkout -b feature/login
# 또는
git switch -c feature/login
# 브랜치 삭제
git branch -d feature/login브랜치 네이밍 컨벤션
| 접두사 | 용도 | 예시 |
|---|---|---|
feature/ |
새 기능 개발 | feature/login, feature/payment |
fix/ |
버그 수정 | fix/login-error, fix/typo |
hotfix/ |
긴급 수정 | hotfix/security-patch |
refactor/ |
코드 정리 | refactor/api-structure |
실전 흐름: 브랜치로 작업하기
# 1. main에서 새 브랜치 생성
git switch -c feature/signup
# 2. 코드 작성 & 커밋
git add .
git commit -m "feat: 회원가입 API 구현"
# 3. 원격에 브랜치 푸시
git push -u origin feature/signup
# 4. GitHub에서 Pull Request 생성
# 5. 코드 리뷰 후 main에 머지충돌(Conflict) 해결 — 당황하지 않는 법
충돌은 '에러'가 아닙니다. 두 사람이 같은 부분을 다르게 수정했을 때 Git이 '어느 쪽을 쓸까요?'라고 물어보는 것입니다.
충돌은 같은 파일의 같은 부분을 두 브랜치에서 서로 다르게 수정했을 때 발생합니다.
충돌이 발생하면 보이는 형태
<<<<<<< HEAD
const message = "안녕하세요";
=======
const message = "반갑습니다";
>>>>>>> feature/greeting<<<<<<< HEAD~=======: 현재 브랜치의 코드=======~>>>>>>> feature/greeting: 합치려는 브랜치의 코드
충돌 해결 3단계
- 충돌 파일 열기 —
<<<<<<<,=======,>>>>>>>마커 찾기 - 원하는 코드만 남기기 — 마커를 모두 삭제하고, 최종 코드만 남김
- 저장 → add → commit
# 충돌 해결 후
git add .
git commit -m "merge: greeting 브랜치 충돌 해결"VS Code에서는 충돌 부분에 'Accept Current Change', 'Accept Incoming Change', 'Accept Both' 버튼이 나타납니다. 클릭 한 번으로 해결 가능합니다.
Pull Request(PR) — 협업의 핵심
Pull Request(PR)는 "내 코드를 main에 합쳐주세요"라고 요청하는 것입니다. GitHub에서 가장 중요한 협업 기능입니다.
PR 작성 흐름
- feature 브랜치에서 작업 완료 & push
- GitHub에서 "Compare & pull request" 버튼 클릭
- 제목과 설명 작성 (무엇을 왜 변경했는지)
- 리뷰어 지정 → 코드 리뷰
- 승인(Approve) 후 Merge
좋은 PR 작성법
| 항목 | 좋은 예 | 나쁜 예 |
|---|---|---|
| 제목 | feat: 소셜 로그인 (카카오) 추가 | 기능 추가 |
| 설명 | 변경 이유, 주요 변경사항 목록, 테스트 방법 포함 | (설명 없음) |
| 크기 | 변경 파일 5~10개 이내 | 변경 파일 50개 이상 (리뷰 불가능) |
.gitignore — 올리면 안 되는 파일 관리하기
.env 파일, API 키, node_modules 같은 것은 절대 커밋하면 안 됩니다. 한 번 올리면 기록에 남아 완전히 지우기 어렵습니다.
.gitignore 파일은 Git이 추적하지 않을 파일/폴더를 지정하는 설정 파일입니다. 프로젝트 루트에 생성합니다.
자주 쓰는 .gitignore 패턴
# 환경 변수 (API 키, 비밀번호 등)
.env
.env.local
.env.production
# 의존성 폴더 (용량이 큼)
node_modules/
venv/
__pycache__/
# 빌드 결과물
dist/
build/
*.class
# IDE 설정 파일
.idea/
.vscode/settings.json
*.swp
# OS 파일
.DS_Store
Thumbs.db
# 로그 파일
*.log
logs/gitignore.io (toptal.com/developers/gitignore)에서 사용하는 언어·프레임워크를 선택하면 최적의 .gitignore를 자동 생성해줍니다.
Git 명령어 치트시트 (저장 필수)
상황별로 자주 쓰는 명령어를 정리했습니다. 즐겨찾기 해두고 필요할 때 찾아보세요.
| 상황 | 명령어 | 설명 |
|---|---|---|
| 시작하기 | git init |
새 저장소 생성 |
git clone URL |
원격 저장소 복사 | |
git remote -v |
연결된 원격 저장소 확인 | |
| 일상 작업 | git status |
현재 상태 확인 |
git add . |
모든 변경 파일 스테이징 | |
git commit -m "메시지" |
커밋 | |
git push origin 브랜치명 |
원격에 업로드 | |
| 브랜치 | git branch |
브랜치 목록 |
git switch -c 브랜치명 |
새 브랜치 생성 + 전환 | |
git merge 브랜치명 |
현재 브랜치에 합치기 | |
git branch -d 브랜치명 |
브랜치 삭제 | |
| 되돌리기 | git log --oneline |
커밋 이력 한 줄로 보기 |
git diff |
변경 내용 비교 | |
git reset HEAD~1 |
마지막 커밋 취소 (변경 유지) | |
git stash |
작업 중인 변경사항 임시 저장 |
Q. Git과 GitHub은 같은 건가요?
아닙니다. Git은 로컬에서 동작하는 버전 관리 도구이고, GitHub은 Git 저장소를 온라인에 호스팅하는 서비스입니다. GitHub 외에도 GitLab, Bitbucket 등의 대안이 있습니다.
Q. commit은 얼마나 자주 해야 하나요?
정답은 없지만, '의미 있는 단위'마다 하는 것이 좋습니다. 기능 하나를 완성했을 때, 버그를 고쳤을 때 등 '나중에 이 시점으로 되돌아올 이유가 있는' 단위가 적당합니다. 너무 자주(줄 하나마다)도, 너무 드물게(하루에 한 번)도 좋지 않습니다.
Q. 실수로 잘못된 파일을 커밋했는데 어떻게 하나요?
git reset HEAD~1으로 마지막 커밋을 되돌릴 수 있습니다 (변경 내용은 유지됨). 이미 push한 경우에는 git revert로 새 커밋을 만들어 되돌리는 것이 안전합니다. force push는 협업 시 다른 사람의 작업을 덮어쓸 수 있으므로 주의하세요.
Q. fork와 clone의 차이가 뭔가요?
clone은 원격 저장소를 내 컴퓨터로 복사하는 것이고, fork는 다른 사람의 저장소를 내 GitHub 계정으로 복사하는 것입니다. 오픈소스 기여 시 fork → clone → 수정 → PR의 흐름으로 진행합니다.
