[태그:] commit

작성자: 컴맹 집사

대표 이미지: 저장·커밋·푸시는 포장하고 송장을 붙여 보내는 택배와 비슷하다 (사진: tama66 / Pixabay)

나도 처음에는 커밋과 푸시가 같은 말인 줄 알았다. 둘 다 “올린다”는 뜻 아닌가? 게다가 파일은 이미 Ctrl+S로 저장했는데 왜 또 뭘 눌러야 하는지 이해가 안 됐다.

그 차이를 알게 된 건, 분명히 고쳤는데 아무것도 바뀌지 않은 날이었다.

고쳤는데 왜 그대로지?

강아지 앱의 질문 문구를 하나 고쳤다. “산책할 때 어떤가요?”를 “산책할 때 우리 아이는 어떤가요?”로. 메모장에서 저장하고, 내 컴퓨터에서 열어 보니 잘 바뀌어 있었다.

그런데 GitHub 웹사이트에 들어가 보니 예전 문구 그대로였다. 몇 번을 새로고침해도 마찬가지였다.

AI에게 물었다.

파일을 저장했는데 GitHub에는 반영이 안 돼. 왜 그래?

답은 짧았다. “저장만 하고 커밋과 푸시를 안 하셨네요.”

세 단계를 택배에 비유하면

AI가 해 준 택배 비유가 가장 이해하기 쉬웠다.

단계	하는 일	택배로 비유하면
저장 (Ctrl+S)	내 컴퓨터의 파일을 고친다	물건을 포장한다
커밋 (Commit)	바뀐 내용을 설명과 함께 기록한다	송장을 붙이고 접수한다
푸시 (Push)	기록을 GitHub(인터넷)로 보낸다	택배 기사가 배송한다

포장만 해 두면 물건은 내 방에 그대로 있다. 접수를 해야 기록이 생기고, 배송이 되어야 상대방에게 도착한다. 나는 포장만 해 놓고 왜 도착을 안 하냐고 묻고 있었던 셈이다.

조금 더 정확하게

저장

메모장이나 코드 편집기에서 Ctrl+S를 누르는 것. 내 컴퓨터 안의 파일 내용만 바뀐다. GitHub는 이 사실을 모른다.

커밋(commit)

“지금 이 상태를 하나의 버전으로 기록해 줘”라는 뜻이다. (출처: Pro Git, 변경 사항 기록) 커밋할 때는 커밋 메시지라는 짧은 설명을 적는다. 예: 질문 1번 문구 수정.

중요한 점은 커밋이 아직 내 컴퓨터 안에서만 남는 기록이라는 것이다. 인터넷에는 아직 올라가지 않았다.

푸시(push)

내 컴퓨터에 쌓인 커밋들을 GitHub로 보내는 것. 푸시를 해야 비로소 GitHub 웹사이트에도 바뀐 내용이 보인다.

GitHub Desktop에서 실제로 누르는 순서

1. 파일을 고치고 저장한다.
2. GitHub Desktop을 열면 왼쪽 Changes 탭에 바뀐 파일이 보인다. 오른쪽에는 빨간색(지운 줄)과 초록색(추가한 줄)으로 무엇이 바뀌었는지 표시된다.
3. 왼쪽 아래 Summary 칸에 커밋 메시지를 적는다. 예: 질문 1번 문구 수정
4. Commit to main 버튼을 누른다. → 기록 완료
5. 위쪽의 Push origin 버튼을 누른다. → GitHub로 전송 완료

맨 처음 한 번은 5번 자리에 Publish repository라는 버튼이 나온다. 아직 GitHub에 이 저장소가 없으니 “처음 올리기”를 하라는 뜻이다. 한 번 올리고 나면 그다음부터는 Push origin으로 바뀐다.

왜 굳이 커밋과 푸시를 나눠 놨을까

처음에는 버튼 하나로 합쳐 주면 편할 텐데 싶었다. 앱을 계속 고치면서 나눠 둔 이유를 알게 됐다.

1. 작은 단위로 기록할 수 있다.
질문 문구 수정 → 커밋, 버튼 색 변경 → 커밋, 결과 설명 수정 → 커밋. 이렇게 잘게 나눠 두면 나중에 “버튼 색 바꾼 것만 되돌리기”가 가능하다.

2. 인터넷이 없어도 기록은 남길 수 있다.
커밋은 내 컴퓨터 안에서 일어나니까, 인터넷이 없어도 할 수 있다. 푸시는 나중에 한꺼번에 해도 된다.

3. 푸시에는 결과가 따른다.
나중에 알게 된 가장 중요한 이유다. 앱을 인터넷에 배포한 뒤로는 푸시하는 순간 실제 앱이 바뀐다. 그래서 푸시는 충분히 확인한 다음에 하는 동작이 됐다. 이 이야기는 Vercel 글에서 이어진다.

커밋 메시지, 이렇게 쓰기로 했다

처음에는 커밋 메시지를 수정, ㅇㅇ, 1처럼 대충 썼다. 며칠 뒤 되돌릴 버전을 찾으려는데 전부 수정이라 어느 게 어느 건지 알 수가 없었다.

그 뒤로 정한 규칙은 이렇다.

• 무엇을 했는지 한 줄로 쓴다: 결과 화면에 작위 설명 추가
• 왜 했는지가 중요하면 덧붙인다: 총집사가 안 나오는 문제 수정 - 유형별 작위 연결 조정
• 한 커밋에는 한 가지 변경만 담는다.

AI에게 코드 수정을 요청할 때 “이번 수정에 어울리는 커밋 메시지도 써 줘”라고 덧붙이면 알아서 적어 주기도 한다. 꽤 유용했다.

초보자가 자주 하는 실수

• 저장을 안 하고 커밋하려 한다. Changes 탭에 아무것도 안 뜨면 먼저 저장했는지 확인하자.
• 커밋만 하고 푸시를 잊는다. GitHub Desktop 위쪽 버튼에 숫자(↑1 같은)가 떠 있으면 아직 안 보낸 커밋이 있다는 뜻이다.
• 여러 가지를 한 커밋에 몰아넣는다. 문제가 생기면 전부 같이 되돌려야 한다.

되돌리기가 필요할 때

커밋을 잘게 해 두면 되돌리기도 쉽다. GitHub Desktop의 History 탭에서 되돌리고 싶은 커밋을 오른쪽 클릭하면 Revert changes in commit이라는 메뉴가 있다. 그 커밋에서 바꾼 내용만 거꾸로 되돌리는 새 커밋이 만들어진다. 되돌린 뒤에도 푸시를 해야 GitHub에 반영된다는 점은 똑같다.

처음 이 기능을 쓴 건 작위증 배경색을 바꿨다가 글자가 안 보이게 됐을 때였다. 배경색 변경 커밋만 되돌리고, 그 전에 한 질문 수정은 그대로 살릴 수 있었다. 여러 가지를 한 커밋에 몰았다면 불가능했을 일이다.

초보자 팁: 오늘 작업을 마칠 때는 GitHub Desktop 위쪽 버튼에 숫자가 남아 있지 않은지 확인하자. 보내지 않은 커밋이 남아 있으면 다음 날 헷갈린다.

이제는 이렇게 이해한다

저장은 나를 위한 것, 커밋은 기록을 위한 것, 푸시는 세상에 보내기 위한 것.

이 순서가 몸에 익고 나니 앱을 고치는 과정 전체가 정리됐다. 고친다 → 확인한다 → 커밋한다 → 푸시한다. 그리고 이 마지막 푸시가, 다음에 배울 Vercel과 연결되는 출발 신호가 됐다.

---

이전 글: 깃허브(GitHub)가 뭐길래? 코딩 몰라도 이해되는 앱 타임머신 이야기
다음 글: Vercel이 뭐길래 내 앱에 주소가 생겼을까? 배포 서비스 쉬운 설명