Git의 Main 및 Master Branch: 개념 및 메인 브랜치가 필요한 이유

Git에서 Main / Master Branch란

Main Branch(또는 Master — 저장소 설정에 따라 다름)는 Git 저장소를 초기화할 때 생성되는 기본 브랜치입니다. 프로젝트의 메인 브랜치이며 프로덕션에 배포할 준비가 된 코드를 포함합니다.

새로운 기능으로 일상적인 작업이 활발한 develop과 달리, main은 프로젝트의 쇼케이스입니다. main의 각 코드 버전은 전체 사이클을 거쳤습니다: feature 브랜치에서 개발, develop에 통합, release 브랜치에서 릴리스 준비, 최종 테스트. 그 후에야 변경 사항이 main에 도달합니다.

핵심 원칙: main은 항상 안정적이어야 합니다. main에서 오류가 발견되면, 긴급 hotfix를 순서 외로 릴리스해야 함을 의미합니다. 따라서 전문 프로젝트에서는 main이 브랜치 보호 규칙에 의해 우발적인 변경으로부터 보호됩니다.

Git Book에 따르면, main은 고유한 속성을 가진 특별한 브랜치가 아니라, 관례상 메인으로 간주되는 커밋에 대한 일반적인 참조입니다. Git은 시스템 수준에서 main과 다른 브랜치를 구분하지 않습니다.

master에서 main으로의 전환

역사적으로 Git의 기본 브랜치는 master라고 불렸습니다. 2020년 6월, Black Lives Matter 운동이 IT 업계에서 master와 slave라는 용어에 주목하게 했습니다. GitHub는 기본 브랜치에 main이라는 용어로 전환을 발표했습니다.

2020년 10월부터 GitHub의 모든 새 저장소는 main 브랜치로 생성됩니다. GitLab과 Bitbucket도 기본 이름으로 main을 지원했습니다. Git 2.28(2020년 7월)은 기본 브랜치 이름을 구성하는 init.defaultBranch 옵션을 추가했습니다.

기술적으로 기존 브랜치의 이름을 master에서 main으로 변경하는 것은 간단한 작업입니다. 주요 과제는 CI/CD 구성, 문서 및 개발자의 로컬 저장소에 있는 모든 참조를 업데이트하는 것입니다.

기존 저장소에서 브랜치 이름을 변경하려면 다음을 실행하세요:

# 로컬에서 master를 main으로 이름 변경
git branch -m master main

# 원격 저장소 업데이트
git push -u origin main

# 서버에서 이전 master 삭제
git push origin --delete master

# 서버에서 HEAD 업데이트
# (GitHub 웹 인터페이스를 통해: Settings → Branches → Default branch)

Git Flow 및 GitHub Flow에서 main의 역할

Git Flow와 GitHub Flow는 main 브랜치의 역할을 다르게 정의합니다. 모델 선택은 팀 규모, 릴리스 빈도 및 코드 안정성 요구 사항에 따라 다릅니다.

모바일 개발의 경우 Git Flow가 표준입니다. App Store 및 Google Play에 앱을 게시하는 데는 고정된 릴리스 사이클이 있기 때문입니다. GitHub Flow는 하루에 여러 번 배포할 수 있는 웹 프로젝트에 더 적합합니다.

GitHub Flow — 간소화된 접근 방식

GitHub Flow에는 develop 브랜치가 없습니다. 모든 feature 브랜치는 main에서 직접 생성되며, 완료 후 Pull Request를 통해 다시 병합됩니다. main에 대한 각 병합은 자동으로 프로덕션 배포를 트리거합니다. 이 모델은 높은 수준의 테스트 자동화와 팀 규율이 필요합니다.

GitHub Flow에는 develop 브랜치가 없습니다. 모든 feature 브랜치는 main에서 직접 생성되며, 완료 후 Pull Request를 통해 다시 병합됩니다. main에 대한 각 병합은 자동으로 프로덕션 배포를 트리거합니다. 이 모델은 높은 수준의 테스트 자동화와 팀 규율이 필요합니다.

main 브랜치 보호

main에 대한 브랜치 보호는 모든 상업 프로젝트에서 필수 설정입니다. 이것이 없으면 우발적인 push로 인해 미완성 코드가 프로덕션에 전송되거나 모든 사용자의 작동 중인 애플리케이션이 손상될 수 있습니다.

• Require pull request — main에 직접 push 금지. 모든 변경은 검토가 있는 PR을 통해.
• Require approvals — main에 병합하려면 최소 2개의 승인 필요(검토자가 놓친 경우 대비).
• Require status checks — 병합 전 모든 CI/CD 검사 통과 필요.
• Require up-to-date — PR은 최신 main 커밋을 기반으로 해야 합니다.
• Include administrators — 보호는 저장소 소유자에게도 적용됩니다.
• Require signed commits — main의 모든 커밋은 GPG 키로 서명되어야 합니다.

6가지 규칙 모두를 구성하는 것은 10,000명 이상의 사용자가 있는 모바일 프로젝트의 표준입니다. 소규모 프로젝트의 경우 처음 세 가지 규칙으로 충분합니다.

다양한 프로젝트 유형에 대한 보호 수준 비교

main의 보호 수준은 프로젝트 규모에 따라 다릅니다. 스타트업은 최소한의 보호로 충분하지만, 엔터프라이즈 애플리케이션은 최대 제한이 필요합니다.

main의 릴리스 및 태그

태깅은 main의 특정 커밋에 이름이 지정된 참조를 생성하는 방법입니다. 각 태그는 프로덕션에 릴리스된 애플리케이션 버전에 해당합니다. 이를 통해 디버깅이나 패치를 위해 이전 릴리스로 빠르게 전환할 수 있습니다.

모바일 개발에서 태그 명명 표준은 SemVer(시맨틱 버저닝)입니다: v1.2.3. 첫 번째 숫자는 주 버전(호환성을 깨는 변경), 두 번째는 부 버전(새 기능), 세 번째는 패치(수정)입니다.

release 브랜치가 main에 병합된 후 태그가 생성됩니다. 그런 다음 이 커밋은 CI/CD에서 빌드되고, 서명되며, 앱 스토어로 전송됩니다. 태그에서 오류가 발견되면 해당 태그에서 hotfix 브랜치가 생성됩니다.

# 주석이 달린 릴리스 태그 생성
git tag -a v2.4.1 -m "Release version 2.4.1"

# 서버에 태그 보내기
git push origin v2.4.1

# 저장소의 모든 태그 보기
git tag -l "v2.*"

# 특정 태그에서 hotfix 브랜치 생성
git checkout -b hotfix/crash-fix v2.4.1

Git Flow 브랜치 계층 구조

Git Flow의 브랜치 계층 구조를 이해하는 것은 협업 개발을 올바르게 구성하기 위한 기초입니다. 각 브랜치 유형에는 고유한 소스, 목적 및 병합 규칙이 있습니다.

• Main (레벨 1) — 루트 브랜치, 릴리스 버전만 포함. 저장소 초기화 시 생성.
• Develop (레벨 2) — 프로젝트 시작 시 main에서 생성. 모든 기능의 통합 코드 포함.
• Feature (레벨 3) — develop에서 생성. 개별 기능의 격리된 개발.
• Release (레벨 2) — develop에서 생성. 특정 릴리스 출시 준비.
• Hotfix (레벨 2) — main에서 생성. 프로덕션의 중요한 오류 긴급 수정.

중요한 규칙: feature는 절대 main에 직접 병합되지 않습니다. feature → develop → release → main이 올바른 병합 체인입니다. 이 규칙을 위반하면 Git Flow 모델 전체의 목적이 무효화됩니다.

main 작업 명령어 예제

시나리오를 고려해보세요: 팀이 릴리스 v2.5.0 준비를 완료했습니다. release 브랜치가 검토되었고 main에 병합할 준비가 되었습니다. 병합 후 태그가 생성되고 릴리스가 게시됩니다.

# main으로 전환 및 업데이트
git checkout main
git pull origin main

# 검증된 release 브랜치 병합
git merge --no-ff release/2.5.0

# 릴리스 태그 생성
git tag -a v2.5.0 -m "Release 2.5.0 - Payment integration"

# main과 태그를 서버에 보내기
git push origin main --tags

--no-ff 플래그(fast-forward 없음)는 포인터를 단순히 이동하여 병합을 수행할 수 있었더라도 병합 커밋 생성을 보장합니다. 이렇게 하면 변경 사항이 release 브랜치에서 왔다는 정보가 보존되어 기록 분석이 용이해집니다.

main을 통한 hotfix 작업

프로덕션에서 중요한 오류가 발견되면 프로세스가 일반 릴리스와 다릅니다. hotfix는 main에서 생성되고, 수정 후 main과 develop 모두에 병합됩니다.

프로덕션에서 중요한 오류가 발견되면 프로세스가 일반 릴리스와 다릅니다. hotfix는 main에서 생성되고, 수정 후 main과 develop 모두에 병합됩니다.

# main에서 hotfix 브랜치 생성
git checkout main
git checkout -b hotfix/2.5.1-crash-fix

# 수정 및 커밋
git add src/fix/
git commit -m "Fix crash on login screen"

# hotfix를 main으로 다시 병합
git checkout main
git merge --no-ff hotfix/2.5.1-crash-fix
git tag -a v2.5.1 -m "Hotfix 2.5.1"
git push origin main --tags

# develop에도 hotfix 병합
git checkout develop
git merge --no-ff hotfix/2.5.1-crash-fix
git push origin develop

# hotfix 브랜치 삭제
git branch -d hotfix/2.5.1-crash-fix