master ─────────────────────────────> (프로덕션)
    ↑                              ↑
develop ───────┬──────────────────┘
               ↑
          feature/login
          feature/payment
          ...

main ─────────────────────────────────> (항상 배포 가능)
    ↓                             ↗
  feature/add-login ──────────────┘
  feature/fix-bug ────────────────┘

# ✅ main 브랜치는 항상 이 상태여야 합니다
- 모든 테스트 통과
- 빌드 성공
- 실제 프로덕션에서 동작 가능

# main에서 새 브랜치 생성
git checkout main
git pull origin main
git checkout -b feature/add-user-profile

# ✅ 좋은 브랜치 이름
feature/add-login-button
fix/memory-leak-in-dashboard
experiment/new-search-algorithm
hotfix/security-vulnerability
 
# ❌ 나쁜 브랜치 이름
test
my-branch
feature1
temp

# 1. main 브랜치로 이동
git checkout main
 
# 2. 원격 저장소의 최신 내용을 가져오기
git pull origin main
 
# 3. 새 기능 브랜치 생성 및 이동
git checkout -b feature/add-dark-mode

# 현재 브랜치 확인
git branch
# 출력:
# * feature/add-dark-mode
#   main

# 1. 파일 수정 (예: 다크 모드 CSS 추가)
# src/styles/dark-mode.css 파일 생성
 
# 2. 변경사항 확인
git status
 
# 3. 변경된 파일 스테이징
git add src/styles/dark-mode.css
 
# 4. 커밋 (명확한 메시지 작성)
git commit -m "feat: Add dark mode CSS styles"

# ✅ 좋은 커밋 메시지
feat: Add user authentication feature
fix: Resolve memory leak in dashboard
docs: Update API documentation
refactor: Simplify user validation logic
 
# ❌ 나쁜 커밋 메시지
update
fix bug
changes
WIP

# 첫 번째 작업
git add src/styles/dark-mode.css
git commit -m "feat: Add dark mode base styles"
 
# 두 번째 작업
git add src/components/ThemeToggle.tsx
git commit -m "feat: Add theme toggle component"
 
# 세 번째 작업
git add src/hooks/useDarkMode.ts
git commit -m "feat: Add dark mode custom hook"

# 처음 푸시하는 경우 (브랜치 생성과 함께)
git push -u origin feature/add-dark-mode
 
# 이후 푸시하는 경우
git push

## 변경 사항
- 다크 모드 CSS 스타일 추가
- 테마 토글 컴포넌트 구현
- useDarkMode 커스텀 훅 생성
 
## 테스트
- [ ] 라이트 모드에서 다크 모드로 전환 확인
- [ ] 로컬 스토리지에 테마 설정 저장 확인
- [ ] 새로고침 후 테마 유지 확인
 
## 스크린샷
[다크 모드 스크린샷 첨부]
 
## 관련 이슈
Closes #123

# 1. 피드백에 따라 코드 수정
# 파일 수정...
 
# 2. 수정사항 커밋
git add .
git commit -m "refactor: Apply code review feedback"
 
# 3. 다시 푸시 (같은 PR에 자동으로 반영됨)
git push

리뷰어: "다크 모드 토글 버튼의 접근성을 개선할 수 있을까요?"
작성자: "좋은 지적입니다. aria-label을 추가하겠습니다."

리뷰어: "테마 변경 시 깜빡임이 발생하는데, 트랜지션을 추가하면 어떨까요?"
작성자: "CSS transition을 추가해서 부드럽게 전환되도록 개선했습니다."

# 1. main 브랜치로 이동
git checkout main
 
# 2. 최신 상태로 업데이트
git pull origin main
 
# 3. feature 브랜치 병합
git merge feature/add-dark-mode
 
# 4. 원격 저장소에 푸시
git push origin main
 
# 5. 로컬 feature 브랜치 삭제
git branch -d feature/add-dark-mode
 
# 6. 원격 feature 브랜치 삭제
git push origin --delete feature/add-dark-mode

# 자동 배포 설정이 되어 있다면
# main 브랜치에 병합되면 자동으로 배포됩니다
 
# 수동 배포의 경우
git checkout main
git pull origin main
npm run deploy

# 1. 최신 main에서 hotfix 브랜치 생성
git checkout main
git pull origin main
git checkout -b hotfix/fix-login-error
 
# 2. 버그 수정 및 커밋
# 파일 수정...
git add .
git commit -m "fix: Resolve login authentication error"
 
# 3. 푸시
git push -u origin hotfix/fix-login-error
 
# 4. PR 생성하고 빠르게 리뷰 받기
# GitHub에서 PR 생성...
 
# 5. 승인되면 즉시 병합 및 배포
# GitHub에서 Merge...

# 1. 실험용 브랜치 생성
git checkout main
git pull origin main
git checkout -b experiment/new-search-algorithm
 
# 2. 실험 진행
# 코드 작성 및 테스트...
git add .
git commit -m "experiment: Try new search algorithm"
git push -u origin experiment/new-search-algorithm
 
# 3. 실험 결과가 좋으면 PR 생성
# 실험 결과가 좋지 않으면 브랜치 삭제
git checkout main
git branch -D experiment/new-search-algorithm
git push origin --delete experiment/new-search-algorithm

# 1. 작업 중 main이 업데이트된 경우
git checkout feature/add-dark-mode
 
# 2. main의 최신 변경사항 가져오기
git fetch origin main
 
# 3. 현재 브랜치에 main 병합
git merge origin/main
 
# 4. 충돌 발생 시
# 충돌 파일 수정...
git add .
git commit -m "merge: Resolve conflicts with main"
 
# 5. 푸시
git push

// 충돌이 발생한 파일
<<<<<<< HEAD
const theme = 'dark';
=======
const theme = 'light';
>>>>>>> origin/main
 
// 해결 후
const theme = localStorage.getItem('theme') || 'light';

# 기능 개발
feature/add-user-authentication
feature/implement-payment-system
 
# 버그 수정
fix/resolve-memory-leak
fix/correct-date-formatting
 
# 문서 작업
docs/update-api-documentation
docs/add-deployment-guide
 
# 리팩토링
refactor/simplify-auth-logic
refactor/optimize-database-queries
 
# 실험
experiment/test-new-ui
experiment/try-different-algorithm
 
# 긴급 수정
hotfix/security-patch
hotfix/critical-bug-fix

# ✅ 좋은 습관: 작은 단위로 여러 번 커밋
git commit -m "feat: Add login button component"
git commit -m "feat: Add login form validation"
git commit -m "feat: Implement login API integration"
 
# ❌ 나쁜 습관: 모든 작업을 한 번에 커밋
git commit -m "feat: Add entire login feature"

# 큰 기능을 작은 PR로 나누기
feature/user-profile
├── feature/user-profile-ui       (UI 컴포넌트만)
├── feature/user-profile-api      (API 연동만)
└── feature/user-profile-tests    (테스트만)

## 목적
이 PR의 목적을 간단히 설명합니다.
 
## 변경 사항
- 변경 사항 1
- 변경 사항 2
- 변경 사항 3
 
## 테스트 방법
1. 단계 1
2. 단계 2
3. 예상 결과
 
## 체크리스트
- [ ] 테스트 코드 작성
- [ ] 문서 업데이트
- [ ] 코드 스타일 가이드 준수
- [ ] 성능 영향 검토
 
## 스크린샷 (UI 변경 시)
[스크린샷 첨부]
 
## 관련 이슈
Closes #123
Related to #456

# .github/workflows/ci.yml
# 자동 테스트 설정 예시
name: CI
 
on:
  pull_request:
    branches: [ main ]
 
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Install dependencies
        run: npm install
      - name: Run tests
        run: npm test
      - name: Run linter
        run: npm run lint

master (프로덕션)
  ↑
develop (개발)
  ↑
feature/* (기능 개발)
release/* (릴리스 준비)
hotfix/* (긴급 수정)

main (프로덕션 + 개발)
  ↑
feature/* (모든 작업)

# 평균 명령어 수: 15~20개
git checkout develop
git pull origin develop
git checkout -b feature/new-feature
# 작업...
git checkout develop
git merge feature/new-feature
git checkout -b release/1.0.0
# 테스트...
git checkout master
git merge release/1.0.0
git tag v1.0.0
git checkout develop
git merge master

# 평균 명령어 수: 6~8개
git checkout main
git pull origin main
git checkout -b feature/new-feature
# 작업...
git push -u origin feature/new-feature
# GitHub에서 PR 생성 및 병합

# 핵심 워크플로우가 단순합니다
1. 브랜치 생성 → 2. 작업 → 3. PR → 4. 병합 → 5. 배포

# 변경사항이 즉시 프로덕션에 반영됩니다
feature → PR → merge → deploy (1~2시간 이내)
 
# Git Flow는 여러 단계를 거칩니다
feature → develop → release → master → deploy (며칠~주 단위)

# .github/workflows/deploy.yml
name: Deploy
 
on:
  push:
    branches: [ main ]
 
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to production
        run: npm run deploy

# ❌ GitHub Flow는 명시적인 버전이 없습니다
main: commit1 → commit2 → commit3 → ...
 
# ✅ Git Flow는 명확한 버전이 있습니다
master: v1.0.0 → v1.1.0 → v2.0.0

# Git 태그를 사용하여 버전 관리
git tag -a v1.0.0 -m "Release version 1.0.0"
git push origin v1.0.0

# 문제 상황: main에 버그가 있는 커밋이 있고,
# 이미 다른 기능들이 병합되어 있을 때
 
main: [good] → [bug] → [feature1] → [feature2]

# Revert 커밋을 사용
git revert <buggy-commit-hash>
 
# 또는 새로운 수정 커밋 추가
git checkout -b hotfix/fix-critical-bug
# 수정...
# PR 생성 및 빠르게 병합

# 10명 이상이 동시에 main에 병합하면
# 충돌 해결에 많은 시간이 소요됩니다

# 작업 시작 전 main을 자주 업데이트
git checkout feature/my-feature
git fetch origin main
git rebase origin/main
 
# 작은 단위로 자주 병합
# 하루에 여러 개의 작은 PR을 병합

# ❌ GitHub Flow는 단일 환경(프로덕션)에 최적화
main → production
 
# Git Flow는 여러 환경을 지원
master → production
develop → staging
feature → development

# 환경별 브랜치 추가 (Modified GitHub Flow)
main → production
staging → staging environment
develop → development environment

main      (프로덕션)
  ↑
staging   (스테이징 환경)
  ↑
feature/* (기능 개발)

# 1. feature 브랜치에서 작업
git checkout -b feature/new-feature
 
# 2. staging에 병합하여 테스트
git checkout staging
git merge feature/new-feature
git push origin staging
# 스테이징 환경에서 테스트...
 
# 3. 테스트 통과 후 main에 병합
git checkout main
git merge feature/new-feature
git push origin main
# 프로덕션 배포...

# 주기적으로 릴리스 태그 생성
git checkout main
git tag -a v1.2.0 -m "Release 1.2.0"
git push origin v1.2.0
 
# 릴리스 노트 자동 생성
git log v1.1.0..v1.2.0 --oneline > RELEASE_NOTES.md

// 완료되지 않은 기능도 main에 병합
// 하지만 Feature Flag로 숨김
 
const FEATURES = {
  NEW_UI: process.env.FEATURE_NEW_UI === 'true',
  PAYMENT_V2: process.env.FEATURE_PAYMENT_V2 === 'true'
};
 
function App() {
  return (
    <>
      {FEATURES.NEW_UI ? <NewUI /> : <OldUI />}
      {FEATURES.PAYMENT_V2 && <PaymentV2 />}
    </>
  );
}

# 1. 잘못된 커밋의 해시 확인
git log --oneline
 
# 2. Revert 커밋 생성
git revert <commit-hash>
 
# 3. 푸시
git push origin main
 
# Revert는 기존 커밋을 유지하면서 변경사항을 되돌립니다
# 따라서 안전하고 추적 가능합니다

# 기능들이 서로 영향을 주지 않는다면
# 준비된 순서대로 병합하면 됩니다
 
feature/add-user-profile → main (월요일)
feature/add-payment      → main (화요일)
feature/add-search       → main (수요일)
 
# 기능들이 서로 의존한다면
# 의존성을 고려하여 순서대로 병합합니다

# 1. 최신 main 가져오기
git checkout feature/my-feature
git fetch origin main
 
# 2. main의 변경사항 병합
git merge origin/main
 
# 또는 rebase 사용 (커밋 히스토리가 깔끔함)
git rebase origin/main
 
# 3. 충돌 해결 후 푸시
git push --force-with-lease origin feature/my-feature

# ❌ 절대 하지 말 것
git checkout main
git add .
git commit -m "Quick fix"
git push origin main
 
# ✅ 항상 브랜치를 만들어서 작업
git checkout -b hotfix/quick-fix
git add .
git commit -m "Quick fix"
git push -u origin hotfix/quick-fix
# PR 생성...

# 1. GitHub에서 PR 병합 시 자동 삭제 옵션 체크
# "Delete branch" 버튼 클릭
 
# 2. 로컬에서 브랜치 삭제
git checkout main
git pull origin main
git branch -d feature/my-feature
 
# 3. 원격 브랜치가 남아있다면 삭제
git push origin --delete feature/my-feature
 
# 4. 오래된 원격 브랜치 참조 정리
git fetch --prune