작성자: 컴맹 집사
대표 이미지: 저장·커밋·푸시는 포장하고 송장을 붙여 보내는 택배와 비슷하다 (사진: tama66 / Pixabay)
이 글에서 얻는 것
- 이런 분께 앱을 고치고 저장했는데 인터넷에 반영되지 않아 답답한 분
- 핵심 답 저장은 포장, 커밋은 송장을 붙여 접수, 푸시는 배송이다. 푸시까지 해야 고친 내용이 GitHub(인터넷)에 도착한다
- 바로 쓰는 팁 고쳤는데 그대로라면 저장에서 멈추지 않았는지, 커밋과 푸시까지 했는지부터 확인하자
나도 처음에는 커밋과 푸시가 같은 말인 줄 알았다. 둘 다 “올린다”는 뜻 아닌가? 게다가 파일은 이미 Ctrl+S로 저장했는데 왜 또 뭘 눌러야 하는지 이해가 안 됐다.
그 차이를 알게 된 건, 분명히 고쳤는데 아무것도 바뀌지 않은 날이었다.
고쳤는데 왜 그대로지?
강아지 앱의 질문 문구를 하나 고쳤다. “산책할 때 어떤가요?”를 “산책할 때 우리 아이는 어떤가요?”로. 메모장에서 저장하고, 내 컴퓨터에서 열어 보니 잘 바뀌어 있었다.
그런데 GitHub 웹사이트에 들어가 보니 예전 문구 그대로였다. 몇 번을 새로고침해도 마찬가지였다.
AI에게 물었다.
파일을 저장했는데 GitHub에는 반영이 안 돼. 왜 그래?
답은 짧았다. “저장만 하고 커밋과 푸시를 안 하셨네요.”
세 단계를 택배에 비유하면
AI가 해 준 택배 비유가 가장 이해하기 쉬웠다.
| 단계 | 하는 일 | 택배로 비유하면 |
|---|---|---|
| 저장 (Ctrl+S) | 내 컴퓨터의 파일을 고친다 | 물건을 포장한다 |
| 커밋 (Commit) | 바뀐 내용을 설명과 함께 기록한다 | 송장을 붙이고 접수한다 |
| 푸시 (Push) | 기록을 GitHub(인터넷)로 보낸다 | 택배 기사가 배송한다 |
포장만 해 두면 물건은 내 방에 그대로 있다. 접수를 해야 기록이 생기고, 배송이 되어야 상대방에게 도착한다. 나는 포장만 해 놓고 왜 도착을 안 하냐고 묻고 있었던 셈이다.
조금 더 정확하게
저장
메모장이나 코드 편집기에서 Ctrl+S를 누르는 것. 내 컴퓨터 안의 파일 내용만 바뀐다. GitHub는 이 사실을 모른다.
커밋(commit)
“지금 이 상태를 하나의 버전으로 기록해 줘”라는 뜻이다. (출처: Pro Git, 변경 사항 기록) 커밋할 때는 커밋 메시지라는 짧은 설명을 적는다. 예: 질문 1번 문구 수정.
중요한 점은 커밋이 아직 내 컴퓨터 안에서만 남는 기록이라는 것이다. 인터넷에는 아직 올라가지 않았다.
푸시(push)
내 컴퓨터에 쌓인 커밋들을 GitHub로 보내는 것. 푸시를 해야 비로소 GitHub 웹사이트에도 바뀐 내용이 보인다.
GitHub Desktop에서 실제로 누르는 순서
- 파일을 고치고 저장한다.
- GitHub Desktop을 열면 왼쪽 Changes 탭에 바뀐 파일이 보인다. 오른쪽에는 빨간색(지운 줄)과 초록색(추가한 줄)으로 무엇이 바뀌었는지 표시된다.
- 왼쪽 아래 Summary 칸에 커밋 메시지를 적는다. 예:
질문 1번 문구 수정 - Commit to main 버튼을 누른다. → 기록 완료
- 위쪽의 Push origin 버튼을 누른다. → GitHub로 전송 완료
맨 처음 한 번은 5번 자리에 Publish repository라는 버튼이 나온다. 아직 GitHub에 이 저장소가 없으니 “처음 올리기”를 하라는 뜻이다. 한 번 올리고 나면 그다음부터는 Push origin으로 바뀐다.
왜 굳이 커밋과 푸시를 나눠 놨을까
처음에는 버튼 하나로 합쳐 주면 편할 텐데 싶었다. 앱을 계속 고치면서 나눠 둔 이유를 알게 됐다.
1. 작은 단위로 기록할 수 있다.
질문 문구 수정 → 커밋, 버튼 색 변경 → 커밋, 결과 설명 수정 → 커밋. 이렇게 잘게 나눠 두면 나중에 “버튼 색 바꾼 것만 되돌리기”가 가능하다.
2. 인터넷이 없어도 기록은 남길 수 있다.
커밋은 내 컴퓨터 안에서 일어나니까, 인터넷이 없어도 할 수 있다. 푸시는 나중에 한꺼번에 해도 된다.
3. 푸시에는 결과가 따른다.
나중에 알게 된 가장 중요한 이유다. 앱을 인터넷에 배포한 뒤로는 푸시하는 순간 실제 앱이 바뀐다. 그래서 푸시는 충분히 확인한 다음에 하는 동작이 됐다. 이 이야기는 Vercel 글에서 이어진다.
커밋 메시지, 이렇게 쓰기로 했다
처음에는 커밋 메시지를 수정, ㅇㅇ, 1처럼 대충 썼다. 며칠 뒤 되돌릴 버전을 찾으려는데 전부 수정이라 어느 게 어느 건지 알 수가 없었다.
출처: 앱 저장소(GitHub)의 실제 기록을 정리해 직접 제작
그 뒤로 정한 규칙은 이렇다.
- 무엇을 했는지 한 줄로 쓴다:
결과 화면에 작위 설명 추가 - 왜 했는지가 중요하면 덧붙인다:
총집사가 안 나오는 문제 수정 - 유형별 작위 연결 조정 - 한 커밋에는 한 가지 변경만 담는다.
AI에게 코드 수정을 요청할 때 “이번 수정에 어울리는 커밋 메시지도 써 줘”라고 덧붙이면 알아서 적어 주기도 한다. 꽤 유용했다.
초보자가 자주 하는 실수
- 저장을 안 하고 커밋하려 한다. Changes 탭에 아무것도 안 뜨면 먼저 저장했는지 확인하자.
- 커밋만 하고 푸시를 잊는다. GitHub Desktop 위쪽 버튼에 숫자(↑1 같은)가 떠 있으면 아직 안 보낸 커밋이 있다는 뜻이다.
- 여러 가지를 한 커밋에 몰아넣는다. 문제가 생기면 전부 같이 되돌려야 한다.
되돌리기가 필요할 때
커밋을 잘게 해 두면 되돌리기도 쉽다. GitHub Desktop의 History 탭에서 되돌리고 싶은 커밋을 오른쪽 클릭하면 Revert changes in commit이라는 메뉴가 있다. 그 커밋에서 바꾼 내용만 거꾸로 되돌리는 새 커밋이 만들어진다. 되돌린 뒤에도 푸시를 해야 GitHub에 반영된다는 점은 똑같다.
처음 이 기능을 쓴 건 작위증 배경색을 바꿨다가 글자가 안 보이게 됐을 때였다. 배경색 변경 커밋만 되돌리고, 그 전에 한 질문 수정은 그대로 살릴 수 있었다. 여러 가지를 한 커밋에 몰았다면 불가능했을 일이다.
초보자 팁: 오늘 작업을 마칠 때는 GitHub Desktop 위쪽 버튼에 숫자가 남아 있지 않은지 확인하자. 보내지 않은 커밋이 남아 있으면 다음 날 헷갈린다.
이제는 이렇게 이해한다
저장은 나를 위한 것, 커밋은 기록을 위한 것, 푸시는 세상에 보내기 위한 것.
이 순서가 몸에 익고 나니 앱을 고치는 과정 전체가 정리됐다. 고친다 → 확인한다 → 커밋한다 → 푸시한다. 그리고 이 마지막 푸시가, 다음에 배울 Vercel과 연결되는 출발 신호가 됐다.
이전 글: 깃허브(GitHub)가 뭐길래? 코딩 몰라도 이해되는 앱 타임머신 이야기
다음 글: Vercel이 뭐길래 내 앱에 주소가 생겼을까? 배포 서비스 쉬운 설명
