[TIL] 효율적인 git commit 전략

2025-02-18 TIL

📝 TIL (Today I Learned)
🔗 원본 이슈: #19
📅 작성일: 2025-02-18
🔄 최종 수정: 2025년 03월 05일


🍀 새롭게 배운 것

이번에 Git에 대해 다시 공부하면서 두 가지 개념을 중점적으로 정리했다.

  • 효율적인 Git Commit 전략

    • 예전에는 커밋 메시지를 감으로 작성했지만, 최근엔 Udacity 스타일의 커밋 메시지 작성법을 적용해보려 하고 있다. 예: feat: 사용자 프로필 저장 기능 추가 또는 fix: API 응답 포맷 오류 수정
  • git rebase 완전 정복하기

    • 지금까지는 git merge만을 주로 사용해 협업을 해왔지만, git rebase의 개념은 늘 ‘들어만 봤던’ 상태였다.
    • 이번 기회에 git rebase가 실제로 어떤 상황에서 유용하고, 어떤 흐름으로 작동하는지를 명확히 정리하게 되었다.

🍎 오늘의 문제 상황

🔍 문제 인식

프로젝트를 진행하면서 Git 커밋 로그가 너무 산만하게 흐르는 것을 보며, 자연스럽게 Git 전략에 대한 고민이 생겼다. 특히 git merge만 사용하다 보니 히스토리가 복잡하게 얽히는 문제가 발생했다. 이때 떠오른 것이 git rebase였다.

하지만 막상 스스로 설명하려 하니…

“내가 이걸 **‘제대로’ 아는 걸까?” 라는 의문이 들었다.

✅ 해결 과정

  • Git Merge vs Rebase 차이점 정리
항목git mergegit rebase
브랜치 구조브랜치가 병합되며 병합 커밋(Merge Commit) 생성브랜치가 직선적으로 재배열됨
커밋 히스토리복잡하지만 충돌 이력이 명확히 남음깔끔하지만 충돌 해결 히스토리는 사라짐
협업 시기공식 배포 브랜치 병합 시 사용 권장개인 브랜치 정리용으로 주로 사용
  • 언제 rebase가 유용할까?

    • 큰 조직이나 다수의 협업자들이 있는 경우, 직선적인 커밋 히스토리는 디버깅과 리뷰에 큰 도움이 된다.
    • PR을 올리기 전 개인 브랜치의 커밋을 정리할 때 매우 유용하다. (git rebase -i로 커밋 합치기 등)
  • 작은 프로젝트에서는 merge만 써도 큰 불편은 없었지만, 실제 대규모 프로젝트에서는 rebase의 가치가 커진다는 것을 깨달았다.


🦄 느낀 점

  • 정말로 와닿은 문장:

    “아는 것과 제대로 아는 것은 다르다.”

  • 나는 git rebase를 ‘안다고 생각했지만’, 정작 쓸 수는 없었다. 이번에 개념과 흐름을 정리하면서 ‘실제로 써먹을 수 있는 지식’으로 바뀌었다.

  • 이제는 협업 시 git log를 깔끔하게 유지하는 것도 개발자의 중요한 역량이라는 걸 알게 되었고, 다음 협업에서는 rebase도 적극적으로 활용해보고 싶다.


💬 TIP

팀원들과 Git 전략을 공유할 때는 merge/rebase 전략을 사전에 정리하고, PR 전에는 git rebase origin/main을 통해 개인 브랜치를 정리해두는 습관이 중요하다!

🐬 깃블로그 정리

  • [효율적인 git commit 전략] (https://nan0silver.github.io/miscellaneous/2025-02-19-git-commit/)
  • [git rebase] (https://nan0silver.github.io/miscellaneous/2025-01-23-git-rebase/)