commit, push, pull이 뭐예요? 내 코드가 GitHub를 오가는 방법

바이브코딩을 하다 보면 AI가 이런 말을 합니다.

변경 내용을 커밋했습니다.
GitHub에 push했습니다.
먼저 최신 내용을 pull하겠습니다.

기능은 잘 만들어진 것 같은데 갑자기 영어 단어가 연달아 나옵니다. commit과 push가 모두 “저장”처럼 들리고, pull은 무엇을 어디에서 가져온다는 뜻인지 헷갈려요.

핵심부터 보면 세 단어는 코드가 오가는 방향을 설명합니다.

내 컴퓨터
→ commit으로 변경 기록 만들기
→ push로 GitHub에 올리기

GitHub
→ pull로 최신 기록 받기
→ 내 컴퓨터

이 흐름을 이해하면 “내 컴퓨터에서는 잘 되는데 왜 배포한 앱은 그대로지?” 같은 문제도 훨씬 쉽게 풀 수 있습니다.

먼저 Git과 GitHub는 달라요

Git은 내 코드의 변경 내용을 기록하는 도구입니다. 어떤 파일을 바꿨는지, 어느 시점에 무엇을 완성했는지 차곡차곡 남겨요.

GitHub는 Git으로 만든 기록을 인터넷에 보관하는 서비스입니다. 내 컴퓨터가 아닌 온라인 공간에 기록을 올려두면 배포 서비스가 코드를 가져갈 수 있고, 다른 컴퓨터나 함께 일하는 사람도 같은 기록을 볼 수 있어요.

Git
→ 내 컴퓨터에서 변경 기록을 관리

GitHub
→ 변경 기록을 온라인에 보관

Git과 GitHub를 사용하는 이유부터 알고 싶다면 Git과 GitHub를 꼭 써야 하는 이유를 먼저 읽어도 좋습니다.

Git을 처음 사용하는 컴퓨터라면 첫 commit 전에 작성자 정보가 필요할 수 있습니다. 왜 이름과 이메일을 설정하는지는 Git 최초 작성자 설정 글에서 설명합니다.

파일 저장은 commit이 아니에요

문서 작업을 떠올려볼게요. 글자를 고치고 저장 버튼을 누르면 파일의 내용이 바뀝니다. 코드도 마찬가지예요. AI가 코드를 수정하면 내 컴퓨터의 파일이 바뀌고, localhost는 바뀐 파일을 바로 읽습니다.

하지만 파일을 저장했다고 Git의 변경 기록까지 생기지는 않습니다.

파일 저장
→ 현재 파일의 내용을 바꿈

commit
→ 여러 변경을 하나의 작업 기록으로 묶음

예를 들어 신청 폼의 전화번호 오류를 고쳤다면 다음처럼 기록할 수 있어요.

전화번호 입력 오류 수정

이 설명과 함께 관련 파일의 변경 내용을 묶은 기록 하나가 commit입니다. 나중에 무엇을 왜 바꿨는지 찾거나, 문제가 생기기 전 상태와 비교할 때 사용할 수 있어요.

commit은 작업 단위로 남기는 기록이에요

commit은 단순히 모든 파일을 한꺼번에 저장하는 버튼이 아닙니다. 하나의 작업을 이해할 수 있는 단위로 묶는 과정이에요.

좋은 작업 단위
→ 신청 폼 전화번호 오류 수정

서로 다른 작업을 한꺼번에 묶은 상태
→ 로그인 수정 + 색상 변경 + 테스트 파일 삭제

하나의 commit에 관련 없는 변경을 많이 섞으면 나중에 무엇 때문에 문제가 생겼는지 찾기 어렵습니다. 그래서 commit하기 전에 이번 작업과 관련된 파일을 고르는 과정이 있어요. 개발자는 이 과정을 add 또는 스테이징이라고 부릅니다. 실제로 언제 기록을 남기면 좋은지는 commit하기 좋은 순간을 정하는 기준에서 사례별로 설명했습니다.

입문자가 명령어와 순서를 외울 필요는 없습니다. AI에게 다음처럼 요청하면 됩니다.

현재 바뀐 파일을 확인하고 이번 신청 폼 수정과 관련된 변경만 알려줘.
관계없는 변경은 빼고 어떤 내용을 commit할지 먼저 설명해줘.
확인하기 전에는 commit하지 마.

AI가 보여준 파일과 설명을 확인한 뒤 commit을 맡기면 됩니다.

commit은 아직 내 컴퓨터에만 있어요

여기서 가장 많이 헷갈립니다.

commit을 만들었다고 GitHub에 올라간 것은 아닙니다.

commit은 먼저 내 컴퓨터의 Git 기록에 생깁니다. 인터넷이 연결되지 않아도 commit을 만들 수 있어요.

파일 수정
→ 내 컴퓨터의 파일이 바뀜

commit
→ 내 컴퓨터의 Git 기록에 남음

아직 GitHub에는 없음

AI가 “커밋했습니다”라고 말한 뒤 작업을 끝냈다면 GitHub에는 이전 코드만 있을 수 있습니다. GitHub와 연결한 배포 서비스도 이전 코드를 보게 돼요.

push는 commit을 GitHub에 올리는 일이에요

push는 내 컴퓨터에 쌓인 commit을 GitHub로 보냅니다.

내 컴퓨터의 commit
→ push
→ GitHub

처음 push할 때 로그인이나 PAT, SSH 키 안내가 나타날 수 있습니다. 이는 GitHub 저장소에 접근할 권한을 확인하는 과정이에요. 각각 무엇을 의미하는지는 GitHub 인증이 필요한 이유에서 확인할 수 있습니다.

배포 서비스를 GitHub와 연결했다면 push가 중요한 출발점이 됩니다. 배포 서비스는 보통 GitHub에 새 commit이 들어왔을 때 새 버전을 만들기 시작해요.

commit만 함
→ 내 컴퓨터에는 최신 기록이 있음
→ GitHub에는 없음
→ 새 배포가 시작되지 않음

push까지 함
→ GitHub에도 최신 기록이 있음
→ 배포 서비스가 새 버전을 만들 수 있음

따라서 “내 컴퓨터에서는 수정한 기능이 되는데 배포한 앱에서는 안 된다”면 commit과 push를 모두 마쳤는지 확인해야 합니다. 전체 점검 순서는 내 컴퓨터에서는 되는데 배포하면 안 될 때 확인할 것에서 살펴볼 수 있어요.

pull은 GitHub의 최신 commit을 받는 일이에요

push가 내 컴퓨터에서 GitHub로 보내는 방향이라면 pull은 반대입니다.

GitHub의 최신 commit
→ pull
→ 내 컴퓨터

다른 컴퓨터에서 코드를 수정했거나, GitHub에서 파일을 바꿨거나, 함께 일하는 사람이 새 commit을 올렸다면 내 컴퓨터의 코드는 GitHub보다 오래된 상태일 수 있어요. pull하면 GitHub의 최신 변경을 내 작업 폴더에 반영합니다.

한 컴퓨터에서 혼자 작업할 때는 push보다 pull을 덜 만날 수도 있습니다. 그래도 AI가 작업을 시작하기 전에 “최신 내용을 먼저 받겠습니다”라고 말한다면 GitHub와 내 컴퓨터의 차이를 맞추려는 과정이라고 이해하면 됩니다.

pull하기 전에 내 변경부터 확인해야 해요

GitHub와 내 컴퓨터에서 같은 파일의 같은 부분을 서로 다르게 바꿨다면 Git이 어느 내용을 선택할지 바로 결정하지 못할 수 있습니다.

이때는 무작정 pull하거나 내 파일을 덮어쓰기보다, 아직 commit하지 않은 변경이 있는지 먼저 확인해야 해요.

내 컴퓨터에 아직 기록하지 않은 변경이 있음
+ GitHub에도 새로운 변경이 있음
→ 먼저 차이를 확인

AI에게 다음처럼 요청해보세요.

GitHub의 최신 내용을 받기 전에 내 컴퓨터에 아직 commit하지 않은 변경이 있는지 확인해줘.
내 변경을 잃을 위험이 있다면 pull하지 말고 상황부터 쉽게 설명해줘.
파일을 강제로 덮어쓰지 마.

여러 사람이 같은 코드를 고치면서 생기는 충돌과 해결 방법은 이후 협업 글에서 별도로 다룰게요.

저장, commit, push는 모두 다른 일이에요

세 단계를 한 줄로 놓으면 차이가 선명해집니다.

저장
→ 내 컴퓨터의 파일 내용을 바꿈

commit
→ 바뀐 내용을 하나의 작업 기록으로 남김

push
→ 작업 기록을 GitHub에 올림

GitHub에서 내 컴퓨터로 오는 방향에는 pull이 있습니다.

pull
→ GitHub의 최신 작업 기록을 내 컴퓨터에 반영

그래서 다음 문장은 서로 다른 상태를 뜻해요.

• “파일을 고쳤어요” — 내 컴퓨터의 파일만 달라졌을 수 있습니다.
• “commit했어요” — 내 컴퓨터에 변경 기록을 만들었습니다.
• “push했어요” — GitHub에도 변경 기록을 올렸습니다.
• “pull했어요” — GitHub의 최신 변경을 내 컴퓨터에 반영했습니다.

바이브코딩에서는 상태를 먼저 물어보세요

명령어보다 중요한 것은 지금 코드가 어디까지 이동했는지 아는 일입니다. AI에게 “알아서 GitHub에 올려줘”라고만 하면 무엇을 commit했고 어디까지 push했는지 놓치기 쉬워요.

다음처럼 상태와 범위를 먼저 확인하세요.

현재 바뀐 파일을 확인해줘.
이번 작업과 관련된 변경만 묶어서 commit할 내용을 먼저 설명해줘.
내가 확인하면 commit하고 GitHub에 push해줘.
완료한 뒤 commit과 push가 각각 성공했는지 알려줘.
비밀값이 든 파일은 포함하지 마.

GitHub의 최신 내용을 받아야 할 때는 이렇게 요청할 수 있습니다.

pull하기 전에 내 컴퓨터에 저장하지 않았거나 commit하지 않은 변경이 있는지 확인해줘.
안전하다고 확인한 뒤에만 최신 내용을 받아줘.

AI가 작업을 대신해도 commit과 push의 경계는 알아두는 편이 좋습니다. 그래야 “고친 코드는 내 컴퓨터에만 있는지, GitHub까지 갔는지, 배포까지 이어졌는지”를 정확히 물을 수 있어요.

정리

• 파일 저장은 현재 코드의 내용을 바꾸는 일입니다.
• commit은 관련된 변경을 하나의 작업 기록으로 묶는 일입니다.
• commit은 먼저 내 컴퓨터에만 생깁니다.
• push는 내 컴퓨터의 commit을 GitHub에 올립니다.
• pull은 GitHub의 최신 commit을 내 컴퓨터에 반영합니다.
• 명령어를 외우기보다 AI에게 현재 상태와 작업 범위를 먼저 확인시키세요.
• commit하기 전에는 포함할 파일을, pull하기 전에는 아직 기록하지 않은 변경을 확인해야 합니다.

가장 중요한 한 줄만 기억하면 됩니다.

저장 ≠ commit ≠ push

내 컴퓨터에서 기능을 고쳤는데 실제 사이트가 바뀌지 않았다면 “push까지 했나요?”부터 확인해보세요.