Git & GitHub 실전 활용법
Git 없이 개발하는 건 Ctrl+Z 없이 문서를 작성하는 것과 같습니다. 되돌리기, 분기, 병합 — 이 세 가지가 Git의 전부입니다. 처음엔 명령어가 많아서 겁이 나지만, 실제로 매일 쓰는 건 손에 꼽을 정도입니다.
Git이 뭔데?
Git은 파일의 변경 이력을 추적하는 도구입니다. 쉽게 말하면, 코드의 "세이브 포인트"를 만들어주는 시스템입니다.
게임에서 보스전 전에 세이브하는 것처럼, 코드를 크게 바꾸기 전에 현재 상태를 저장(commit)할 수 있습니다. 뭔가 잘못되면 이전 세이브 포인트로 돌아가면 됩니다. 코드를 날려먹을 걱정이 사라지니까, 더 과감하게 실험할 수 있습니다.
Git 기본 명령어
저장소 초기화와 첫 커밋
git init # 현재 폴더를 Git 저장소로 만들기
git add index.html # 이 파일을 다음 커밋에 포함
git commit -m "feat: 초기 페이지 추가" # 세이브 포인트 생성
이 세 단계가 Git의 핵심 흐름입니다. init으로 시작하고, add로 파일을 고르고, commit으로 저장합니다.
여기서 add가 왜 필요한지 의문이 들 수 있습니다. 바로 commit하면 안 되나? Git에는 스테이징 영역이라는 개념이 있습니다. 10개 파일을 수정했는데 그중 3개만 커밋하고 싶을 때, add로 원하는 파일만 골라 담을 수 있습니다. 장바구니에 물건을 담는 것과 비슷합니다.
git add .으로 전체 파일을 한 번에 스테이징할 수도 있습니다. 하지만 .env(비밀 키가 담긴 파일)나 node_modules(의존성 폴더)가 실수로 포함되지 않도록 주의해야 합니다. .gitignore 파일을 먼저 만들어 두는 게 안전합니다.
# .gitignore 예시
node_modules/
.env
.DS_Store
dist/
이 파일에 적힌 경로는 Git이 아예 무시합니다. 프로젝트를 시작하면 가장 먼저 .gitignore부터 만드세요.
상태 확인과 히스토리
git status # 현재 상태 확인 — 뭐가 바뀌었는지 한눈에
git log --oneline # 커밋 히스토리를 한 줄씩 보기
git diff # 아직 커밋하지 않은 변경 내용 비교
git status는 가장 자주 쓰는 명령어입니다. "지금 뭘 수정했고, 뭘 아직 add 안 했는지"를 알려줍니다. 커밋하기 전에 습관적으로 한 번 확인하면 실수를 줄일 수 있습니다.
git log --oneline --graph를 쓰면 브랜치 구조를 시각적으로 볼 수 있습니다. 텍스트로 된 나뭇가지 그림이 나타나는데, GUI 도구 없이도 어떤 브랜치가 어디서 갈라지고 합쳐졌는지 파악할 수 있습니다.
브랜치 — Git의 진짜 힘
브랜치는 Git의 핵심 기능입니다. 코드의 "평행 우주"를 만드는 것과 같습니다.
main 브랜치는 항상 안정적인 상태를 유지해야 합니다. 새 기능을 만들 때는 별도의 브랜치를 만들어서 거기서 작업합니다. 기능이 완성되면 main에 합칩니다(merge). 이렇게 하면 작업 중인 기능이 완성되지 않아도, main은 항상 잘 돌아가는 상태를 유지합니다.
git checkout -b feature/login # 새 브랜치 생성 + 이동
# 여기서 마음껏 작업합니다
git add .
git commit -m "feat: 로그인 폼 구현"
git checkout main # main으로 돌아가기
git merge feature/login # 작업한 내용을 main에 합치기
checkout -b는 "새 브랜치를 만들면서 동시에 그 브랜치로 이동"하는 단축 명령어입니다. git branch feature/login + git checkout feature/login을 한 줄로 줄인 것입니다.
브랜치 네이밍 규칙
일관된 이름을 쓰면 프로젝트 관리가 편해집니다. 브랜치 이름만 봐도 "이 사람이 뭘 하고 있는지" 알 수 있어야 합니다.
feature/기능명— 새 기능 개발fix/버그명— 버그 수정refactor/대상— 코드 구조 개선 (동작은 같지만 코드를 깔끔하게)docs/문서명— 문서 작업
팀에서 이 규칙을 미리 정해두면 PR 리뷰 때 브랜치 이름만 봐도 맥락을 파악할 수 있습니다. 혼자 개발할 때도 이 습관을 들여두면, 나중에 팀 프로젝트를 할 때 자연스럽게 적응됩니다.
GitHub 협업 워크플로우
Pull Request 기반 개발
Pull Request(PR)는 "내가 이런 변경을 했는데, main에 합쳐도 될까?"라고 요청하는 것입니다. 코드 리뷰의 시작점이기도 합니다.
혼자 개발해도 PR을 만드는 습관을 들이면 좋습니다. 나중에 "왜 이렇게 바꿨지?"라는 질문에 대한 답이 기록으로 남습니다. 3개월 뒤의 내가 가장 감사할 대상은 PR을 꼼꼼히 작성한 과거의 나입니다.
# 작업 브랜치에서 GitHub로 push
git push origin feature/login
# GitHub 웹사이트에서 Pull Request 생성
# 팀원이 코드 리뷰
# 리뷰 통과 후 Merge
PR 제목은 커밋 메시지처럼 간결하게 씁니다. 본문에는 "왜" 이 변경이 필요한지를 적습니다. "무엇"을 바꿨는지는 코드 diff가 이미 보여주고 있으니까, 중복해서 쓸 필요가 없습니다.
커밋 메시지 컨벤션
feat: 새 기능 추가
fix: 버그 수정
refactor: 코드 구조 개선 (기능 변경 없음)
docs: 문서 수정
style: 코드 포맷팅 (기능 변경 없음)
test: 테스트 추가/수정
chore: 빌드 설정, 패키지 관리 등 잡일
이 형식은 Conventional Commits 표준을 따른 것입니다. 처음엔 "이렇게까지 해야 하나" 싶지만, 자동 버전 관리나 CHANGELOG 생성 도구와 호환됩니다. 커밋 히스토리가 깔끔해지는 건 덤입니다.
feat:은 사용자에게 보이는 새 기능, fix:은 버그 수정, refactor:는 코드 내부 구조 변경입니다. style:과 refactor:가 헷갈릴 수 있는데 — style:은 들여쓰기나 세미콜론 같은 순수 포맷팅만 해당됩니다.
충돌 해결 — 겁먹지 마세요
여러 사람이 같은 파일의 같은 줄을 수정하면 충돌(conflict)이 발생합니다. 처음 보면 당황스럽지만, 패턴을 알면 전혀 어렵지 않습니다.
<<<<<<< HEAD
const color = "blue";
=======
const color = "red";
>>>>>>> feature/theme
이게 무슨 뜻이냐면 — <<<<<<< HEAD부터 =======까지가 현재 내 코드이고, =======부터 >>>>>>>까지가 합치려는 브랜치의 코드입니다. 둘 중 하나를 선택하거나, 두 코드를 조합해서 새로운 결과를 만들면 됩니다.
VS Code에서는 "Accept Current Change", "Accept Incoming Change", "Accept Both Changes" 버튼이 자동으로 나타납니다. 클릭 한 번으로 해결할 수 있어서, 실제로는 텍스트를 직접 편집할 일이 거의 없습니다.
충돌이 자주 발생한다면 브랜치를 너무 오래 분리해둔 것입니다. main을 자주 pull 받아서 내 브랜치를 최신 상태로 유지하는 게 가장 좋은 예방책입니다. 작은 단위로 자주 merge하세요.
실수를 되돌리는 방법
Git의 가장 큰 장점은 실수를 되돌릴 수 있다는 것입니다. 패닉하지 마세요.
# 마지막 커밋 취소 (변경사항은 유지됨)
git reset --soft HEAD~1
# 작업 중인 변경사항을 임시 저장
git stash
# 임시 저장한 변경사항 복구
git stash pop
reset --soft는 커밋만 취소하고 코드는 그대로 둡니다. "커밋 메시지를 잘못 썼다"거나 "파일 하나를 빼먹고 커밋했다" 같은 상황에서 유용합니다.
stash는 "지금 작업 중인 걸 잠깐 서랍에 넣어두는 것"입니다. 갑자기 다른 브랜치에서 급한 버그를 고쳐야 할 때, 현재 작업을 stash로 보관하고, 버그를 고치고, 다시 stash pop으로 꺼내오면 됩니다. 개발하다 보면 이 패턴을 정말 자주 씁니다.
git reset --hard는 변경사항을 완전히 날려버리기 때문에 신중하게 써야 합니다. 확신이 없다면 항상 --soft가 안전합니다. 한 번 --hard로 날린 코드는 복구가 매우 어렵습니다.
지금 바로 시작하세요
오늘 당장 개인 프로젝트에 Git을 적용해보는 것이 가장 빠른 학습법입니다. git init 하나면 시작할 수 있습니다. README 하나 만들고, 커밋 하나 찍고, GitHub에 push하는 것까지 해보세요. 거기까지 했으면 이미 Git의 핵심 70%를 경험한 것입니다. 복잡한 워크플로우는 필요할 때 하나씩 배우면 됩니다.