실전 Git 및 GitHub 설정: 실제 프로젝트를 위한

Source: Dev.to

왜 이 설정이 작동하는가

• 초보자에게 쉬움
• 팀 규모에 맞게 확장 가능
• 최소 규칙, 최대 명료성
• 실제 프로덕션 프로젝트에서 사용됨

브랜칭 전략 (단순하지만 강력함)

main        → production‑ready code
develop     → active development
feature/*   → new features
bugfix/*   → bug fixes
hotfix/*   → urgent production fixes

예시

feature/user-login
bugfix/cart-total
hotfix/payment-crash

왜 복잡한 GitFlow를 사용하지 않을까?

• 관리해야 할 브랜치가 적음
• 빠른 온보딩
• 혼란 감소

커밋 메시지 규칙

경량화된 관례 형식을 사용:

type(scope): 짧은 설명

일반적인 타입

• feat – 새로운 기능
• fix – 버그 수정
• refactor – 내부 개선
• docs – 문서
• test – 테스트
• chore – 도구 / 설정

예시

feat(auth): OTP 로그인 추가
fix(cart): 총 가격 수정
refactor(api): 직렬 변환기 간소화

GitHub 라벨 (최소 및 유용)

유형

• type: bug
• type: feature
• type: enhancement
• type: refactor

우선순위

• priority: high
• priority: medium
• priority: low

상태

• status: ready
• status: in-progress
• status: blocked
• status: needs-review

심각도 (버그용)

• severity: critical
• severity: major
• severity: minor

이슈 템플릿

버그 보고

설명

재현 단계

예상 동작

실제 동작

환경

### 기능 요청

```markdown

문제

제안된 해결책

대안

추가 컨텍스트

풀 리퀘스트 템플릿

이 PR은 무엇을 하나요?

관련 이슈

닫음 #123

변경 사항

테스트 방법

체크리스트

• 코드가 표준을 따름
• 테스트 추가/업데이트됨
• 파괴적인 변경 없음

코드 리뷰 및 브랜치 보호

규칙

• main에 직접 푸시 금지
• 풀 리퀘스트 필요
• 최소 1개의 승인 필요
• 상태 검사가 통과해야 함

이 규칙들은 개발 속도를 늦추지 않으면서 품질을 보장합니다.

GitHub Actions를 사용한 자동화

기본 CI 워크플로

Create .github/workflows/ci.yml:

name: CI

on:
  pull_request:
  push:
    branches: [main, develop]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 18

      - name: Install dependencies
        run: npm install

      - name: Run tests
        run: npm test

이것이 제공하는 것

• 테스트가 실패하면 PR이 자동으로 실패합니다
• 사람이 테스트 실행을 기억할 필요가 없습니다
• 더 깔끔한 main 브랜치

Solo Developer vs Team Setup

Solo Developer (Recommended)

• Branches: main, feature/*
• Labels: type + priority
• PRs: optional but recommended
• CI: yes (non‑negotiable)

Why? Even solo devs forget context. This keeps history clean.

Small Team (2–5 Developers)

• Full branching strategy
• Mandatory PRs
• Labels for status & severity
• CI required before merge

Result: Less confusion, fewer bugs, faster reviews.

Larger Teams

• Add CODEOWNERS
• Require 2 approvals
• Add lint + security checks
• Auto‑release notes

README 구조

# Project Name

## Description
A brief description of what the project does and who it's for.

## Table of Contents
- [Installation](#installation)
- [Usage](#usage)
- [Contributing](#contributing)
- [License](#license)

## Installation
Instructions on how to install the project.

## Usage
Examples of how to use the project.

## Contributing
Guidelines for contributing to the project.

## License
The license under which the project is released.

설명

기술 스택

설정

스크립트

기여

라이선스

피해야 할 일반적인 실수

• 레이블이 너무 많음
• main에 직접 커밋
• 불명확한 커밋 메시지
• 자동화 없음
• PR 템플릿 없음

Final Thoughts

A good Git & GitHub setup should disappear into the background and let you focus on building.

This setup is:

• Easy
• Scalable
• Production‑proven