[Git] 효율적인 Git commit 전략: 단위 결정, 스타일, 충돌 해결 방법

in GIT

직렬화 (Serialization)와 역직렬화(Deserialization)에 대해 알아보자.

Commit 단위를 결정 짓는 요소

  1. 하나의 목적 / 의도
  • 커밋은 하나의 논리적 작업 단위만 포함한다.
    • 예시
      • “로그인 버튼 스타일 수정” 과 “API 요청 추가”는 별도 커밋으로 나눔
  1. 변경 사항의 크기
    • 가능한 작은 크기로 나누되, 완결성을 가져야 한다.
  2. 독립성
  • 독립적으로 동작할 수 있어야 한다.
    • 커밋 후 언제든 코드를 실행하거나 테스트할 수 있어야 한다.
  1. 관련성
  • 서로 연관된 변경사항은 하나의 커밋으로 묶는다.
    • 예시: 새로운 기능을 추가하면서 해당 기능의 스타일을 함께 수정하는 경우, 하나의 커밋으로 처리 가능
    • 하지만 독립적인 기능 수정과 스타일 변경은 별도의 커밋으로 분리해야 함.
  1. 의미 있는 메시지
  • 커밋 메시지가 변경 사항을 명확하게 설명할 수 있도록 구성해야함
    • 예시
      • 좋은 예 : “사용자 로그인 API 요청 로직 추가”
      • 나쁜 예 : “수정함” 또는 “업데이트”

Udacity style

  • Udacity에서 권장하는 커밋 메시지 작성 스타일을 의미

📌 Udacity 커밋 메시지 스타일

type: 설명 (길이 72자 이내)

  • type: 변경 사항의 유형을 나타냄 (예: feat, fix, refactor 등)
  • 설명: 간결하고 명확한 변경 사항 설명

✅ Udacity 스타일 커밋 메시지 예시

feat: 로그인 API 요청 추가
fix: 비밀번호 입력 검증 로직 수정
refactor: 중복된 코드 제거 및 함수 리팩토링
style: 코드 스타일 정리 (불필요한 공백 제거)
docs: README 파일 업데이트
test: 회원가입 유닛 테스트 추가
chore: 패키지 버전 업데이트

🛠 Udacity 스타일 주요 특징

  1. 첫 글자는 소문자 사용
    • Git 커밋 메시지 관례에 따라 소문자로 시작함
  2. 커밋 타입을 명확히 구분
    • feat: 새로운 기능 추가
    • fix: 버그 수정
    • refactor: 코드 리팩토링
    • 기능 유지 + 코드의 가독성, 유지보수성, 성능 최적화등 코드 구조 개선
    • style: 코드 스타일 변경 (기능 변경 없음)
    • 기능 유지 + 들여쓰기, 공백, 줄정리 등 코드 포맷 정리
    • docs: 문서 수정
    • test: 테스트 코드 추가/수정
    • chore: 빌드 및 패키지 관련 작업
  3. 제목 길이는 72자 이내로 유지
    • Git 로그에서 한눈에 보기 쉽게 유지
  4. 명령형 사용
    • "Fixed login bug" ❌ → "fix: 로그인 버그 수정" ✅

🎯 Udacity 스타일을 쓰는 이유

  • 협업 시 일관성 있는 커밋 로그 유지
  • Git 커밋 히스토리 가독성 향상
  • 자동화된 릴리즈 노트 생성 가능 (Conventional Commits 방식과 유사)
  • 커밋 이력이 깔끔하게 정리되고 팀원들이 쉽게 이해할 수 있어 유지보수 및 협업에 유리하다.

Rebase를 잘쓰자!

  • 참조하는 commit을 변경하는 명령어
  • base branch가 변경될 때마다 rebase를 하면 conflict를 최소화할 수 있다.

Rebase란?

🔗 [Git] git rebase 블로그에 정리되어 있습니다!

conflict를 해결하는 방법, Reset + force push

Reset이란?

  • git reset 명령어는 특정 커밋으로 되돌리는 기능을 하며, 되돌리는 방식에 따라 코드 변경 사항을 유지할 수도 있고, 삭제할 수도 있음
  • git reset의 주요 옵션
    • --soft
      • 특정 커밋 이전으로 HEAD를 이동하지만, 변경된 파일과 스테이징 영역은 그대로 유지
      • 보통 최근 커밋을 수정하고 다시 커밋할 때 사용
    • --mixed (기본 옵션)
      • 특정 커밋 이전으로 HEAD 이동, 스테이징 영역은 초기화되지만 작업 디렉터리는 유지됨
    • --hard
      • 특정 커밋 이전으로 HEAD 이동, 변경된 코드까지 전부 삭제되며 되돌릴 수 없음

Reset 후 force push 사용

  • 로컬에서 git reset을 사용하여 커밋을 변경하면, 원격 저장소와 커밋 이력이 달라져 git push시 conflict가 발생할 수 있다.
  • 이 문제를 해결하기 위해 git push --force를 사용하면, 로컬 브랜치의 변경사항을 강제로 원격 저장소에 반영할 수 있음
  • conflict 해결 방법으로써의 Reset + force push
    • commit이 여러개인 경우, 중간에 conflict가 난 경우, 이 후의 커밋 모두 conflict가 발생
      • 하지만 git reset으로 커밋을 하나의 커밋으로 만들면 코드 충돌을 빠르게 해결할 수 있음