Git 워크플로우: 브랜치, 커밋, 스태시 활용법

효율적인 Git 워크플로우를 위한 실전 팁과 문제 해결 방법을 알아봅니다.
여러 브랜치에서 작업할 때 발생하는 일반적인 상황들을 어떻게 다루는지 실제 사례를 통해 배워보세요.

1. 관련 변경사항 별로 커밋 분리하기

하나의 브랜치에서 여러 가지 서로 다른 변경사항을 작업했을 때, 이를 논리적으로 분리된 커밋으로 나누는 것이 좋습니다.
이렇게 하면 코드 리뷰가 쉬워지고, 변경 히스토리를 더 명확하게 추적할 수 있습니다.

변경사항 현황

예를 들어, fix/auth-refresh 브랜치에서 다음과 같은 변경사항이 있었습니다:

1. 리프레시 토큰 헤더 이름 수정 (axios-interceptor.ts)
2. 토큰 디코딩 함수 개선 (decodeToken.ts)
3. 패키지 의존성 추가 (package.json, package-lock.json)

해결책: git add -p 활용

git add -p 명령어를 사용하면 변경된 파일의 각 부분을 선택적으로 스테이징할 수 있습니다:

# 변경된 파일들을 한 부분씩 검토하면서 스테이징
git add -p

# 첫 번째 변경사항에 대한 커밋
git commit -m "fix: API헤더에 알맞는 헤더명으로 변경"

# 나머지 변경사항 스테이징 및 커밋
git add .
git commit -m "refactor: improve JWT token decoding function"

대안: 파일 단위로 스테이징

변경사항이 파일별로 깔끔하게 구분된다면, 파일 단위로 스테이징하는 방법도 있습니다:

# 첫 번째 변경사항 관련 파일만 스테이징
git add src/api/axios-interceptor.ts App.tsx

# 첫 번째 커밋
git commit -m "fix: API헤더에 알맞는 헤더명으로 변경"

# 나머지 파일 스테이징 및 커밋
git add package.json package-lock.json src/utils/auth/decodeToken.ts
git commit -m "refactor: improve JWT token decoding function"

2. 브랜치 최신화하기: Merge vs Rebase

main 브랜치에 새로운 변경사항이 있고, 작업 중인 기능 브랜치를 최신 상태로 업데이트해야 할 때 두 가지 방법이 있습니다.

merge 방식 (일반적인 방법)

git checkout feat/verify-email
git pull origin main

장점

• 안전하고 간단합니다.
• 충돌이 발생하면 한 번만 해결하면 됩니다.
• 변경사항이 많을 때 더 관리하기 쉽습니다.

단점

• 병합 커밋이 생성되어 커밋 히스토리가 복잡해질 수 있습니다.

rebase 방식 (깔끔한 히스토리를 위한 방법)

git rebase main은 기본적으로 로컬의 main 브랜치를 의미합니다.
하지만 대부분의 경우 실제로는 원격 저장소(origin)의 최신 main 브랜치로 업데이트하고 싶을 것입니다.
따라서 제대로 된 리베이스 과정은 보통 다음과 같습니다:

# 먼저 로컬 main 브랜치를 origin의 최신 main으로 업데이트
git checkout main
git pull origin main

# 그 다음 기능 브랜치로 이동해서 최신 main에 리베이스
git checkout feat/verify-email
git rebase main

이렇게 하면 순서대로:

1. 로컬 main 브랜치를 원격 저장소의 최신 상태로 업데이트
2. 기능 브랜치를 업데이트된 로컬 main 브랜치 위로 리베이스

장점

• 선형적이고 깔끔한 커밋 히스토리가 만들어집니다.
• 병합 커밋이 생성되지 않습니다.

단점

• 변경사항이 많을 경우 각 커밋마다 충돌을 해결해야 할 수 있어 복잡해집니다.
• 이미 원격 저장소에 푸시된 브랜치에 적용할 때는 주의가 필요합니다(--force 옵션 필요).

merge와 rebase의 차이

merge 전/후:

A---B---C (main)
     \
      D---E (feat/branch)

# merge 후
A---B---C (main)
     \   \
      D---E---F (feat/branch, F는 병합 커밋)

rebase 전/후:

A---B---C (main)
     \
      D---E (feat/branch)

# rebase 후
A---B---C (main)
         \
          D'---E' (feat/branch)

변경사항이 많은 경우에는 일반적인 병합 방식이 더 실용적입니다.

3. 스태시(stash) 활용하기

스태시는 작업 중인 변경사항을 임시로 저장해 두는 Git의 기능입니다. 브랜치를 전환하거나 다른 작업을 먼저 해야 할 때 유용합니다.

스태시 적용하기

스태시와 브랜치 리베이스를 함께 사용할 때는 순서가 중요합니다:

# 먼저 브랜치를 최신 main으로 리베이스
git checkout feat/verify-email
git rebase main

# 그 다음 스태시를 적용
git stash pop stash@{1}

올바른 순서를 따라야 하는 이유

1. 먼저 브랜치를 최신 상태로 업데이트하면 깨끗한 상태에서 시작할 수 있습니다.
2. 그 다음 스태시를 적용하면 최신 코드 위에 작업 중이던 변경사항을 적용할 수 있습니다.
3. 반대 순서로 하면 리베이스 과정에서 충돌이 발생할 가능성이 높아집니다.

4. GitHub에서 PR과 브랜치 관리

PR 후 브랜치 삭제하기

GitHub에서 "Delete branch" 버튼은 원격 브랜치만 삭제합니다. 로컬 브랜치는 직접 삭제해야 합니다:

# 원격 브랜치 정보 업데이트
git fetch -p

# 로컬 브랜치 삭제
git branch -d fix/auth-refresh

새 PR 푸시하기

이미 존재하는 브랜치에 추가 커밋을 푸시하면, 해당 브랜치에 대한 PR이 이미 존재하는 경우 그 PR에 커밋이 추가됩니다:

git push origin fix/auth-refresh

GitHub는 새 브랜치가 푸시될 때마다 PR 생성 링크를 표시하지만, 이미 PR이 존재한다면 기존 PR이 업데이트됩니다.

결론

Git과 GitHub을 효율적으로 활용하려면 브랜치, 커밋, 스태시 등의 기능을 상황에 맞게 적절히 사용하는 것이 중요합니다. 이 글에서 다룬 실전 팁들이 여러분의 개발 워크플로우를 더 효율적으로 만드는 데 도움이 되기를 바랍니다.

특히 팀 프로젝트에서는 커밋을 논리적 단위로 분리하고, 브랜치를 최신 상태로 유지하는 습관이 중요합니다. 또한 변경사항의 규모와 상황에 따라 merge와 rebase를 적절히 선택하여 사용하는 것이 좋습니다.