GitHub Flow

GitHub Flow는 GitHub에서 제안한 브랜치 전략으로, 메인 브랜치(main)와 기능 브랜치(feature)만을 사용하여 개발과 배포를 진행한다. 각 기능은 별도의 브랜치에서 개발되며, Pull Request를 통해 코드 리뷰와 테스트를 거친 후 메인 브랜치에 병합된다. 이러한 방식은 빠른 피드백과 지속적인 배포를 가능하게 한다.

Git Flow의 복잡성을 제거하고 웹 기반 애플리케이션 개발에 최적화된 워크플로우로, main 브랜치를 중심으로 기능 브랜치를 활용하여 빠른 개발 주기와 안정적인 배포를 동시에 달성할 수 있다.

핵심 개념

  • 메인 브랜치(main): 항상 배포 가능한 상태를 유지하는 브랜치이다.
  • 기능 브랜치(feature): 새로운 기능이나 수정 사항을 개발하는 브랜치로, 작업 완료 후 Pull Request를 통해 메인 브랜치에 병합된다.

모든 작업은 설명적인 이름의 기능 브랜치에서 수행한다.
정기적인 커밋과 원격 저장소 푸시
승인 후 즉시 main 브랜치에 병합되며 즉시 배포된다.

graph TD
    main[main 브랜치] -->|분기| feature[feature/기능]
    feature -->|풀 리퀘스트| main
    main -->|즉시 배포| Production

Github Flow
https://github.com/SvanBoxel/release-based-workflow/issues/1

목적

  • 개발 프로세스의 단순화 및 효율성 향상
  • 지속적 배포 환경 지원
  • 협업과 코드 리뷰 문화 강화
  • 빠른 피드백 사이클 구현
  • 안정적인 배포 프로세스 확립

필요성

  • 웹 기반 애플리케이션의 빈번한 배포 요구사항 충족
  • Git Flow보다 단순한 워크플로우 필요
  • 팀 간 효과적인 협업 도구 요구
  • 코드 품질 관리와 지식 공유 필요
  • DevOps 문화 적용을 위한 프로세스 요구

주요 기능

  1. 브랜치 관리: main 브랜치와 피처 브랜치 기반 개발
  2. Pull Request: 코드 리뷰, 토론, CI/CD 통합
  3. 지속적 통합: 자동화된 테스트 및 빌드
  4. 즉각적 배포: main 브랜치 병합 후 자동 배포
  5. 이슈 추적: GitHub Issues와 통합된 작업 관리

역할

  1. 개발 프로세스 표준화: 팀 전체의 일관된 작업 방식 제공
  2. 품질 관리: 코드 리뷰를 통한 품질 향상
  3. 배포 자동화: 지속적 배포 파이프라인 지원
  4. 협업 촉진: 팀원 간 효과적인 소통 채널 제공
  5. 위험 관리: 안정적인 배포 프로세스로 배포 위험 최소화

특징

  • 단순한 브랜치 구조: 메인 브랜치와 기능 브랜치만을 사용하여 관리가 용이하다.
  • 빠른 배포 주기: 변경 사항을 빠르게 배포하여 사용자 피드백을 신속하게 반영할 수 있다.

장점과 단점

구분항목설명
✅ 장점단순성복잡한 브랜치 전략이 없어 학습 곡선이 낮음
신속한 배포main 브랜치 병합 즉시 배포로 빠른 릴리스 가능
지속적 통합CI/CD와 자연스럽게 통합되어 자동화 용이
코드 리뷰 문화PR을 통한 필수 코드 리뷰로 품질 향상
투명성모든 변경사항이 PR로 추적되어 이력 관리 용이
⚠ 단점버전 관리 제한명시적인 버전 관리가 어려움
복잡한 릴리스 미지원여러 버전 동시 관리가 필요한 프로젝트에 부적합
핫픽스 처리긴급 수정사항도 전체 PR 프로세스 거쳐야 함
브랜치 관리적절한 브랜치 네이밍 규칙이 없으면 혼란 발생
테스트 환경 부족별도의 스테이징 환경이 없으면 문제 발생 시 대응이 어려울 수 있습니다.

작동 원리

GitHub Flow 작동 원리의 상세 프로세스:

  1. 브랜치 생성:

    1
    
    git checkout -b feature/user-authentication
    
  2. 변경사항 커밋:

    1
    2
    3
    
    git add .
    git commit -m "feat: 사용자 인증 기능 추가"
    git push origin feature/user-authentication
    
  3. Pull Request 생성:

    • GitHub 웹 인터페이스에서 PR 생성
    • 설명적인 제목과 상세 설명 작성
    • 리뷰어 지정
  4. 코드 리뷰 프로세스:

    • 팀원들의 피드백
    • 필요한 수정사항 반영
    • CI 테스트 통과 확인
  5. 병합 및 배포:

    • PR 승인 후 main 브랜치에 병합
    • 자동화된 배포 파이프라인 실행

구성 요소 및 아키텍처

GitHub Flow의 주요 구성 요소와 각각의 기능:

  1. main 브랜치
    • 기능: 프로덕션 배포 코드 유지
    • 역할: 항상 안정적이고 배포 가능한 상태 보장
  2. 피처 브랜치
    • 기능: 개별 기능 개발 공간 제공
    • 역할: 독립적인 작업 환경 구성
  3. Pull Request
    • 기능: 코드 변경사항 검토 및 토론 플랫폼
    • 역할: 품질 관리와 지식 공유
  4. CI/CD 파이프라인
    • 기능: 자동화된 테스트, 빌드, 배포
    • 역할: 품질 보증과 배포 자동화
  5. 이슈 트래커
    • 기능: 작업 추적 및 버그 관리
    • 역할: 프로젝트 진행 상황 모니터링

아키텍처 구조:

1
2
3
4
5
6
[main branch] 
      |
[feature branch] --> [Pull Request] --> [Code Review] --> [CI/CD] --> [Merge to main] --> [Deploy]
      |                    |                |                |
      |                    |                |                |
[Local commits] <->[Discussion] <->[Tests] <->[Build]

상황별 적용 시나리오

 기본적으로 단순성과 지속적 배포에 초점을 맞춘 워크플로우지만, 실제 운영에서는 팀별로 필요에 따라 브랜치 유형을 확장해 사용한다.

상황적용 방법기대 효과주의사항
신규 기능 개발feature/user-auth 브랜치 생성 후 개발독립적인 개발 환경 제공브랜치 네이밍 규칙 준수
버그 수정bugfix/login-error 브랜치에서 수정빠른 버그 대응 가능테스트 케이스 필수 추가
긴급 핫픽스hotfix/security-patch 브랜치 사용긴급 문제 신속 해결최소한의 변경만 포함
코드 리팩토링refactor/api-structure 브랜치 활용코드 품질 개선기능 변경 없음 확인
문서 업데이트docs/api-documentation 브랜치 사용문서화 개선관련 코드와 동기화

Github Flow 시작하기

GitHub Flow는 간단하고 효과적인 브랜칭 전략으로, 다음과 같은 핵심 원칙을 가지고 있다:

  1. main(또는 master) 브랜치는 항상 배포 가능한 상태 유지
  2. 새로운 기능이나 수정은 별도의 브랜치에서 작업
  3. 정기적으로 커밋하고 원격 브랜치에 푸시
  4. 피드백이나 도움이 필요하거나 작업이 완료되면 Pull Request 생성
  5. 다른 팀원의 리뷰와 승인 후 main 브랜치에 머지
  6. main 브랜치에 머지되면 즉시 배포

1. 저장소 초기 설정

1
2
3
4
5
6
# 새 저장소 생성 또는 기존 저장소 클론
git clone https://github.com/username/repository.git
cd repository

# main 브랜치 확인
git branch

2. 브랜치 보호 규칙 설정

GitHub 웹사이트에서:

  1. 저장소의 Settings 탭으로 이동
  2. 좌측 메뉴에서 “Branches” 선택
  3. “Branch protection rules” 섹션에서 “Add rule” 클릭
  4. Branch name pattern에 “main” 입력
  5. 다음 옵션들을 선택:
    • Require a pull request before merging
    • Require approvals (최소 1명 이상)
    • Require status checks to pass before merging
    • Require branches to be up to date before merging
    • Include administrators
  6. “Create” 클릭

3. 이슈(Issue) 등록 및 관리

작업(기능 추가, 버그 수정 등)이 필요할 때 GitHub의 Issues 탭 혹은 Jira에서 이슈를 등록한다.
담당자(Assignee), 라벨(Label) 등으로 이슈를 명확히 관리한다.

4. 브랜치 생성

main 브랜치에서 새로운 브랜치를 만든다.
브랜치 이름은 보통 feature/이슈번호-설명fix/이슈번호-설명 등으로 작성한다.

1
2
3
git checkout main
git pull origin main
git checkout -b feature/123-add-login

브랜치 이름에 이슈 번호를 포함하면 추적이 쉽다.

5. 기능 개발 및 커밋

생성한 브랜치에서 기능 개발, 버그 수정 등 작업을 진행한다.
작업 단위로 커밋(Commit)을 남긴다.

1
2
git add .
git commit -m "로그인 기능 추가: #123"

6. 원격 저장소에 브랜치 Push

작업이 끝나면 브랜치를 원격 저장소에 Push한다.

1
git push origin feature/123-add-login

7. Pull Request(PR) 생성

  • GitHub 저장소에서 [Pull Requests] 메뉴로 이동하여 [New pull request]를 클릭한다.
  • base 브랜치는 main, compare 브랜치는 작업한 feature 브랜치로 지정한다.
  • PR 제목과 설명을 작성하고, 필요시 담당자(Assignee), 리뷰어(Reviewer) 지정 후 PR을 생성한다.

8. 코드 리뷰 및 테스트

  • 팀원들이 PR을 리뷰하고, 필요시 수정 요청(코멘트)을 남긴다.
  • CI(지속적 통합) 도구(GitHub Actions 등)로 자동 테스트가 실행되도록 워크플로우를 설정할 수 있다.
  • 리뷰 및 테스트가 완료되면 Approve(승인)한다.

9. PR 병합(Merge)

  • 리뷰가 끝나고 모든 조건이 충족되면 PR을 main 브랜치에 병합한다.
  • 병합 후, 작업 브랜치는 삭제해도 된다.

10. 로컬 Main 브랜치 업데이트

  • main 브랜치로 이동 후, 원격 저장소의 최신 내용을 pull 받아 동기화한다.

    1
    2
    
    git checkout main
    git pull origin main
    

Github Flow를 활용한 예시

GitHub 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
[개발자 로컬] --> [Feature Branch] --> [Push to Remote]
                                           |
                                           v
                                    [Pull Request]
                                           |
                                           v
                                    [Code Review]
                                     /     |     \
                                    /      |      \
                            [Unit Tests] [Lint] [Build]
                                    \      |      /
                                     \     |     /
                                    [Approval Process]
                                           |
                                           v
                                    [Merge to Main]
                                           |
                                           v
                                [Automated Deployment]
                                     /          \
                                    /            \
                        [Staging Deploy]   [Production Deploy]
                                |                  |
                                v                  v
                        [E2E Tests]        [Monitoring]

실제 개발 시나리오: 사용자 인증 기능 추가

1. 개발자 로컬 (Developer Local)

개발자가 새로운 사용자 인증 기능을 구현하기 위해 로컬 환경을 준비한다.

1
2
3
# 최신 main 브랜치로 업데이트
git checkout main
git pull origin main

2. Feature Branch

새로운 기능을 위한 브랜치를 생성한다.

1
2
3
4
5
6
7
# 기능 브랜치 생성 및 체크아웃
git checkout -b feature/user-authentication

# 작업 진행
# - src/auth/login.js 생성
# - src/auth/register.js 생성
# - tests/auth.test.js 생성

3. Push to Remote

로컬에서 작업한 내용을 원격 저장소로 푸시한다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
# 변경사항 커밋
git add .
git commit -m "feat: implement user authentication with JWT

- Add login endpoint with email/password validation
- Add registration with password hashing
- Add JWT token generation and validation
- Add unit tests for auth service"

# 원격 저장소로 푸시
git push -u origin feature/user-authentication

4. Pull Request

GitHub에서 Pull Request를 생성한다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
## 🔐 User Authentication Feature

### Description
Implements user authentication system using JWT tokens.

### Changes
- Added login and registration endpoints
- Implemented JWT token generation/validation
- Added password hashing with bcrypt
- Created auth middleware for protected routes

### Testing
- ✅ Unit tests for auth service
- ✅ Integration tests for API endpoints
- ✅ Manual testing with Postman

### Checklist
- [x] Code follows style guidelines
- [x] Tests pass
- [x] Documentation updated
- [x] No security vulnerabilities

Closes #123

5. Code Review

팀원들이 코드 리뷰를 진행한다.

Reviewer 1 Comment:

1
2
Line 45 in auth.service.js:
Consider using constant-time comparison for password validation to prevent timing attacks.

Developer Response:

1
Good catch! Updated to use crypto.timingSafeEqual() for password comparison.

Reviewer 2 Comment:

1
2
auth.middleware.js:
Should we add rate limiting to prevent brute force attacks?

Developer Response:

1
Added express-rate-limit middleware with 5 attempts per 15 minutes for login endpoint.

6. Automated Checks (Unit Tests, Lint, Build)

CI/CD 파이프라인이 자동으로 실행된다.

.github/workflows/ci.yml:

 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
name: CI

on:
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - name: Use Node.js
      uses: actions/setup-node@v2
      with:
        node-version: '18.x'
    
    - name: Install dependencies
      run: npm ci
    
    - name: Run linting
      run: npm run lint
    
    - name: Run tests
      run: npm test
    
    - name: Build project
      run: npm run build

CI Results:

1
2
3
✅ Linting - Passed
✅ Unit Tests - 42 passed
✅ Build - Success

7. Approval Process

코드 리뷰어들이 변경사항을 승인합니다.

  • Reviewer 1: ✅ Approved
  • Reviewer 2: ✅ Approved
  • CI/CD: ✅ All checks passed

8. Merge to Main

PR이 main 브랜치로 병합된다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
# GitHub에서 "Squash and merge" 버튼 클릭
# 또는 CLI에서:
git checkout main
git merge --squash feature/user-authentication
git commit -m "feat: implement user authentication system (#124)

* Add JWT-based authentication
* Implement login and registration endpoints
* Add password hashing and validation
* Include comprehensive test coverage

Co-authored-by: Reviewer1 <reviewer1@example.com>
Co-authored-by: Reviewer2 <reviewer2@example.com>"

9. Automated Deployment

배포 파이프라인이 자동으로 시작된다.

.github/workflows/deploy.yml:

 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
28
29
30
31
name: Deploy

on:
  push:
    branches: [ main ]

jobs:
  deploy-staging:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - name: Deploy to Staging
      run: |
        npm run build
        npm run deploy:staging
    
    - name: Run E2E Tests
      run: npm run test:e2e
    
  deploy-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - name: Deploy to Production
      run: |
        npm run build
        npm run deploy:production
    
    - name: Health Check
      run: npm run health-check:production

10. Staging Deploy

스테이징 환경으로 자동 배포된다.

1
2
3
4
5
6
7
8
9
# 배포 스크립트 실행
npm run deploy:staging

# 출력
🚀 Deploying to staging environment...
📦 Building application...
📤 Uploading artifacts...
✅ Deployment successful!
🌍 Staging URL: https://staging.myapp.com

11. E2E Tests

스테이징 환경에서 E2E 테스트가 실행된다.

cypress/integration/auth.spec.js:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
describe('Authentication Flow', () => {
  it('should allow user registration', () => {
    cy.visit('/register')
    cy.get('input[name="email"]').type('test@example.com')
    cy.get('input[name="password"]').type('securePassword123')
    cy.get('button[type="submit"]').click()
    cy.url().should('include', '/dashboard')
  })

  it('should allow user login', () => {
    cy.visit('/login')
    cy.get('input[name="email"]').type('test@example.com')
    cy.get('input[name="password"]').type('securePassword123')
    cy.get('button[type="submit"]').click()
    cy.getCookie('token').should('exist')
  })
})

12. Production Deploy

E2E 테스트 통과 후 프로덕션으로 배포된다.

1
2
3
4
5
6
7
8
9
# 프로덕션 배포
npm run deploy:production

# 출력
🚀 Deploying to production environment...
📦 Building optimized bundle...
📤 Uploading to production servers...
✅ Deployment successful!
🌍 Production URL: https://myapp.com

13. Monitoring

프로덕션 모니터링이 시작된다.

monitoring/alerts.js:

 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
28
29
30
// 모니터링 설정
const alerts = {
  authenticationErrors: {
    threshold: 10,  // 10개 이상의 인증 실패
    timeWindow: '5m',  // 5분 이내
    severity: 'high',
    notify: ['security-team@company.com']
  },
  
  loginLatency: {
    threshold: 1000,  // 1초 이상의 응답 시간
    timeWindow: '1m',
    severity: 'medium',
    notify: ['devops-team@company.com']
  }
}

// Grafana 대시보드 설정
const dashboard = {
  panels: [
    {
      title: 'Authentication Success Rate',
      query: 'rate(auth_success_total[5m]) / rate(auth_attempts_total[5m])'
    },
    {
      title: 'JWT Token Generation Time',
      query: 'histogram_quantile(0.95, rate(jwt_generation_duration_seconds_bucket[5m]))'
    }
  ]
}

모니터링 알림 예시:

1
2
3
4
5
6
🔔 Alert: High authentication failure rate detected
- Current rate: 25 failures/minute
- Normal rate: 2-3 failures/minute
- Affected endpoint: /api/auth/login
- Time: 2024-01-20 15:30:22 UTC
- Action: Security team notified

실무에서 효과적으로 적용하기 위한 고려사항 및 주의할 점

고려사항세부내용권장사항피해야 할 점
브랜치 네이밍일관된 명명 규칙 사용feature/[기능명], bugfix/[이슈번호] 형식 사용모호하거나 일반적인 이름 피하기
PR 크기 관리리뷰 가능한 크기 유지200-400줄 이내로 제한거대한 변경사항 한 번에 제출
코드 리뷰 문화건설적인 피드백 제공구체적인 개선 제안, 긍정적 피드백 포함개인 비난, 모호한 지적
CI/CD 설정자동화 테스트 완비단위/통합 테스트 필수 실행테스트 없는 병합 허용
커밋 메시지명확한 메시지 작성컨벤션 준수 (feat:, fix:, docs: 등)의미 없는 메시지 사용

최적화하기 위한 고려사항 및 주의할 점

최적화 영역방법기대 효과주의사항
CI 파이프라인병렬 테스트 실행, 캐싱 활용빌드 시간 단축과도한 병렬화로 리소스 고갈 주의
브랜치 관리정기적인 오래된 브랜치 정리저장소 크기 최적화활성 작업 브랜치 삭제 주의
PR 프로세스자동 리뷰어 지정, 템플릿 사용리뷰 시간 단축자동화로 인한 품질 저하 방지
병합 전략Squash merge 활용깔끔한 커밋 이력 유지상세 이력 필요한 경우 제외
배포 자동화스테이징 환경 자동 배포배포 검증 시간 단축프로덕션 자동 배포는 신중히 결정

최신 동향

주제항목설명
AI 통합AI 코드 리뷰GitHub Copilot으로 자동 코드 리뷰 제안
AI PR 설명 생성커밋 내용 기반 자동 PR 설명 작성
보안 강화자동 취약점 스캔Dependabot, CodeQL 통합 강화
시크릿 탐지민감 정보 커밋 방지 자동화
DevSecOps보안 게이트보안 요구사항 자동 검증
컴플라이언스 체크규정 준수 자동 확인
협업 도구Slack 통합 강화PR 이벤트 실시간 알림
VS Code 통합IDE 내 PR 리뷰 기능

주목해야 할 기술

주제항목설명
AI 자동화GitHub Copilot X전체 개발 주기 AI 지원
AI 머지 충돌 해결자동 충돌 해결 제안
보안Supply Chain 보안종속성 보안 강화
제로 트러스트 접근모든 커밋 검증 강화
성능 최적화모노레포 지원대규모 프로젝트 성능 개선
분산 CI/CD글로벌 빌드 최적화

앞으로의 전망

주제항목설명
브랜치 전략단순화 추세복잡한 브랜치 전략보다 단순한 전략이 선호되는 경향이 있습니다.
자동화CI/CD 강화자동화된 테스트와 배포가 더욱 중요해지고 있습니다.
AI 중심 워크플로우완전 자동화 PRAI가 PR 생성부터 병합까지 제안
예측적 코드 리뷰잠재적 문제 사전 탐지
DevSecOps 통합보안 우선 개발모든 단계에 보안 검증 통합
자동 컴플라이언스규제 준수 자동화
분산 협업비동기 워크플로우시간대 차이 극복 도구
VR/AR 코드 리뷰실감형 협업 도구 등장

하위 주제로 분류한 추가 학습 내용

카테고리주제간략한 설명
브랜치 전략브랜치 네이밍 컨벤션feature/, bugfix/, hotfix/ 등 명명 규칙
브랜치 보호 규칙main 브랜치 직접 푸시 방지 설정
PR 관리PR 템플릿 작성표준화된 PR 설명 양식 만들기
리뷰 가이드라인효과적인 코드 리뷰 방법론
자동화GitHub Actions 심화워크플로우 자동화 구성 방법
병합 자동화자동 병합 조건 설정
품질 관리테스트 전략PR 단위 테스트 구성
정적 분석 도구SonarQube, ESLint 통합

관련 분야 추가 학습 내용

관련 분야주제간략한 설명
Git 심화Git 내부 동작 원리객체 모델, 참조 관리 등
고급 Git 명령어rebase, cherry-pick, bisect 등
CI/CDJenkins Pipeline파이프라인 스크립트 작성
GitHub Actions 고급복잡한 워크플로우 구성
DevOps컨테이너화Docker, Kubernetes 통합
인프라 자동화Terraform, Ansible 활용
프로젝트 관리애자일 방법론스크럼, 칸반과 GitHub Flow 통합
이슈 트래킹Jira, GitHub Issues 활용

용어 정리

용어설명
메인 브랜치 (main)항상 배포 가능한 상태를 유지하는 브랜치로, GitHub Flow의 중심입니다.
기능 브랜치 (feature branch)새로운 기능이나 버그 수정을 위한 임시 브랜치로, 작업 완료 후 main 브랜치에 병합됩니다.
Pull Request (PR)코드 변경 사항을 main 브랜치에 병합하기 위해 요청하는 작업으로, 코드 리뷰 및 CI 프로세스가 수행됩니다.
CI/CDContinuous Integration / Continuous Deployment. 코드 변경 시 자동으로 빌드, 테스트, 배포를 수행하는 DevOps 핵심 자동화 기법입니다.
GitHub ActionsGitHub에서 제공하는 CI/CD 워크플로우 자동화 도구로, PR 생성, 푸시 등을 트리거로 자동 테스트 및 배포 수행이 가능합니다.
CodespacesGitHub에서 제공하는 브라우저 기반 개발 환경으로, 별도 설정 없이 클라우드에서 코딩과 디버깅이 가능한 기능입니다.
브랜치 전략 (Branch Strategy)Git에서 브랜치를 어떻게 생성하고 병합할 것인지에 대한 규칙과 흐름을 정의한 방법론입니다.
코드 리뷰 (Code Review)PR 요청 시 다른 개발자가 코드를 검토하고 피드백을 제공하여 품질을 확보하는 협업 절차입니다.
자동 배포 (Auto Deployment)main 브랜치에 병합되면 자동으로 애플리케이션이 테스트 및 프로덕션 환경에 배포되는 과정입니다.
스테이징 환경 (Staging Environment)실제 배포 전 테스트를 위한 미러 환경. GitHub Flow에서는 별도의 스테이징 브랜치 없이 자동화로 테스트 환경을 운영하는 경우가 많습니다.
Squash Merge여러 커밋을 하나로 합쳐서 병합하는 방식
Code Review다른 개발자가 코드 변경사항을 검토하는 프로세스
Branch Protection브랜치에 대한 직접 푸시를 방지하고 PR을 통한 병합만 허용하는 설정
Continuous Deployment코드 변경사항이 자동으로 프로덕션에 배포되는 프로세스

참고 및 출처