Question 1

Git Flow와 GitHub Flow의 차이점은?

Accepted Answer

두 가지 대표적인 Git 브랜치 전략입니다.

**Git Flow:**
```
main ───────────────── 배포
develop ──────────── 개발 통합
  feature/xxx ──── 기능 개발
  release/1.0 ──── 릴리스 준비
  hotfix/xxx ───── 긴급 수정
```

**GitHub Flow:**
```
main ───────────────── 항상 배포 가능
  feature/xxx ──── 기능 개발 → PR → 코드리뷰 → main 머지
```

- **Git Flow**: 릴리스 주기가 있는 프로젝트에 적합 (모바일 앱 등)
- **GitHub Flow**: CI/CD 기반의 지속적 배포에 적합 (웹 서비스)
- 대부분의 웹 프로젝트에서는 GitHub Flow가 더 적합합니다.
- Trunk-Based Development도 최근 많이 사용되는 전략입니다.

Question 2

git reset, git revert, git stash의 차이점은?

Accepted Answer

각각 다른 상황에서 변경 사항을 관리하는 데 사용됩니다.

```bash
# reset: 커밋을 되돌림 (히스토리 변경)
git reset --soft HEAD~1   # 커밋만 취소 (변경사항 staged)
git reset --mixed HEAD~1  # 커밋+staging 취소 (변경사항 unstaged)
git reset --hard HEAD~1   # 모든 변경사항 삭제 (주의!)

# revert: 새 커밋으로 이전 커밋을 되돌림 (히스토리 유지)
git revert abc1234        # abc1234의 변경을 취소하는 새 커밋

# stash: 임시로 변경사항을 저장
git stash                 # 현재 변경사항 임시 저장
git stash pop             # 저장한 변경사항 복원
git stash list            # 저장 목록 확인
```

- **reset**: 로컬에서 실수를 수정할 때 (push 전)
- **re

Question 3

git cherry-pick의 용도와 사용법은?

Accepted Answer

**git cherry-pick**은 다른 브랜치의 특정 커밋을 현재 브랜치에 복사(적용)하는 명령입니다. **기본 사용법:** ```bash # 특정 커밋 하나 적용 git cherry-pick # 여러 커밋 적용 git cherry-pick # 범위 적용 (A 이후 ~ B까지) git cherry-pick A..B ``` **유용한 옵션:** ```bash # 커밋하지 않고 변경사항만 스테이징 git cherry-pick --no-commit # 충돌 발생 시 git cherry-pick --continue # 충돌 해결 후 계속 git cherry-pick --abort # cherry-pick 취소 ``` **활용 시나리오:** 1. **핫픽스 백포트**: main의 버그 수정 커밋을 release 브랜치에 적용 2. **특정 기능만 가져오기**: feature 브랜치에서 일부

Question 4

Monorepo 관리 전략과 도구를 비교해주세요.

Accepted Answer

Monorepo는 여러 프로젝트를 하나의 저장소에서 관리하는 전략입니다.

**장점:**
- 코드 공유 용이 (공통 컴포넌트, 유틸)
- 일관된 도구/설정 관리
- 원자적 변경 (여러 패키지 동시 수정 후 단일 커밋)
- 의존성 버전 통일

**단점:**
- 저장소 크기 증가
- CI/CD 복잡성 (변경된 패키지만 빌드/테스트 필요)
- 접근 권한 관리 어려움

**도구 비교:**
| 도구 | 특징 | 장점 |
|------|------|------|
| **Turborepo** | 캐싱 기반 빌드 | 빠름, 설정 간단, Vercel 통합 |
| **Nx** | 풀 기능 빌드 시스템 | 의존성 그래프, 생성기 |
| **pnpm workspace** | 패키지 매니저 내장 | 디스크 효율, 빠른 설치 |
| **Lerna** | 레거시 (Nx에 통합) | 버전 관리, 배포 |

**pnpm workspace 기본 설정:**
```yaml
# pnpm-workspace.yaml
pac

Question 5

Git Hooks와 Husky를 이용한 코드 품질 관리 방법은?

Accepted Answer

**Git Hooks**는 Git 이벤트(commit, push 등) 발생 시 자동으로 실행되는 스크립트입니다.

**주요 Hook 종류:**
| Hook | 시점 | 용도 |
|---|---|---|
| `pre-commit` | 커밋 전 | 린트, 포맷팅 검사 |
| `commit-msg` | 커밋 메시지 작성 후 | 커밋 메시지 규칙 검증 |
| `pre-push` | 푸시 전 | 테스트 실행 |

**Husky 설정 (v9):**
```bash
npm install -D husky
npx husky init
```

**lint-staged — 스테이징된 파일만 검사:**
```bash
npm install -D lint-staged
```
```json
// package.json
{
  "lint-staged": {
    "*.{ts,tsx}": ["eslint --fix", "prettier --write"],
    "*.css": ["prettier --write"

Question 6

git bisect를 이용한 버그 원인 커밋 탐색 방법은?

Accepted Answer

git bisect는 **이진 탐색**으로 버그를 도입한 커밋을 빠르게 찾아냅니다.

**사용법:**
```bash
# 1. bisect 시작
git bisect start

# 2. 현재(버그 있음)를 bad로 표시
git bisect bad

# 3. 버그 없던 커밋을 good으로 표시
git bisect good abc123

# 4. Git이 중간 커밋을 체크아웃 → 테스트 후 good/bad 판정
git bisect good  # 또는 git bisect bad

# 5. 반복하면 원인 커밋 특정
# "abc456 is the first bad commit"

# 6. 종료
git bisect reset
```

**자동화:**
```bash
# 테스트 스크립트로 자동 판별
git bisect start HEAD abc123
git bisect run npm test
# 테스트 성공(exit 0) → good, 실패(exit 1) → bad
```

**활용 시나리오:**

Git

01Git Flow와 GitHub Flow의 차이점은?보통워크플로우

02git reset, git revert, git stash의 차이점은?보통명령어

03git cherry-pick의 용도와 사용법은?보통명령어

04Monorepo 관리 전략과 도구를 비교해주세요.보통전략

05Git Hooks와 Husky를 이용한 코드 품질 관리 방법은?보통도구

06git bisect를 이용한 버그 원인 커밋 탐색 방법은?보통명령어