Git의 Develop Branch — 정의, 목적 및 작동 원리

Git의 Develop Branch란

Develop Branch(개발 브랜치)는 Git Flow의 장기 실행 브랜치로, 모든 개발자의 코드 통합을 위한 중앙 허브 역할을 합니다. 개발 완료 및 코드 리뷰 후 feature 브랜치가 여기에 병합됩니다.

develop의 코드는 항상 릴리스 생성 준비가 된 상태에 있지만 아직 프로덕션에 배포되지는 않았습니다. 즉, develop의 모든 기능은 리뷰, 테스트 및 통합 검사를 통과했지만 아직 릴리스 주기를 기다리고 있습니다.

각 코드 버전이 릴리스인 main과 달리 develop에는 지속적인 변경 흐름이 포함됩니다. feature 브랜치가 병합됨에 따라 develop에 커밋이 나타나며, 이는 하루에 여러 번 발생할 수 있습니다.

Vincent Driessen, 2010에 따르면 develop은 성공적인 브랜칭 모델의 핵심 요소로, 초안 작업을 릴리스 준비 버전과 분리합니다.

develop과 main 브랜치의 차이

develop과 main의 차이를 이해하는 것은 올바른 Git Flow 워크플로에 중요합니다. 이 브랜치들은 다른 기능을 수행하며 다른 안정성 요구사항을 가집니다.

develop과 main으로 분할하면 팀이 프로덕션 버전 안정성을 위험에 빠뜨리지 않고 새 코드를 지속적으로 통합할 수 있습니다. 개발자는 공식 릴리스 전이라도 PR 승인 후 즉시 develop에서 자신의 코드를 볼 수 있습니다.

Git Flow에서 develop의 역할

Git Flow 모델에서 develop은 feature 브랜치(변경 소스)와 release 브랜치(릴리스 준비) 사이에서 중심적인 위치를 차지합니다. 이 계층 구조를 이해하는 것이 효과적인 브랜칭의 기초입니다.

• Feature → Develop — 각 완료된 기능은 코드 리뷰와 함께 Pull Request를 통해 develop에 병합됩니다.
• Develop → Release — 릴리스에 충분한 변경 사항이 축적되면 develop에서 release 브랜치가 생성됩니다.
• Release → Main + Develop — 최종 준비 후 release 브랜치는 main(릴리스)과 develop(버그 수정)에 병합됩니다.
• Hotfix → Main + Develop — 중요한 수정 사항은 main에서 생성되어 두 브랜치에 병합됩니다.

이 구조는 develop이 항상 모든 새 기능이 포함된 최신 코드를 유지하고 main이 검증된 프로덕션 코드만 포함하도록 보장합니다. 이는 App Store 및 Google Play에서 리뷰 주기가 긴 모바일 프로젝트에서 특히 중요합니다.

다른 Git Flow 브랜치와 develop의 관계

Develop은 feature, release 및 hotfix 브랜치 간의 중심 연결 고리 역할을 합니다. 병합 방향을 이해하는 것은 충돌과 커밋 손실을 방지하는 데 필수적입니다.

develop의 코드 품질 요구사항

develop의 코드 품질은 높아야 하지만 절대적일 필요는 없습니다. 모든 오류가 긴급 hotfix를 의미하는 main과 달리 develop은 릴리스 전에 수정될 사소한 불완전성을 허용합니다.

develop에 병합하기 전 코드의 최소 요구사항:

• 컴파일 — 코드가 오류 없이 컴파일되어야 합니다. develop에서 빌드가 깨지면 팀 전체의 작업이 차단됩니다.
• 단위 테스트 — 모든 기존 테스트가 통과해야 합니다. 새 코드는 최소 70% 이상 테스트로 커버되어야 합니다.
• 코드 스타일 — 코드는 팀에서 승인된 형식 및 명명 표준을 준수해야 합니다.
• 더 이상 사용되지 않는 API 금지 — 새 코드에서 더 이상 사용되지 않는 메서드 사용은 허용되지 않습니다.

CI/CD 파이프라인의 자동 검사는 develop에 대한 모든 푸시에서 실행되어야 합니다. 빌드가 깨지면 책임 개발자가 한 시간 내에 문제를 해결하거나 커밋을 되돌려야 합니다.

develop을 위한 CI/CD 검사

develop에 GitHub Actions를 설정하면 모든 PR이 병합 전에 자동 검사를 통과하도록 보장합니다. 일반적인 파이프라인에는 빌드, 테스트 및 린팅이 포함됩니다.

# GitHub Actions — 병합 후 develop 확인
name: Develop CI

on:
  pull_request:
    branches: [develop]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Unit tests
        run: ./gradlew testDebug
      - name: Lint
        run: ./gradlew lint
      - name: Build
        run: ./gradlew assembleDebug

develop 병합 규칙

develop에 병합은 통합 브랜치의 안정성을 유지하기 위해 엄격한 규칙을 따라야 합니다. 이러한 규칙을 위반하면 충돌, 빌드 손상 및 팀 시간 낭비가 발생합니다.

• Pull Request로만 — develop에 직접 푸시는 금지됩니다. 모든 변경 사항은 코드 리뷰를 거칩니다.
• 최소 한 명의 승인 — PR은 작업에 참여하지 않은 최소 한 명의 개발자 승인이 필요합니다.
• Squash merge — 깔끔한 기록을 위해 develop에 병합할 때 모든 feature 브랜치 커밋을 하나로 합치는 것을 권장합니다.
• PR 최신 상태 유지 — 병합 전 PR은 최신 develop 커밋(rebase 또는 merge)을 기준으로 업데이트되어야 합니다.

PR 최신 상태 유지 규칙은 특히 중요합니다. feature 브랜치가 일주일 전에 생성되었고 develop이 50커밋 앞서간 경우 직접 병합하면 develop보다 PR 컨텍스트에서 해결하는 것이 더 나은 충돌이 발생할 수 있습니다.

잘못된 병합으로부터 develop 보호

브랜치 보호 규칙은 GitHub, GitLab 또는 Bitbucket 수준의 설정으로 develop에 대한 잘못된 변경을 방지합니다. 실수로 푸시해도 통합 브랜치가 손상되지 않도록 보장합니다.

develop에 권장되는 보호 규칙:

• Pull request 필수 — develop에 직접 푸시 금지. 모든 변경 사항은 PR로만.
• 승인 필수 — PR 병합 전 최소 1-2명의 승인.
• 상태 확인 필수 — CI/CD 파이프라인이 통과하지 못하면 병합 차단.
• 최신 상태 필수 — 병합 전 PR 브랜치가 develop을 기준으로 업데이트되어야 함.
• 푸시 액세스 제한 — develop에 대한 푸시 권한을 시니어 개발자로만 제한.

develop 보호 설정은 10분이 소요되지만 통합 브랜치 손상과 관련된 몇 주간의 가동 중단을 방지합니다. 다중 플랫폼 팀이 있는 모바일 프로젝트의 경우 특히 중요합니다.

develop 작업 명령어 예시

일반적인 개발자의 하루를 생각해보겠습니다: 아침에 develop을 업데이트하고, 새 feature 브랜치를 만들고, 작업 완료 후 변경 사항을 develop에 다시 병합합니다.

# 아침 develop 동기화
git checkout develop
git pull origin develop

# develop에서 새 feature 브랜치 생성
git checkout -b feature/add-push-notifications

# 기능 작업 중...
git add . && git commit -m "Add FCM integration"

# 개발 중 develop 업데이트
git fetch origin develop
git rebase origin/develop

# PR 승인 후 — 로컬 develop 업데이트
git checkout develop
git pull origin develop
git branch -d feature/add-push-notifications

develop에서 git pull 명령은 한 번에 두 가지 작업을 수행합니다: git fetch(서버에서 새 커밋 가져오기)와 git merge(로컬 브랜치와 병합). develop의 경우 이것이 표준 동기화 방법입니다.

손상된 병합 후 develop 복구

빌드를 깨는 코드가 develop에 들어가면 신속하게 조치해야 합니다. develop의 가동 중단 1시간마다 전체 개발 팀의 작업이 차단됩니다.

빌드를 깨는 코드가 develop에 들어간 경우 git revert를 사용하여 문제가 있는 변경 사항을 취소하는 새 커밋을 만듭니다. develop에서 git reset을 사용하지 마십시오 — 다른 팀 구성원이 이미 가지고 있는 기록을 덮어씁니다.

# 문제가 있는 커밋 찾기
git log --oneline develop

# revert를 통한 커밋 취소 (안전)
git revert a1b2c3d

# 원격 develop에 수정 사항 푸시
git push origin develop

# 특정 커밋의 변경 사항 보기
git show a1b2c3d --stat