— git commit을 하지 않으면, 그 코드는 존재하지 않는다
버튼 하나를 바꿨다.
식사 기록 목록 화면에서
‘새 식사 기록’ 버튼을 ‘홈으로’ 링크로 바꿨다.
로컬에서는 잘 보였다.
웹에서도 문제없었다.
그래서 bin/deploy를 실행했다.
그런데 모바일에서는
여전히 예전 버튼이 그대로 보였다.
“왜지?”
코드는 분명 바뀌었는데
서버는 모른 척을 하고 있었다.
⸻
내가 하고 있던 착각
나는 이렇게 생각하고 있었다.
• 파일을 저장했으니 변경된 것이다
• 배포를 했으니 서버에 반영됐을 것이다
• GitHub 저장소도 없는데, Git이 뭐 그리 중요할까
하지만 이 셋 다
배포의 세계에서는 틀린 생각이었다.
⸻
결정적인 한 줄
그 순간 이 문장을 들었다.
“git commit을 하지 않으면,
그 코드는 배포되지 않습니다.”
처음엔 당연한 말처럼 들렸는데
곱씹어 보니 전혀 당연하지 않았다.
나는 GitHub도 만들지 않았고
어딘가에 push한 적도 없었기 때문이다.
그런데도 배포는
commit을 기준으로만 이루어지고 있었다.
⸻
GitHub가 없어도 Git은 완전하다
이제야 분리해서 이해하게 됐다.
• Git은
내 컴퓨터 안에서 코드의 역사를 관리하는 도구다.
• GitHub는
그 역사를 외부에 보관하거나 공유하는 장소일 뿐이다.
즉,
GitHub는 없어도 Git은 동작한다.
그리고 배포 도구는
GitHub가 아니라 Git의 커밋을 본다.
⸻
commit의 진짜 의미
git commit은
“외부로 보내는 행위”가 아니었다.
그건 이런 선언에 가깝다.
“이 상태의 코드를
하나의 공식적인 역사로 인정한다.”
커밋되지 않은 코드는
내 컴퓨터 안에서는 존재하지만,
배포의 관점에서는 아직 태어나지 않은 코드다.
⸻
Kamal은 무엇을 배포하는가
Kamal은 내 로컬 파일을 보지 않는다.
저장 여부도 보지 않는다.
Kamal이 믿는 건 단 하나다.
현재 Git 저장소의 최신 커밋 상태
그래서 순서가 중요하다.
1. git add — 이 변경을 기록할 대상으로 올리고
2. git commit — 이 상태를 역사로 확정한 뒤
3. bin/deploy — 그 역사를 서버로 옮긴다
이 중 하나라도 빠지면
서버는 과거에 머문다.
⸻
비유로 이해해보면
• 로컬에서 파일 수정
→ 혼잣말
• git commit
→ 일기장에 날짜 찍고 한 페이지 완성
• 배포
→ 그 페이지를 복사해 서버 벽에 붙이는 일
일기장에 쓰지 않은 이야기는
아무리 머릿속에 있어도
역사가 되지 않는다.
⸻
내가 얻은 진짜 깨달음
이건 단순한 Git 사용법이 아니었다.
코드는 저장으로 바뀌는 게 아니라
커밋으로 세상에 등장한다.
그리고 이 한 줄로 정리된다.
GitHub는 선택이다.
Git commit은 현실이다.
배포는 현실만을 믿는다.
⸻
이 글은
미래의 나에게 남기는 메모이기도 하고,
지금 막 같은 벽 앞에 서 있는 누군가에게는
작은 등불이 되길 바란다.
나도 그랬다.
버튼 하나로 시작된 의문이
개발의 세계를 한 칸 넓혀주었다.
느리지만,
확실하게 앞으로 가고 있다.