git add와 git commit은 쓸 줄 알겠는데, rebase와 reset 앞에서 멈춘 경험이 있다면 이 글이 딱 필요한 시점입니다. 버전 관리는 혼자 코딩할 때도, 팀 협업을 할 때도 가장 기본이 되는 기술인데, 정작 “어떤 상황에 어떤 명령어를 써야 하는지” 헷갈리는 경우가 많습니다. 이 글에서는 실무에서 실제로 자주 쓰이는 Git 명령어 10가지를 개념부터 활용법, 주의사항까지 한번에 정리합니다.
Git은 왜 모든 개발자의 필수 도구인가?
Git은 소스 코드의 변경 이력을 추적하고, 여러 개발자가 동시에 같은 프로젝트를 안전하게 작업할 수 있게 해주는 분산 버전 관리 시스템입니다. Stack Overflow 개발자 설문(2024년 기준)에서 응답자의 93% 이상이 Git을 사용한다고 답했을 만큼, Git은 업계 표준이 된 지 오래입니다.
사이드 프로젝트를 시작하든, 팀 협업을 하든, 오픈소스에 기여하든 Git을 제대로 쓸 줄 아는 것은 개발자의 기본 역량입니다. 프론트엔드 개발을 막 시작했다면 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 # 특정 파일만 스테이징3. git commit — 변경사항을 이력으로 남기기
git commit은 스테이징된 변경사항을 저장소 이력에 영구 기록합니다. 커밋 메시지는 나중에 이력을 볼 때 변경 이유가 명확히 전달되도록 작성하는 것이 중요합니다.
bash
git commit -m "feat: 로그인 폼 유효성 검사 추가"팀 협업에서는 Conventional Commits 규칙(feat:, fix:, docs: 등)을 따르면 이력 파악이 훨씬 쉬워집니다.
4. git push / git pull — 원격 저장소와 동기화하기
git push는 로컬 커밋을 원격에 업로드하고, git pull은 원격의 최신 변경사항을 로컬로 가져옵니다.
bash
git push origin main # 로컬 커밋을 원격에 업로드
git pull origin main # 원격 최신 내용을 로컬로 가져오기브랜치와 병합, 협업의 핵심 명령어는?
혼자 작업할 때는 main 브랜치 하나로도 충분하지만, 팀 협업에서는 브랜치 전략이 협업 품질을 좌우합니다.
git branch와 git switch를 함께 써야 하는 이유는?
브랜치는 메인 코드에 영향을 주지 않고 독립적으로 기능을 개발할 수 있는 작업 공간입니다. Git 2.23 이전에는 git checkout 하나로 브랜치 이동과 파일 복원을 모두 처리했지만, 두 역할이 뒤섞여 혼란을 주는 경우가 많았습니다. Git 2.23부터 브랜치 이동에는 git switch, 파일 복원에는 git restore로 명확히 분리되었으므로 새로 배운다면 이 방식을 사용하는 것이 좋습니다.
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충돌이 발생한 파일을 열면 <<<<<<<, =======, >>>>>>> 마커로 충돌 구간이 표시됩니다. 원하는 내용으로 수정하고 마커를 제거한 뒤 다시 add → commit하면 병합이 완료됩니다.
임시 저장과 이력 관리, 어떻게 하면 좋을까?
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 그래프 형태로 확인할 수 있습니다. 더 다양한 포맷 옵션은 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로 복구를 시도해볼 수 있습니다. 더 자세한 내용은 GitHub Docs — 변경사항 되돌리기를 참고하세요.
자주 묻는 질문 (FAQ)
Q. git merge와 git rebase 중 팀 협업에서 어느 것을 써야 하나요?
두 명령어 모두 브랜치를 합치는 역할을 하지만 방식이 다릅니다. git merge는 병합 커밋을 만들어 두 브랜치가 합쳐진 이력을 그대로 보존하고, git rebase는 이력을 선형으로 재정리해 깔끔한 히스토리를 만듭니다. 하지만 rebase는 이미 원격에 push된 브랜치에서 사용하면 다른 팀원의 이력과 충돌을 일으킬 수 있습니다. 일반적인 팀 협업 원칙은 “원격 공유 브랜치는 merge, 로컬 브랜치 정리는 rebase”로 구분하는 것입니다.
Q. git reset의 --soft, --mixed, --hard는 어떻게 다른가요?
세 옵션 모두 커밋을 되돌리지만, 변경사항을 어디까지 보존하느냐가 다릅니다. --soft는 커밋만 취소하고 변경사항을 스테이징 영역에 유지합니다. --mixed(기본값)는 커밋을 취소하고 변경사항을 워킹 디렉터리에 남깁니다. --hard는 커밋과 변경사항을 모두 삭제합니다. --hard는 되돌릴 수 없으므로 사용 전에 반드시 확인하세요. 실수로 삭제했다면 git reflog로 복구를 시도할 수 있습니다.
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 자동화나 커밋 메시지 컨벤션을 도입해 팀의 협업 문화를 개선해 보는 것을 추천합니다.
