팀에 처음 합류하던 날, 선임 개발자가 “PR 올리기 전에 rebase 하고 올려줘”라고 했을 때 속으로 패닉이 왔던 기억이 있습니다. git add와 git commit은 자신 있었는데, rebase라는 단어 앞에서 화면을 뚫어지게 바라봤죠. 그 당시 이런 글이 있었더라면 훨씬 빠르게 팀 흐름에 합류할 수 있었을 텐데요.
이 글에서는 실무에서 실제로 자주 쓰이는 Git 명령어 10가지를 개념, 사용법, 그리고 “이 상황에서 쓰면 안 되는” 주의사항까지 한번에 정리합니다. 현재 Git 최신 안정 버전은 2.51(2025년 8월 기준)이며, 이 글의 모든 내용은 해당 버전 기준으로 작성되었습니다.
Git은 왜 모든 개발자의 필수 도구인가?
Git은 소스 코드의 변경 이력을 추적하고, 여러 개발자가 동시에 같은 프로젝트를 안전하게 작업할 수 있게 해주는 분산 버전 관리 시스템입니다. Stack Overflow 개발자 설문(2022년)에서는 “Git만큼 광범위하게 사용되는 기술은 없다”고 명시했을 만큼, Git은 업계 표준이 된 지 오래입니다.
한 가지 반가운 소식도 있습니다. 현재 개발 중인 Git 3.0은 2026년 말 출시를 목표로 하고 있는데, 가장 큰 변화는 기본 해시 알고리즘이 SHA-1에서 SHA-256으로 전환된다는 점입니다. Git 2.51에서 이미 SHA-256이 기본값으로 준비되고 있으므로, 지금부터 알아두면 좋습니다. 다만 현재는 GitHub 등 주요 플랫폼이 SHA-256을 완전 지원하지 않아 실무 전환은 아직 이르고, 일반 사용자는 당장 체감할 변화가 거의 없습니다.
프론트엔드 개발을 막 시작했다면 2026년 프론트엔드 개발자 로드맵에서도 Git이 가장 먼저 나오는 이유가 여기에 있습니다.
기본 Git 명령어 4가지: 저장소 생성부터 원격 동기화까지
Git 작업의 핵심 흐름은 로컬에서 변경 → 스테이징 → 커밋 → 원격 동기화입니다. 이 흐름을 담당하는 4가지 명령어를 먼저 익혀두세요.
1. git init / git clone — 저장소 시작하기
git init은 현재 디렉터리를 Git 저장소로 초기화하고, git clone은 GitHub 등의 원격 저장소를 로컬로 복사합니다. 신규 프로젝트를 처음 시작할 때는 git init, 기존 프로젝트에 참여할 때는 git clone을 사용합니다.
bash
git init # 현재 디렉터리를 Git 저장소로 초기화
git clone https://github.com/user/project.git # 원격 저장소 복제2. git add — 변경사항을 스테이징하기
git add는 변경된 파일을 “스테이징 영역”에 올려두는 명령어입니다. 커밋할 파일을 선별할 수 있어, 관련 없는 변경사항을 분리해서 커밋할 때 유용합니다.
bash
git add . # 변경된 파일 전체 스테이징
git add src/App.tsx # 특정 파일만 스테이징
git add -p # 변경사항을 hunk 단위로 선택해서 스테이징git add -p는 팀 코드리뷰에서 실제로 많이 활용합니다. 하나의 파일을 수정하다가 두 가지 목적의 변경이 섞였을 때, 변경 덩어리(hunk)를 골라서 커밋을 깔끔하게 나눌 수 있어서 유용합니다.
3. git commit — 변경사항을 이력으로 남기기
git commit은 스테이징된 변경사항을 저장소 이력에 영구 기록합니다. 커밋 메시지는 나중에 이력을 볼 때 변경 이유가 명확히 전달되도록 작성하는 것이 중요합니다.
bash
git commit -m "feat: 로그인 폼 유효성 검사 추가"팀 협업에서는 Conventional Commits 규칙(feat:, fix:, docs: 등)을 따르면 이력 파악이 훨씬 쉬워집니다. CHANGELOG 자동 생성 도구도 이 컨벤션을 기반으로 동작합니다.
4. git push / git pull — 원격 저장소와 동기화하기
git push는 로컬 커밋을 원격에 업로드하고, git pull은 원격의 최신 변경사항을 로컬로 가져옵니다.
bash
git push origin main # 로컬 커밋을 원격에 업로드
git pull origin main # 원격 최신 내용을 로컬로 가져오기git pull은 내부적으로 git fetch + git merge를 실행합니다. 병합 커밋 없이 이력을 깔끔하게 유지하고 싶다면 git pull --rebase를 습관화하는 것도 좋은 방법입니다.
브랜치와 병합, 협업의 핵심 명령어는?
혼자 작업할 때는 main 브랜치 하나로도 충분하지만, 팀 협업에서는 브랜치 전략이 협업 품질을 좌우합니다.
git branch와 git switch를 함께 써야 하는 이유는?
브랜치는 메인 코드에 영향을 주지 않고 독립적으로 기능을 개발할 수 있는 작업 공간입니다. Git 2.23(2019년)부터 브랜치 이동은 git switch, 파일 복원은 git restore로 역할이 명확히 분리되었습니다. 기존의 git checkout은 두 역할을 모두 수행하다 보니 혼란을 주는 경우가 많았거든요. 이제 5년 이상 지난 변경 사항이라 현재 팀에서도 대부분 switch를 기본으로 사용하고 있으니, 새로 배운다면 처음부터 이 방식으로 익히는 것이 좋습니다.
bash
git branch feature/login # 새 브랜치 생성
git switch feature/login # 브랜치로 이동
git switch -c feature/login # 생성 + 이동 한번에
git branch -d feature/login # 브랜치 삭제 (병합 완료 후)GitLens처럼 브랜치 이력을 시각적으로 보여주는 확장을 활용하면 훨씬 편리합니다. 유용한 VS Code 확장이 궁금하다면 프론트엔드 개발자가 반드시 써야 할 VS Code 확장 프로그램 10가지도 참고해 보세요.
merge 충돌이 발생하면 어떻게 해결해야 할까?
git merge는 두 브랜치를 하나로 합칩니다. 같은 파일의 같은 줄이 각 브랜치에서 다르게 수정되었을 때 충돌(conflict)이 발생하며, 이를 직접 해결해야 합니다.
bash
git switch main
git merge feature/login
# 충돌 발생 시: 해당 파일 수동 수정 후 git add → git commit충돌이 발생한 파일을 열면 <<<<<<<, =======, >>>>>>> 마커로 충돌 구간이 표시됩니다. 원하는 내용으로 수정하고 마커를 제거한 뒤 다시 add → commit하면 병합이 완료됩니다. VS Code의 내장 병합 편집기를 사용하면 이 과정이 훨씬 직관적입니다.
임시 저장과 이력 관리, 어떻게 하면 좋을까?
git stash는 언제 사용해야 할까?
git stash는 커밋하지 않은 현재 작업을 임시 저장 공간에 보관하고, 워킹 디렉터리를 즉시 깨끗한 상태로 만들어 줍니다. 기능 개발 중 갑자기 긴급 버그 수정이 생겼을 때 가장 빛을 발하는 명령어입니다.
사이드 프로젝트를 진행하다 프로덕션 장애 알림이 온 상황에서 stash를 처음 제대로 활용해봤는데, 그때 이후로 작업 중간에 브랜치를 전환할 일이 생기면 반사적으로 손이 가는 명령어가 되었습니다.
bash
git stash # 현재 작업 임시 저장
git stash pop # 가장 최근 stash 꺼내기
git stash list # 저장된 stash 목록 확인
git stash save "작업 설명" # 이름 붙여서 저장
git stash drop stash@{1} # 특정 stash 삭제git log로 이력을 시각화하는 방법은?
git log는 저장소의 커밋 이력을 시간순으로 출력합니다. 기본 출력은 다소 길지만, 옵션을 조합하면 브랜치 흐름까지 한눈에 파악할 수 있습니다.
bash
git log --oneline --graph --all이 한 줄로 브랜치 분기와 병합 이력을 ASCII 그래프 형태로 확인할 수 있습니다. 팀에서 이력을 확인하러 GitLens나 GitHub 웹으로 가기 전에, 터미널에서 이 명령어 하나로 빠르게 파악하는 습관을 들이면 일이 꽤 빨라집니다. 더 다양한 포맷 옵션은 Git 공식 문서의 git-log 레퍼런스에서 확인할 수 있습니다.
rebase와 reset, 어떻게 다르고 언제 써야 할까?
git rebase를 사용하면 커밋 이력이 어떻게 달라질까?
git rebase는 현재 브랜치의 커밋들을 다른 브랜치의 끝으로 재배치하여 선형적인 이력을 만듭니다. merge는 병합 커밋이 추가되는 반면, rebase는 마치 처음부터 해당 브랜치 위에서 작업한 것처럼 이력이 정리됩니다.
bash
git switch feature/login
git rebase main # main의 최신 커밋 위로 이력 재배치단, 이미 원격에 push된 브랜치에서는 rebase를 사용하지 않는 것이 원칙입니다. 이력이 다시 쓰이면서 다른 팀원의 이력과 충돌이 생길 수 있기 때문입니다. “로컬 브랜치 정리 시 rebase, 공유 브랜치 합칠 때 merge”로 구분해서 사용하는 것이 일반적인 팀 협업 기준입니다.
git reset과 git revert 중 무엇을 선택해야 할까?
둘 다 커밋을 되돌리는 명령어이지만, 방식이 완전히 다릅니다. git revert는 이전 커밋을 취소하는 새 커밋을 생성하여, 공유 브랜치에서도 이력을 안전하게 되돌립니다. 반면 git reset은 이력 자체를 삭제하므로 원격에 push하지 않은 로컬 작업에서만 사용해야 합니다.
git reset 옵션별 차이는 다음과 같습니다.
bash
git reset --soft HEAD~1 # 커밋만 취소, 변경사항 스테이징 영역 유지
git reset --mixed HEAD~1 # 커밋 취소, 변경사항 워킹 디렉터리 유지 (기본값)
git reset --hard HEAD~1 # 커밋 + 변경사항 완전 삭제공유 브랜치에서 커밋을 되돌릴 때는 git revert를 사용합니다.
bash
git revert abc1234 # 특정 커밋을 되돌리는 새 커밋 생성| 구분 | 이력 변경 방식 | 원격 사용 안전 여부 | 주요 용도 |
|---|---|---|---|
| git reset | 이력 삭제 | 불가 | 로컬 실수 수정 |
| git revert | 새 커밋 추가 | 가능 | 공유 브랜치 되돌리기 |
실수로 git reset --hard를 실행했다면 git reflog로 복구를 시도해볼 수 있습니다. git reflog는 HEAD가 가리켰던 모든 위치의 이력을 보관하기 때문에, --hard로 날린 커밋도 일정 기간 내에는 되살릴 수 있습니다. 더 자세한 내용은 GitHub Docs — 변경사항 되돌리기를 참고하세요.
자주 묻는 질문 (FAQ)
Q. git pull과 git fetch는 어떻게 다른가요?
git fetch는 원격 저장소의 변경사항을 로컬로 가져오지만, 현재 작업 중인 브랜치에는 자동으로 반영하지 않습니다. 반면 git pull은 fetch + merge를 한번에 실행해서 즉시 반영합니다. 변경사항을 먼저 확인하고 직접 합치고 싶다면 fetch → git log origin/main → merge 순서로 작업하는 방법도 있습니다. 팀 규모가 크거나 main 브랜치가 자주 바뀌는 프로젝트라면 이 방식이 더 안전합니다.
Q. git merge와 git rebase 중 팀 협업에서 어느 것을 써야 하나요?
git merge는 병합 커밋을 만들어 두 브랜치가 합쳐진 이력을 그대로 보존하고, git rebase는 이력을 선형으로 재정리해 깔끔한 히스토리를 만듭니다. 하지만 rebase는 이미 원격에 push된 브랜치에서 사용하면 다른 팀원의 이력과 충돌을 일으킬 수 있습니다. 일반적인 팀 협업 원칙은 “원격 공유 브랜치는 merge, 로컬 브랜치 정리는 rebase”로 구분하는 것입니다. 팀 초반에 이 기준을 명문화해두면 나중에 불필요한 충돌을 피할 수 있습니다.
Q. git stash를 여러 번 사용했을 때 어떻게 관리하나요?
git stash list를 실행하면 저장된 목록이 stash@{0}, stash@{1} 형태로 출력됩니다. 특정 stash를 꺼내려면 git stash pop stash@{1}, 삭제하려면 git stash drop stash@{1}을 사용합니다. stash가 쌓이면 나중에 뭘 저장해둔 건지 헷갈리기 쉽습니다. git stash save "로그인 폼 임시 저장" 처럼 설명을 붙이는 습관을 들이면 큰 도움이 됩니다.
Git, 어떻게 빠르게 익힐 수 있을까?
Git 명령어는 외워서 익히는 것보다 직접 프로젝트에 적용하면서 체득하는 것이 가장 빠릅니다. git init으로 개인 프로젝트를 만들고, 브랜치를 나눠 기능을 추가해보고, rebase와 reset을 직접 실험해 보세요. 처음에 실수해도 괜찮습니다. 앞서 말한 것처럼 git reflog는 대부분의 실수를 복구할 수 있게 해줍니다.
이 글에서 다룬 10가지 명령어에 익숙해졌다면, 다음 단계로는 GitHub Actions를 활용한 CI/CD 자동화나 커밋 메시지 컨벤션을 도입해 팀의 협업 문화를 개선해 보는 것을 추천합니다.
