🚀 [2편] Git 커밋 vs 푸시 — 언제 해야 할까?

부제: 커밋과 푸시의 타이밍을 이해하는 실전 가이드

 

📘 글 요약

개발을 하다 보면 “이 정도 작업이면 커밋할까, 아니면 푸시까지 할까?” 고민하게 됩니다.

이 글에서는 커밋과 푸시의 차이를 명확히 구분하고,
작업 단위별로 커밋/푸시 타이밍을 판단하는 실제 사례를 정리했습니다.

 

LemonLog(감정일기 앱) 개발 과정을 예시로,
홈화면 구성, API 연동, 리팩터링 등 실제 시나리오에서 어떤 시점에 커밋하고 푸시해야 하는지
한눈에 이해할 수 있습니다.

---

1️⃣ 기본 개념 정리

구분	의미	요약
커밋(commit)	로컬에 작업 이력 저장	“현재 상태가 안정적이다”
푸시(push)	원격 저장소(GitHub 등)에 업로드	“공유/백업할 가치가 있다”

---

2️⃣ 커밋과 푸시의 차이

커밋은 작게, 자주

푸시는 의미 있게, 단계별로

항목	커밋	푸시
목적	개발 진행 기록	결과물 공유/백업
단위	작은 기능, 한 변경점	기능 완성, 마일스톤
빈도	수시 (몇 분~수십 분 단위)	하루 1~2회
롤백	개별 커밋 단위로 가능	히스토리로 관리됨

---

3️⃣ 작업 단위를 끊는 기준

커밋 기준 (로컬)

✅ 빌드가 성공한다

✅ 하나의 목적/기능으로 설명할 수 있다

✅ 롤백해도 의미 있는 상태다

 

푸시 기준 (원격)

✅ 커밋 여러 개가 모여 ‘기능 단위’가 완성됐다

✅ 다른 사람(또는 미래의 나)이 보기에도 의미 있다

✅ 현재 시점의 결과를 공유할 가치가 있다

---

4️⃣ 예시로 이해하기

🔹 홈 화면 4개 UI 요소 구현

단계	행동	이유
첫 번째 요소(API 연결·표시 완료)	커밋만	전체 미완성, 기능 일부만 완성
네 개 UI 요소 모두 완성	커밋 + 푸시	기능 단위 완성, 의미 있는 결과
버그 수정	커밋 + 필요 시 즉시 푸시	협업 시 영향이 있을 수 있음

feat: 홈 화면 첫 번째 카드(API 연동 및 표시) 구현

- 명언 API 호출 및 파싱
- 모델 변환 후 UI 바인딩
- 로딩/에러 상태 추가

🔹 API 기능 구현 흐름

단계	작업	행동
API 클라이언트 작성	커밋	구조/엔드포인트 설정
JSON 모델 및 파싱	커밋	데이터 가공 완료
ViewModel 바인딩	커밋	데이터 흐름 연결
전체 테스트 후 정상 표시	푸시	기능 단위 완성

🔹 리팩터링 작업

단계	행동
Storyboard → 코드 레이아웃 전환	커밋
SceneDelegate 전환 및 루트뷰 설정	커밋
AppIcon 설정 추가	커밋
초기 세팅 완료	푸시

---

5️⃣ 실전 규칙 요약

원칙	설명
✅ 커밋은 작고 명확하게	한 목적, 한 기능 중심
✅ 푸시는 마일스톤 단위로	기능 또는 화면 단위 완성 시
✅ 항상 빌드 그린	깨지는 커밋 금지
✅ 메시지는 현재형으로	“추가”, “수정”, “정리” 등 명령조
✅ 브랜치 전략 활용	main(배포), feature/*(작업용)

---

커밋은 개발자의 사고를 기록하는 과정이고,
푸시는 그 기록을 세상과 나누는 순간이다.
커밋은 세밀하게, 푸시는 의미 있게.