git commit과 git push, 무엇이 다를까 — Git 초보가 먼저 잡아야 할 4단계 흐름
이 글에서 다루는 것
- Git이 Local과 Remote로 나뉘어 있다는 사실과 그 의미
- Working Directory → Staging → Local → Remote의 4단계 흐름
- 실제 작업에서
add,commit,push가 각각 어떤 역할을 하는지
들어가며
Git을 처음 배우는 사람이 가장 자주 부딪히는 질문이 있습니다. "분명히 commit 했는데 왜 GitHub에 코드가 보이지 않을까?" 결론부터 말하면, Git은 작업 공간을 Local(내 PC) 과 Remote(원격 저장소) 로 나누어 관리하기 때문입니다. commit은 내 PC 안에서 일어나는 일이고, GitHub로 보내려면 별도의 push 명령이 필요합니다.
이 글에서는 add, commit, push, pull 네 가지 명령이 어느 공간에서 어떤 일을 하는지 4단계 흐름으로 정리합니다. 흐름을 한 번 머릿속에 정리해 두면, 이후의 Git 사고는 대부분 예방할 수 있습니다.
핵심 개념: commit과 push는 별개의 단계
가장 헷갈리는 두 명령을 한 줄로 정리하면 다음과 같습니다.
commit은 내 PC 저장이고
push 해야 GitHub에 업로드된다다시 말해 commit은 변경 사항을 로컬 저장소(Local Repository) 에 기록하는 행위이고, push는 그 기록을 원격 저장소(Remote Repository) 로 전송하는 행위입니다. 둘은 별개의 단계라는 점을 먼저 받아들이는 것이 출발점입니다.
[!IMPORTANT]
commit이 끝났다고 GitHub에 자동으로 올라가지 않습니다. push 전에는 다른 사람이 내 작업을 볼 수 없습니다.
전체 구조 한눈에 보기
Git의 데이터는 다음 네 공간을 순서대로 이동합니다.
[Working Directory]
↓ git add
[Staging Area]
↓ git commit
[Local Repository]
↓ git push
[Remote Repository]각 공간이 어떤 역할을 하는지 차례로 살펴보겠습니다.
Working Directory
실제로 파일을 수정하는 공간입니다. 에디터에서 코드를 고치면 변경 사항은 일단 이곳에 머뭅니다.
Staging Area
커밋할 파일들을 임시로 등록하는 공간입니다. 모든 변경을 한 번에 커밋하지 않고, 필요한 파일만 골라 묶을 수 있도록 중간에 한 단계가 더 있다고 이해하면 됩니다.
Local Repository
내 PC 안의 Git 저장소입니다. git commit 명령으로 Staging Area의 내용이 이곳에 기록됩니다. 이 시점까지의 모든 작업은 내 컴퓨터 안에서만 일어납니다.
Remote Repository
GitHub처럼 인터넷 너머에 존재하는 원격 저장소입니다. git push를 실행해야 비로소 내 commit이 이곳으로 전송됩니다.
Git 명령어의 기본 형식
Git 명령은 대체로 다음과 같은 형식을 따릅니다.
git {명령어} {사용자입력값}예시로 다음 명령을 살펴봅니다.
git push origin main각 토큰의 의미는 이렇습니다.
push→ 업로드origin→ 원격 저장소 이름main→ 업로드 대상 브랜치
즉 "origin이라는 원격 저장소의 main 브랜치로 올린다"는 뜻이 됩니다. 명령어의 구조가 눈에 들어오면, 새로운 명령을 만나도 의미를 짐작할 수 있습니다.
실제 작업 흐름 따라가기
이번에는 파일 한 개를 수정해 GitHub로 보내기까지의 과정을 단계별로 따라가 보겠습니다.
1. 파일 수정
먼저 에디터에서 파일을 고칩니다.
app.js 수정이 시점의 변경 사항은 Working Directory에만 존재합니다.
2. add — 커밋 대상으로 등록
변경된 파일을 Staging Area에 올립니다.
git add app.js이제 app.js는 다음 커밋의 대상으로 등록되었습니다.
커밋 대상으로 등록3. commit — Local에 저장
Staging Area에 올린 변경 사항을 Local Repository에 기록합니다.
git commit -m "로그인 기능 추가"이 단계에서 작업 내역이 내 PC의 Git 히스토리에 남습니다.
내 PC(Local)에 저장4. push — Remote로 업로드
마지막으로 Local의 commit을 원격 저장소로 전송합니다.
git push origin main이제 다른 사람도 GitHub에서 내 변경 사항을 확인할 수 있습니다.
GitHub(Remote)에 업로드실무에서는 어떻게 사용할까
실무에서는 보통 다음과 같이 브랜치를 나누어 운영합니다.
main = 운영 안정 버전
dev = 개발 통합 버전
feature/* = 기능 개발 브랜치브랜치 트리로 보면 다음과 같은 구조가 됩니다.
main
└─ dev
├─ feature/login
├─ feature/payment
└─ feature/chat각 기능은 feature/* 브랜치에서 개발하고, 완성되면 dev에 통합합니다. 검증을 마친 dev의 내용을 최종적으로 main에 반영하는 방식입니다. 작은 팀에서도 main에서 직접 작업하지 않는 습관을 들이면, 운영 환경의 안정성을 지키는 데 큰 도움이 됩니다.
초보자가 자주 하는 실수
4단계 흐름을 모르면 다음과 같은 실수가 반복됩니다.
commit만 하고 push 안 함
commit은 Local 저장일 뿐이다.내 PC에는 변경 사항이 분명히 남아 있지만, GitHub에는 아무것도 올라가지 않은 상태입니다. "어제 분명 작업했는데 협업자가 못 본다고 한다" 같은 상황의 단골 원인입니다.
git add를 안 함
수정 파일이 커밋에 포함되지 않는다.git add를 거치지 않은 파일은 Staging Area에 없으므로 commit 대상에서 빠집니다. "분명 고쳤는데 커밋에 안 들어갔다"의 흔한 원인입니다.
main에서 직접 작업
운영 코드가 깨질 위험이 있다.main은 가능하면 안정된 상태로 유지하고, 새 작업은 별도 브랜치를 만들어 진행하는 편이 안전합니다.
Git 사고를 줄이는 습관 하나
명령을 실행하기 전 항상 현재 상태를 확인하는 습관을 들이는 것을 추천합니다.
git status이 명령은 어떤 파일이 수정되었고, 어떤 파일이 Staging Area에 올라가 있으며, 현재 브랜치가 무엇인지 알려 줍니다. 단순한 명령이지만, Git 사고의 상당수는 이 한 줄로 예방할 수 있습니다.
[!TIP]
add나commit,push를 실행하기 전에git status로 상태를 한 번 확인하는 습관만 들여도, "엉뚱한 파일이 올라갔다"는 사고를 크게 줄일 수 있습니다.
핵심 요약
지금까지 정리한 흐름을 한 표로 압축하면 다음과 같습니다.
| 명령어 | 데이터 이동 | 의미 |
|---|---|---|
git add |
Working → Staging | 커밋 대상 등록 |
git commit |
Staging → Local | 내 PC(Local) 저장 |
git push |
Local → Remote | GitHub 업로드 |
git pull |
Remote → Local | 최신 코드 가져오기 |
원문 표현으로 다시 한 번 묶으면 다음과 같습니다.
git add → 커밋 대상 등록
git commit → Local 저장
git push → GitHub 업로드
git pull → 최신 코드 가져오기마치며
Git은 단순히 코드를 저장하는 도구가 아닙니다.
안전하게 여러 작업을 동시에 관리하기 위한 시스템내 PC와 원격 저장소가 분리되어 있고, 그 사이에 Staging이라는 한 단계가 더 있다는 구조를 한 번 이해하고 나면, 앞으로 만날 대부분의 Git 명령이 자연스럽게 자리를 찾습니다. 다음 단계로는 브랜치 전략(Git Flow, GitHub Flow), git rebase, git stash 같은 명령을 익히면서 협업 환경에서의 활용을 넓혀가는 것을 권합니다.
참고 자료