포스트

[GitHub 100일 챌린지] Day 41 - 브랜치 개념과 필요성

게시
Day 41 - 브랜치 개념과 필요성
Day 41 - 브랜치 개념과 필요성
By YonYonWare
13 분읽는 시간
[GitHub 100일 챌린지] Day 41 - 브랜치 개념과 필요성

100일 챌린지 Day 41 - 브랜치의 개념을 이해하고 왜 필요한지 알아봅니다.

배울 내용

  1. 브랜치란 무엇인가
  2. 브랜치가 필요한 이유
  3. 브랜치 활용 시나리오

Topic1. 브랜치란 무엇인가

브랜치(Branch)는 독립적인 작업 공간입니다.

브랜치의 핵심 개념

나뭇가지처럼 갈라지는 작업 흐름:

gitGraph
    commit id: "Initial"
    commit id: "Add feature"
    branch develop
    checkout develop
    commit id: "Start new feature"
    commit id: "Complete feature"
    checkout main
    commit id: "Fix bug"

main 브랜치:

  • Git 저장소의 기본 브랜치
  • 과거에는 master로 불렸으나 main으로 변경
  • 보통 배포 가능한 안정적인 코드 유지

브랜치 포인터:

1
2
3

main    →  C3
            ↑
develop →  C4

브랜치의 작동 원리

1. 커밋은 체인처럼 연결:

1
2
3

C1 ← C2 ← C3 ← C4
             ↑
            main

2. 브랜치는 특정 커밋을 가리키는 포인터:

1
2
3
4
5
6
7

      C3 ← C4
     ↗      ↑
C1 ← C2    main
     ↘
      C5 ← C6
           ↑
        develop

3. HEAD는 현재 작업 중인 브랜치를 가리킴:

1
2
3

main    →  C4
develop →  C6
HEAD    →  main  (현재 main 브랜치에서 작업 중)

해보기: 브랜치 개념 이해하기

시나리오: 웹사이트 개발 중 새 기능 추가

1
2
3
4
5
6

# 현재 상태 확인
git log --oneline --all --graph

# 출력 예시
* a1b2c3d (HEAD -> main) Add homepage
* d4e5f6g Initial commit

브랜치 없이 작업하면?

1
2
3
4
5

# main에서 직접 작업 (위험!)
git add new-feature.js
git commit -m "Add experimental feature"

# 문제 발생! 버그가 있는데 이미 main에 들어감

브랜치를 사용하면?

1
2
3
4
5

# 새 브랜치에서 안전하게 작업
git branch feature-login
git checkout feature-login

# 이제 main은 안전하게 보호됨!

결과

브랜치 구조 시각화:

gitGraph
    commit id: "Initial"
    commit id: "Homepage" tag: "main"
    branch feature-login
    checkout feature-login
    commit id: "Login form"
    commit id: "Auth logic"

장점:

  • main은 항상 안전한 상태 유지
  • 실험적인 기능은 별도 브랜치에서
  • 문제 발생 시 해당 브랜치만 삭제

Topic2. 브랜치가 필요한 이유

실무에서 브랜치가 필수인 5가지 이유입니다.

1. 안전한 실험 환경

main 브랜치 보호:

1
2
3
4
5

# main은 항상 배포 가능한 상태
main (배포 가능) ──────→ 프로덕션

# 새 기능은 별도 브랜치에서
feature  ──→ 실험 ──→ 테스트 ──→ main에 병합

실무 예시:

1
2
3
4
5
6

# 새로운 결제 시스템 개발
git checkout -b feature/payment-gateway

# 안전하게 개발 및 테스트
# 문제 없으면 main에 병합
# 문제 있으면 브랜치 삭제

2. 병렬 작업 가능

여러 개발자가 동시에 작업:

gitGraph
    commit id: "v1.0"
    branch feature-A
    branch feature-B
    checkout feature-A
    commit id: "개발자 A 작업"
    checkout feature-B
    commit id: "개발자 B 작업"
    checkout main
    merge feature-A
    merge feature-B
    commit id: "v1.1"

실무 시나리오:

1
2
3
4
5
6
7
8
9
10

# 팀원 A: 로그인 기능
git checkout -b feature/login

# 팀원 B: 검색 기능
git checkout -b feature/search

# 팀원 C: 버그 수정
git checkout -b hotfix/security-bug

# 모두 독립적으로 작업 가능!

3. 체계적인 코드 관리

작업 단위별로 브랜치 분리:

1
2
3
4
5
6
7

main          (배포용)
  ├─ develop  (개발용)
  │   ├─ feature/login
  │   ├─ feature/payment
  │   └─ feature/search
  ├─ hotfix/bug-123
  └─ release/v1.2.0

브랜치 명명 규칙:

1
2
3
4

feature/기능명    # 새 기능 개발
hotfix/버그명     # 긴급 버그 수정
release/버전      # 릴리스 준비
bugfix/버그명     # 일반 버그 수정

4. 안전한 롤백

문제 발생 시 쉽게 되돌리기:

1
2
3
4
5
6
7
8
9
10
11

# 새 기능 개발
git checkout -b feature/new-ui

# 50개 커밋 작업...
git commit -m "..." (x50)

# 문제 발생! 기능 취소하기로 결정
git checkout main
git branch -D feature/new-ui

# main은 여전히 안전한 상태!

5. 코드 리뷰 용이

Pull Request 기반 리뷰:

1
2
3
4
5
6
7
8
9

# 1. 기능 브랜치에서 개발
git checkout -b feature/api-update

# 2. GitHub에 푸시
git push origin feature/api-update

# 3. Pull Request 생성
# 4. 팀원들이 코드 리뷰
# 5. 승인 후 main에 병합

해보기: 브랜치로 안전하게 작업하기

상황: 웹사이트 리디자인 (실험적)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

# 1. 현재 안전한 main 백업
git checkout main
git log --oneline -3

# 2. 실험용 브랜치 생성
git checkout -b redesign-experiment

# 3. 대담한 변경 시도
echo "New design" > index.html
git add index.html
git commit -m "Experimental redesign"

# 4. 마음에 안 들면?
git checkout main
git branch -D redesign-experiment

# 5. main은 여전히 안전!

결과

브랜치 없이:

1

❌ main에 직접 커밋 → 롤백 복잡 → 위험

브랜치 사용:

1

✅ 브랜치에서 작업 → 마음에 안 들면 삭제 → 안전

Topic3. 브랜치 활용 시나리오

실무에서 자주 사용하는 브랜치 전략입니다.

시나리오 1: 신규 기능 개발

상황: 사용자 프로필 기능 추가

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

# 1. main에서 새 브랜치 생성
git checkout main
git checkout -b feature/user-profile

# 2. 기능 개발
touch profile.js
git add profile.js
git commit -m "Add profile page"

touch profile.css
git add profile.css
git commit -m "Style profile page"

# 3. 테스트 완료 후 main에 병합
git checkout main
git merge feature/user-profile

# 4. 브랜치 정리
git branch -d feature/user-profile

브랜치 흐름:

gitGraph
    commit id: "v1.0"
    branch feature/user-profile
    checkout feature/user-profile
    commit id: "Add profile"
    commit id: "Style profile"
    checkout main
    merge feature/user-profile
    commit id: "v1.1"

시나리오 2: 긴급 버그 수정

상황: 프로덕션에서 버그 발견!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# 1. main에서 hotfix 브랜치 생성
git checkout main
git checkout -b hotfix/login-error

# 2. 빠르게 버그 수정
git add auth.js
git commit -m "Fix login validation bug"

# 3. 즉시 main에 병합
git checkout main
git merge hotfix/login-error

# 4. 배포 및 브랜치 삭제
git push origin main
git branch -d hotfix/login-error

긴급 수정 흐름:

gitGraph
    commit id: "v1.0"
    commit id: "발견된 버그!"
    branch hotfix/login-error
    checkout hotfix/login-error
    commit id: "Fix bug"
    checkout main
    merge hotfix/login-error
    commit id: "v1.0.1"

시나리오 3: 여러 기능 동시 개발

상황: 3개 팀이 동시에 작업

1
2
3
4
5
6
7
8
9
10
11
12
13

# 팀 A: 결제 기능
git checkout -b feature/payment
# ... 작업 ...

# 팀 B: 알림 기능
git checkout main  # main에서 시작
git checkout -b feature/notification
# ... 작업 ...

# 팀 C: 검색 기능
git checkout main  # main에서 시작
git checkout -b feature/search
# ... 작업 ...

동시 개발 흐름:

gitGraph
    commit id: "v1.0"
    branch feature/payment
    branch feature/notification
    branch feature/search
    checkout feature/payment
    commit id: "Payment API"
    checkout feature/notification
    commit id: "Notification service"
    checkout feature/search
    commit id: "Search engine"
    checkout main
    merge feature/payment
    merge feature/notification
    merge feature/search
    commit id: "v2.0"

시나리오 4: 릴리스 준비

상황: v2.0 출시 준비

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

# 1. 릴리스 브랜치 생성
git checkout -b release/v2.0

# 2. 버전 번호 업데이트
echo "2.0.0" > VERSION
git commit -am "Bump version to 2.0.0"

# 3. 최종 테스트 및 버그 수정
git commit -am "Fix minor UI issues"

# 4. main에 병합 및 태그
git checkout main
git merge release/v2.0
git tag v2.0.0

# 5. develop에도 병합
git checkout develop
git merge release/v2.0

해보기: Git Flow 전략 실습

Git Flow 브랜치 구조 만들기:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

# 1. develop 브랜치 생성
git checkout -b develop

# 2. feature 브랜치에서 개발
git checkout -b feature/shopping-cart

# 작업 커밋
echo "cart.js" > cart.js
git add cart.js
git commit -m "Add shopping cart"

# 3. develop에 병합
git checkout develop
git merge feature/shopping-cart

# 4. release 브랜치 생성
git checkout -b release/v1.0

# 버전 업데이트
echo "1.0.0" > VERSION
git add VERSION
git commit -m "Release v1.0"

# 5. main에 병합
git checkout main
git merge release/v1.0
git tag v1.0.0

결과

브랜치 전략의 효과:

1
2
3
4

✅ 각 작업이 독립적으로 진행
✅ main은 항상 안전한 상태
✅ 롤백과 버그 수정이 쉬움
✅ 팀 협업이 원활함

실무 권장 사항:

  1. 작은 단위로 브랜치 생성: 기능별, 버그별로 분리
  2. 명확한 이름 사용: feature/login, hotfix/bug-123
  3. 정기적으로 병합: 브랜치가 너무 오래되지 않도록
  4. 사용 완료한 브랜치 삭제: 저장소를 깔끔하게 유지

정리

오늘 배운 내용:

1. 브랜치 개념:

  • 독립적인 작업 공간
  • 커밋을 가리키는 포인터
  • HEAD는 현재 브랜치를 가리킴

2. 브랜치가 필요한 이유:

  • 안전한 실험 환경
  • 병렬 작업 가능
  • 체계적인 코드 관리
  • 안전한 롤백
  • 코드 리뷰 용이

3. 활용 시나리오:

  • 신규 기능 개발
  • 긴급 버그 수정
  • 여러 기능 동시 개발
  • 릴리스 준비

다음 단계: Day 42에서 브랜치 생성하는 방법을 실습합니다.

완료 체크:

  • 브랜치가 무엇인지 설명할 수 있다
  • 브랜치가 왜 필요한지 이해했다
  • 실무에서 브랜치를 어떻게 활용하는지 안다
← Day 40 전체 커리큘럼 Day 42 →
GitHub100일챌린지, Phase05
github git 100days day41 branch
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.