Git의 Feature Branch: 브랜치 생성 및 작업 방법

Git의 Feature Branch란

Feature Branch(기능 브랜치)는 특정 기능을 개발하기 위해 develop에서 생성되는 Git의 임시 브랜치입니다. 장기간 유지되는 main 및 develop 브랜치와 달리, feature 브랜치는 제한된 시간 — 몇 시간에서 몇 주 — 동안만 존재합니다.

feature branch의 주요 목적은 하나의 작업과 관련된 변경 사항을 나머지 코드에서 격리하는 것입니다. 개발자는 자신의 브랜치에서 실험하고, 여러 커밋을 만들고, 코드를 손상시킬 수도 있으며, 팀의 다른 구성원의 작업에 영향을 미치지 않습니다.

개발이 완료되면 feature 브랜치는 필수 코드 리뷰와 함께 Pull Request를 통해 develop으로 다시 병합됩니다. 병합 후, 저장소를 깨끗하게 유지하기 위해 브랜치는 일반적으로 삭제됩니다.

Vincent Driessen, 2010에 따르면, feature 브랜치를 사용한 Git Flow 모델은 다양한 유형의 브랜치 간 책임의 명확한 분리 덕분에 업계 표준이 되었습니다.

Feature Branch 워크플로

워크플로는 개발자가 각 새 기능에 대해 수행하는 일련의 단계로 구성됩니다. 이 프로세스는 병합 충돌을 최소화하고 코드 품질 관리를 보장합니다.

1. 브랜치 생성 develop의 최신 커밋에서. 개발자는 develop으로 전환하고, 업데이트한 후 새 feature 브랜치를 만듭니다.
2. 개발 및 커밋 feature 브랜치에서. 개발자는 변경 사항을 적용하고, 명확한 설명과 함께 커밋하며, 정기적으로 브랜치를 원격 저장소에 푸시합니다.
3. develop과 동기화 — 개발 중에 메인 브랜치가 앞으로 나아갈 수 있습니다. 개발자는 자신의 feature 브랜치에 develop의 rebase 또는 merge를 수행합니다.
4. Pull Request 생성 — 기능이 준비되면, 개발자는 코드 리뷰를 위해 PR을 엽니다. 팀이 코드를 검토하고 댓글을 남깁니다.
5. 병합 및 삭제 — PR 승인 후, 브랜치는 develop에 병합되고 로컬 및 원격 모두에서 삭제됩니다.

develop과의 정기적인 동기화는 매우 중요합니다. feature 브랜치가 develop의 변경 사항을 병합하지 않고 오래 살수록 최종 병합에서 충돌 가능성이 높아집니다.

Feature 브랜치 동기화 빈도

Feature 브랜치 명명 규칙

브랜치 명명은 팀 규율의 중요한 부분입니다. 통일된 명명 표준을 통해 어떤 작업이 진행 중이고 누가 수행하고 있는지 빠르게 식별할 수 있습니다.

• feature/이름 — 클래식 Git Flow에서 feature/ 접두사가 사용됩니다. 예: feature/added-auth-module.
• feature/JIRA-123-설명 — 추적 시스템의 작업 번호에 연결. 예: feature/PROJ-42-add-login.
• feature/유형/이름 — 작업 유형을 나타내는 확장 형식. 예: feature/feat/analytics-dashboard.

JIRA, Trello 또는 다른 시스템의 작업 ID를 사용하는 것이 모범 사례입니다. 코드를 작업에 자동으로 연결하고 git log를 통한 브랜치 검색을 단순화합니다.

Pull Request 프로세스

Pull Request(또는 GitLab의 Merge Request)는 feature 브랜치를 develop에 병합하기 위한 요청입니다. PR은 단순한 기술 작업이 아니라, 코드 품질을 향상시키고 팀 내 지식을 전파하는 팀 코드 리뷰 프로세스입니다.

좋은 PR에는 작업에 대한 간략한 설명이 포함된 제목, 티켓 링크 및 변경 사항 설명이 포함됩니다. 개발자는 정확히 무엇이 수행되었는지, 어떤 파일이 변경되었는지, 프로젝트의 다른 부분에 잠재적 위험이 있는지 명시해야 합니다.

팀은 PR에서 코드를 검토하고, 댓글을 남기고, 변경을 요청하고(change requests), 병합을 승인합니다(approve). 승인 후 merge 또는 squash merge가 수행됩니다.

모바일 개발의 PR 리뷰 평균 시간은 4~24시간입니다. Danger 라이브러리는 PR 내에서 직접 린터와 테스트를 실행하여 일부 검사를 자동화합니다.

좋은 PR 작성을 위한 권장 사항

• 크기 — 300-400줄 이하의 변경. 큰 PR은 리뷰하기 어렵고 리뷰 품질이 떨어집니다.
• 하나의 PR — 하나의 작업 — 하나의 요청에 관련 없는 변경 사항을 혼합하지 마십시오.
• 스크린샷 — UI 변경의 경우 이전 및 이후 스크린샷을 첨부하십시오.
• 테스트 — 새 기능에 대한 단위 테스트를 작성하고 PR에 포함하십시오.

Feature 브랜치 병합 전략

PR 승인 후, feature 브랜치는 다양한 방식으로 develop에 병합될 수 있습니다. 병합 전략의 선택은 커밋 기록과 변경 사항 롤백 가능성에 영향을 미칩니다.

• Merge commit — 병합 커밋을 생성하고 feature 브랜치의 전체 커밋 기록을 보존합니다. 기록은 완전하지만 브랜치 그래프가 더 복잡해집니다.
• Squash merge — feature 브랜치의 모든 커밋을 하나로 결합하고 develop 위에 추가합니다. 기록이 더 깔끔해지지만 중간 커밋에 대한 정보가 손실됩니다.
• Rebase and merge — feature 브랜치의 커밋을 develop의 최신 커밋 위에 다시 작성하고 추가 커밋 없이 병합합니다. 기록이 선형으로 유지됩니다.

자주 릴리스하는 모바일 프로젝트의 경우 일반적으로 squash merge가 사용됩니다. develop에서 깔끔한 기록을 제공하며, 개발 세부 사항은 PR 설명과 트래커 작업에 남습니다.

Feature Branch 작업 시 일반적인 실수

경험 많은 개발자도 feature 브랜치 작업 시 실수를 합니다. 일반적인 문제를 알면 시간과 데이터 손실을 방지할 수 있습니다.

• 브랜치 수명이 너무 긺 — feature 브랜치가 develop과 동기화 없이 2-3주 이상 살아 있어 대규모 병합 충돌이 발생합니다.
• 불명확한 설명의 커밋 — “fix”나 “update”와 같은 메시지는 무엇이 변경되었고 왜 변경되었는지 설명하지 않습니다.
• 작업 혼합 — 동일한 feature 브랜치에서 두 개의 관련 없는 기능이 개발되어 선택적 롤백이 불가능합니다.
• 동기화 부족 — 개발자가 git fetch를 실행하지 않고 develop을 업데이트하지 않아 최종 병합 시 충돌이 발생합니다.

이러한 문제를 피하는 가장 좋은 방법은 프로젝트 시작 시 작업 규칙에 동의하고 CI/CD 파이프라인에서 자동화된 검사를 사용하는 것입니다.

Feature Branch 작업을 위한 명령어 예제

실용적인 시나리오를 고려해 보겠습니다. 개발자가 모바일 앱에서 새 인증 기능을 시작합니다. feature 브랜치를 만들고, 코드 작업을 수행하고, Pull Request로 작업을 완료합니다.

# develop 업데이트 및 feature 브랜치 생성
git checkout develop
git pull origin develop
git checkout -b feature/add-login-screen

# 기능 작업: 커밋
git add src/ui/login/
git commit -m "Add login screen layout"

# 서버에 feature 브랜치 푸시
git push origin feature/add-login-screen

# develop과 동기화(rebase)
git fetch origin develop
git rebase origin/develop

# PR 승인 후: 로컬 develop 업데이트 및 브랜치 삭제
git checkout develop
git pull origin develop
git branch -d feature/add-login-screen

git branch -d 명령어는 변경 사항이 완전히 병합된 후에만 브랜치를 삭제합니다. 브랜치가 병합되지 않은 경우, Git은 강제 삭제를 위해 git branch -D를 사용하도록 제안합니다 — 이 플래그는 주의해서 사용하십시오.

Feature 브랜치에서 검사 자동화

PR을 생성하기 전에 각 feature 브랜치에 대해 CI/CD 파이프라인을 실행해야 합니다. 이를 통해 코드가 다른 개발자의 리뷰에 들어가기 전에 초기 단계에서 문제를 발견할 수 있습니다.

# feature 브랜치 확인을 위한 GitHub Actions
name: Feature Branch CI

on:
  push:
    branches:
      - 'feature/**'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: ./gradlew test
      - name: Lint check
        run: ./gradlew lint

파이프라인은 코드가 컴파일되고, 테스트가 통과하며, 코드 스타일이 팀 표준을 충족하는지 확인합니다. 모든 검사를 통과한 후에만 Pull Request를 생성할 수 있습니다.