Git 커밋 전략: 히스토리 관리와 작업 단위 분리

Git을 활용한 협업에서 커밋 전략은 프로젝트의 히스토리 관리와 코드 품질에 직접적인 영향을 미칩니다. 이 글에서는 효율적인 Git 커밋 전략과 이를 지원하는 도구들을 살펴보겠습니다.

Rebase 기반 워크플로우

Merge vs Rebase

Git 커밋 전략에서 Rebase와 Merge는 개발자마다 선호도가 다른 주제입니다. Rebase는 올바르게 사용하지 않으면 작업물을 잃거나 충돌 해결이 복잡해질 수 있습니다.

하지만 과도한 Merge 커밋은 Git 그래프를 복잡하게 만들어 히스토리 파악을 어렵게 합니다. Git의 핵심 가치는 명확한 히스토리 관리에 있으므로, Rebase를 선호하는 것이 권장됩니다.

Rebase의 장점

• 선형적 히스토리: 커밋 그래프가 단순하고 이해하기 쉽습니다.
• 명확한 변경 추적: 각 커밋이 무엇을 변경했는지 쉽게 파악할 수 있습니다.
• 깔끔한 로그: 불필요한 Merge 커밋이 없어 로그가 간결합니다.

커밋의 단위와 의미

1대1 대응 원칙

일정이 촉박할 때 동일한 작업을 여러 커밋으로 나누는 경우가 발생합니다. 하지만 한 작업 사이클 내에서 이루어지는 변경사항이라면 작업 내용과 커밋이 1대1로 대응하는 것이 좋습니다.

중요성

서비스의 규모가 성장하고 코드의 양이 증가할수록 이 원칙의 중요성은 커집니다. 명확한 커밋 단위는 다음과 같은 이점을 제공합니다:

• 디버깅 용이성: 특정 버그가 언제 도입되었는지 쉽게 파악할 수 있습니다.
• 리뷰 효율성: 코드 리뷰 시 변경사항의 의도를 명확히 이해할 수 있습니다.
• 롤백 안전성: 문제 발생 시 정확한 커밋만 되돌릴 수 있습니다.

의미 있는 커밋

작업 내용을 먼저 계획하고 각 작업이 커밋으로 만들어지면, 자연스럽게 각 커밋은 의미를 지니게 됩니다. 하지만 이전 작업 내용을 변경해야 하는 경우는 어떻게 처리해야 할까요?

스택 브랜치 전략

개념

Stacked PR 또는 Stacked Branch는 작업 단위를 브랜치로 나누되, 이전 작업 브랜치를 기반으로 새로운 작업 브랜치를 만드는 전략입니다.

main
  └─ feature-1
      └─ feature-2
          └─ feature-3

장단점

장점:

• 작업 간 의존성을 명확히 표현할 수 있습니다.
• 각 PR을 작게 유지하여 리뷰가 용이합니다.
• 독립적인 작업 단위를 유지할 수 있습니다.

단점:

• 이전 작업 브랜치가 변경되면 후속 브랜치들을 순차적으로 rebase 해야 합니다.
• 수동 관리 시 복잡도가 증가합니다.

Graphite를 활용한 자동화

Graphite는 스택 브랜치를 손쉽게 관리할 수 있는 도구입니다.

# 스택 브랜치 생성
gt create feature-1
gt create feature-2  # feature-1을 기반으로 생성
 
# 자동 rebase
gt restack  # 변경된 브랜치의 하위 브랜치들을 자동으로 rebase

주요 기능:

• gt cli를 통한 스택 브랜치 생성 및 관리
• 특정 브랜치 변경 시 연결된 브랜치들을 자동으로 rebase
• GitHub PR과 통합

학습 곡선:

• Graphite 고유의 명령어를 익혀야 합니다.
• 팀 전체가 동일한 도구를 사용해야 효과적입니다.

GitButler: 가상 브랜치 전략

혁신적인 접근

GitButler은 새로운 패러다임을 제시합니다. 하나의 브랜치에서 여러 작업을 동시에 진행하고, 각 작업 내용을 가상 브랜치로 분리할 수 있습니다.

동작 방식

Working Directory
  ├─ Virtual Branch: 스타일 변경
  │   ├─ commit: Update button styles
  │   └─ commit: Add responsive layout
  └─ Virtual Branch: 비즈니스 로직
      ├─ commit: Add validation logic
      └─ commit: Update API integration

주요 기능

유연한 작업 분리:

• 스타일 작업 중 비즈니스 로직을 수정해도 각 커밋을 목적에 맞는 가상 브랜치로 이동시키기만 하면 됩니다.

손쉬운 커밋 정리:

• 가상 브랜치 내에서 동일한 작업이 여러 커밋으로 나뉘어 있다면 간편하게 squash할 수 있습니다.

실제 브랜치 변환:

• 각 가상 브랜치는 추후 실제 Git 브랜치로 만들어져 메인 브랜치에 병합할 수 있습니다.

현재 상태

GitButler는 비교적 새로운 도구로, 일부 버그가 존재하지만 도구가 성숙해지면 강력한 워크플로우를 제공할 것으로 기대됩니다.

Git 네이티브 접근: Fixup과 Autosquash

순수하게 Git에서 제공하는 기능만으로도 작업과 커밋을 1대1로 유지할 수 있습니다.

Fixup 커밋

특정 커밋에 추가 변경사항을 연결합니다:

# 이전 커밋에 변경사항을 fixup으로 연결
git commit -a -m 'change comment' --fixup=<이전 커밋 해시>

이 명령어는 자동으로 커밋 메시지 앞에 fixup! 문자열을 추가합니다.

Autosquash Rebase

Rebase 시 fixup 커밋을 자동으로 원래 커밋과 병합합니다:

# fixup 커밋들을 자동으로 병합
git rebase --autosquash <base 커밋 해시>

워크플로우 예시

# 1. 초기 작업 커밋
git commit -m "Add user authentication"
 
# 2. 추가 수정사항 발생
# ... 코드 수정 ...
git commit --fixup=a1b2c3d  # a1b2c3d는 첫 커밋 해시
 
# 3. PR 전 정리
git rebase -i --autosquash main
# fixup 커밋이 자동으로 원래 커밋에 병합됨

설정 최적화

Autosquash를 기본으로 활성화:

git config --global rebase.autosquash true

선택 가이드

Git 네이티브 (Fixup/Autosquash)

적합한 경우:

• 추가 도구 설치를 원하지 않는 경우
• Git 기본 기능만으로 충분한 경우
• 팀이 Git 명령어에 익숙한 경우

Graphite

적합한 경우:

• 스택 브랜치를 자주 사용하는 경우
• 자동화된 rebase 관리가 필요한 경우
• GitHub PR 중심 워크플로우를 사용하는 경우

GitButler

적합한 경우:

• 여러 작업을 동시에 진행하는 경우
• GUI 도구를 선호하는 경우
• 실험적인 워크플로우를 시도하고 싶은 경우

결론

효율적인 Git 커밋 전략의 핵심은 명확한 히스토리 관리와 작업 단위의 1대1 대응입니다. Rebase 기반 워크플로우를 유지하고, 필요에 따라 적절한 도구를 활용하면 팀의 협업 효율성을 크게 향상시킬 수 있습니다.

프로젝트의 규모와 팀의 선호도에 따라 Git 네이티브 기능, Graphite, 또는 GitButler 중 적합한 방법을 선택하여 일관된 커밋 히스토리를 유지하시기 바랍니다.