Git 커밋은 왜 나누고, 왜 squash로 합칠까?

커밋을 왜 나누고 squash는 왜 하는 걸까?

---

Git을 처음 배우는 분들이 자주 묻는 질문이 있다.
“그냥 다 작업하고 나서 한 번에 커밋하면 되는 거 아니에요?”

기술적으로는 가능하다.
하지만 협업을 고려한다면, 그리고 코드 리뷰를 받는다면 상황은 달라진다.

---

커밋은 '저장'이 아니라 '작업 설명서'다

예를 들어 feature/sandwich 브랜치에서
샌드위치를 만드는 기능을 구현하고 있다고 가정하자.

• C1: 샌드위치 준비
• C2: 빵 추가
• C3: 속 재료 넣기
• C4: 머스터드 바르기

이렇게 커밋을 나눈 이유는 단순히 "파일을 나눠서"가 아니다.
각 커밋이 하나의 의미 있는 작업 단위이기 때문이다.

즉, 커밋은 단순 저장 스냅샷이 아니라
작업의 흐름을 설명하는 일종의 설명서라고 볼 수 있다.

그 결과, 리뷰어 입장에서도 다음과 같은 장점이 생긴다.

• 작업 흐름을 쉽게 따라갈 수 있다
• 실수한 부분만 골라서 되돌리기 쉽다
• “이 변경은 왜 필요했지?”에 커밋 로그로 답할 수 있다

---

그렇다면 squash는 왜 필요할까?

이제 기능 개발을 마치고, main 브랜치에 머지하려고 한다.
그런데 C1~C4까지의 커밋이 그대로 main에 들어가는 게 좋을까?

꼭 그렇지는 않다.
개발 중의 작은 작업 흐름은 feature 브랜치 안에서만 중요하다.
main 브랜치에는 그 작업 전체가 하나의 기능으로 보이는 게 좋다.

그래서 사용하는 것이 바로
git merge --squash feature/sandwich

이 명령을 사용하면, 위의 4개 커밋이 하나로 합쳐진다.

• feat: 샌드위치 만들기 (C1~C4 작업 포함)

squash는 말 그대로 여러 개의 커밋을 압축해서 정리하는 작업이다.

---

한 번에 커밋하면 안 되는 이유

처음부터 한 번에 커밋해도 된다면, 굳이 나눌 필요가 있을까?
하지만 그렇게 하면 다음과 같은 문제가 발생한다.

• 작업 흐름이 보이지 않는다 (리뷰가 어려움)
• 실수한 부분만 따로 되돌리기 힘들다
• “이 부분 왜 수정했지?”를 파악하기 어려워진다

그래서 실무에서는 다음과 같은 흐름이 보편적이다.

---

실무에서의 커밋 전략

1. 작업 중에는
   → 커밋을 자주, 작게 나눈다 (의미 단위로)
2. PR 보낼 때는
   → 커밋을 squash로 깔끔하게 정리해서 머지한다

이 방식이 가장 효율적인 협업 전략으로 자리잡고 있다.

---

비유로 정리해보면

• 커밋 여러 개 = 요리에 필요한 재료들
• squash = 재료를 다 모아 완성된 요리를 만드는 과정
• 머지 = 그 요리를 팀장님에게 제출하는 것

---

마무리

• 커밋을 나누는 이유는 작업을 구분하고, 리뷰를 쉽게 하기 위해서
• squash는 그 작업들을 하나의 결과물로 정리하는 과정
• 처음부터 하나의 커밋으로 끝내는 것보다 의미 있는 단위로 나누고, 나중에 정리하는 게 훨씬 낫다

---

 이 내용은 Git을 배우는 학생의 질문을 계기로 정리한 포스트입니다.
실제로 협업을 경험해보면 왜 이 방식이 중요한지 더 명확히 느끼게 될 거예요.