🤝 GitHub 협업하기

📖 정의

GitHub 협업은 여러 개발자가 Git과 GitHub를 사용하여 동일한 프로젝트에서 효율적으로 함께 작업하는 방법입니다. **브랜치(Branch)**로 독립적인 작업 공간을 만들고, **Pull Request(PR)**로 코드 리뷰를 받으며, **이슈(Issue)**로 작업을 추적합니다. 충돌(Conflict)을 해결하고, 코드 품질을 유지하며, 팀과 원활하게 소통하는 것이 핵심입니다.

🎯 비유로 이해하기

공동 문서 작성

GitHub 협업을 Google Docs 공동 작업에 비유하면:

메인 브랜치 (main) = 최종 출판본
├─ 안정적이고 검증된 내용
└─ 항상 작동하는 상태 유지

기능 브랜치 (feature) = 개인 초안
├─ 각자 자유롭게 작성
├─ 실험과 수정 가능
└─ 완성되면 제출

Pull Request = 편집 회의
├─ "이 부분 추가할게요"
├─ 동료들이 검토
├─ 피드백 반영
└─ 승인 후 최종본에 병합

이슈(Issue) = 할일 목록
├─ "3장 작성하기"
├─ "오타 수정"
└─ "참고 자료 추가"

레스토랑 주방

메인 브랜치 = 손님께 나가는 요리
├─ 완벽하게 완성된 상태
└─ 셰프의 최종 승인 필요

개발자 = 조리사
├─ 각자 담당 요리 준비
└─ 독립적인 작업대(브랜치) 사용

Pull Request = 맛보기
├─ 셰프가 맛 확인
├─ 다른 조리사 의견
└─ 최종 승인 후 서빙

코드 충돌 = 재료 겹침
├─ "둘 다 토마토 사용 중"
├─ 조율 필요
└─ 우선순위 결정

⚙️ 작동 원리

1. GitHub 협업 워크플로우

1. Issue 생성
   └─ 작업 내용 정의

2. 브랜치 생성
   └─ main에서 분기

3. 코드 작성
   └─ 로컬에서 개발

4. 커밋 및 푸시
   └─ 원격 브랜치에 업로드

5. Pull Request 생성
   └─ 코드 리뷰 요청

6. 코드 리뷰
   ├─ 팀원들이 검토
   ├─ 코멘트 및 피드백
   └─ 수정 요청

7. 피드백 반영
   └─ 추가 커밋

8. 승인 및 병합
   └─ main에 병합

9. 브랜치 삭제
   └─ 정리

10. 최신 코드 동기화
    └─ git pull

2. 브랜치 전략 (Git Flow)

main (또는 master)
├─ 프로덕션 배포용
├─ 항상 안정적
└─ 직접 커밋 금지

develop
├─ 개발용 메인 브랜치
├─ 다음 릴리스 준비
└─ feature 브랜치의 병합 대상

feature/* (기능 개발)
├─ feature/login
├─ feature/payment
└─ 개발 완료 후 develop에 병합

hotfix/* (긴급 수정)
├─ hotfix/security-patch
├─ main에서 분기
└─ main과 develop에 모두 병합

release/* (릴리스 준비)
├─ release/v1.0.0
├─ develop에서 분기
└─ 테스트 후 main에 병합

3. Pull Request 프로세스

개발자 A                 팀원들                  Reviewer
    |                       |                        |
    | 1. PR 생성            |                        |
    |--------------------->|                        |
    |                       | 2. 알림 받음           |
    |                       |---------------------->|
    |                       |                        | 3. 코드 리뷰
    |                       |                        |    (읽고 분석)
    |                       |                        |
    |                       | 4. 코멘트/수정 요청    |
    |<----------------------------------------------|
    | 5. 피드백 반영        |                        |
    | 6. 추가 커밋          |                        |
    |--------------------->|                        |
    |                       |                        | 7. 재검토
    |                       |                        |
    |                       | 8. 승인 (Approve)      |
    |<----------------------------------------------|
    | 9. Merge              |                        |
    |--------------------->|                        |
    |                       | 10. 브랜치 삭제        |
    |--------------------->|                        |

💡 실제 예시

준비: 팀 프로젝트 시작

# 시나리오: 3명이 웹사이트를 함께 개발

# === 프로젝트 오너 (리더) ===

# 1. GitHub에서 새 저장소 생성
# - Repository name: team-project
# - Public
# - Add README
# - Add .gitignore (Node)
# - Choose license (MIT)

# 2. 로컬에 클론
git clone https://github.com/owner/team-project.git
cd team-project

# 3. 프로젝트 구조 생성
mkdir src tests docs
touch src/index.js src/app.js
touch README.md .gitignore

# 4. 초기 코드 작성
cat > src/index.js << 'EOF'
// Team Project
console.log('Hello, Team!');
EOF

# 5. 첫 커밋
git add .
git commit -m "Initial project setup"
git push origin main

# 6. 팀원 초대
# GitHub 웹사이트:
# Settings → Collaborators → Add people
# - developer1@email.com
# - developer2@email.com
# 초대 이메일 발송됨

Step 1: 팀원들 합류

# === 팀원 A (Developer 1) ===

# 1. 초대 수락
# 이메일에서 링크 클릭하여 수락

# 2. 저장소 클론
git clone https://github.com/owner/team-project.git
cd team-project

# 3. Git 설정 확인
git config user.name "Developer 1"
git config user.email "developer1@email.com"

# 4. 원격 저장소 확인
git remote -v
# origin  https://github.com/owner/team-project.git (fetch)
# origin  https://github.com/owner/team-project.git (push)

# 5. 브랜치 확인
git branch -a
# * main
#   remotes/origin/main

# === 팀원 B (Developer 2) ===
# 동일한 과정 반복

Step 2: Issue로 작업 관리

# GitHub 웹사이트에서 Issue 생성

# === 프로젝트 오너 ===

# Issues 탭 → New issue

# Issue #1
Title: 사용자 로그인 기능 구현
Description:
사용자 로그인 기능을 구현합니다.

**요구사항:**
- [ ] 로그인 폼 UI
- [ ] 인증 로직
- [ ] 세션 관리

**기술스택:**
- React
- JWT

**담당자:** @developer1
**라벨:** enhancement, high priority
**마일스톤:** v1.0

# Issue #2
Title: 상품 목록 페이지 개발
Assignees: @developer2
Labels: feature, frontend

# Issue #3
Title: 데이터베이스 스키마 설계
Assignees: @owner
Labels: backend, database

# 팀원들에게 자동으로 알림 전송!

Step 3: 브랜치에서 작업하기

# === Developer 1: 로그인 기능 개발 ===

# 1. 최신 코드 받기
git checkout main
git pull origin main

# 2. 새 브랜치 생성 (Issue 번호 포함)
git checkout -b feature/login-1

# 브랜치 네이밍 규칙:
# - feature/기능명-이슈번호
# - bugfix/버그명-이슈번호
# - hotfix/긴급수정명
# 예: feature/login-1, bugfix/header-css-5

# 3. 코드 작성

src/Login.js 파일 생성:

```javascript
import React, { useState } from 'react';

function Login() {
  const [email, setEmail] = useState('');
  const [password, setPassword] = useState('');

  const handleSubmit = async (e) => {
    e.preventDefault();

    try {
      const response = await fetch('/api/login', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify(\{ email, password \})
      });

      if (response.ok) {
        const data = await response.json();
        localStorage.setItem('token', data.token);
        alert('로그인 성공!');
      } else {
        alert('로그인 실패');
      }
    } catch (error) {
      console.error('Error:', error);
    }
  };

  return (
    <form onSubmit=\{handleSubmit\}>
      <h2>로그인</h2>
      <input
        type="email"
        placeholder="이메일"
        value=\{email\}
        onChange=\{(e) => setEmail(e.target.value)\}
        required
      />
      <input
        type="password"
        placeholder="비밀번호"
        value=\{password\}
        onChange=\{(e) => setPassword(e.target.value)\}
        required
      />
      <button type="submit">로그인</button>
    </form>
  );
}

export default Login;

4. 테스트 작성

tests/Login.test.js 파일 생성:

import { render, screen, fireEvent } from '@testing-library/react';
import Login from '../src/Login';

test('로그인 폼 렌더링', () => {
  render(<Login />);
  expect(screen.getByPlaceholderText('이메일')).toBeInTheDocument();
  expect(screen.getByPlaceholderText('비밀번호')).toBeInTheDocument();
  expect(screen.getByText('로그인')).toBeInTheDocument();
});

5. 로컬에서 테스트

npm test

6. 작은 단위로 자주 커밋 (권장!)

git add src/Login.js git commit -m "feat: 로그인 컴포넌트 UI 구현

이메일, 비밀번호 입력 폼 추가
useState로 상태 관리

Related to #1"

7. 인증 로직 추가

... 코드 작성 ...

git add src/Login.js git commit -m "feat: 로그인 인증 API 연동

fetch로 POST 요청
JWT 토큰 localStorage 저장
에러 처리 추가

Related to #1"

8. 테스트 추가

git add tests/Login.test.js git commit -m "test: 로그인 컴포넌트 테스트 작성

Related to #1"

9. 원격에 푸시

git push origin feature/login-1

💡 팁: 커밋 메시지 규칙

feat: 새 기능

fix: 버그 수정

docs: 문서 변경

style: 코드 포매팅

refactor: 리팩토링

test: 테스트 추가

chore: 빌드, 설정 변경

### Step 4: Pull Request 생성

```bash
# === Developer 1 ===

# 1. GitHub 웹사이트에서 PR 생성
# - "Compare & pull request" 버튼 클릭 (자동으로 나타남)
# - 또는 Pull requests 탭 → New pull request

# 2. PR 정보 작성 (중요!)

Title: feat: 사용자 로그인 기능 구현

Description:
## 📝 변경사항
사용자 로그인 기능을 구현했습니다.

## ✨ 구현 내역
- [x] 로그인 폼 UI 구현
- [x] 이메일/비밀번호 입력 및 유효성 검사
- [x] API 연동 (POST /api/login)
- [x] JWT 토큰 저장
- [x] 에러 처리
- [x] 단위 테스트 작성

## 🧪 테스트
```bash
npm test

모든 테스트 통과 확인

📸 스크린샷

[로그인 화면 스크린샷 첨부]

🔗 관련 이슈

Closes #1

📋 체크리스트

💬 리뷰어에게

인증 로직의 보안성을 중점적으로 검토해주세요.

Reviewers: @owner, @developer2 Assignees: @developer1 Labels: feature, frontend Milestone: v1.0

3. Create pull request 클릭

🎉 PR 생성 완료!

- 팀원들에게 자동 알림

- GitHub Actions CI가 자동 실행 (설정된 경우)

- 코드 리뷰 시작!

### Step 5: 코드 리뷰

```bash
# === Reviewer (Owner) ===

# GitHub 웹사이트에서 PR 확인

# 1. Files changed 탭 클릭
# - 변경된 코드 확인
# - +9 -2 (9줄 추가, 2줄 삭제)

# 2. 코드에 코멘트 달기
# 특정 라인 클릭 → "+" 버튼

# 코멘트 예시:

Line 15: const handleSubmit = async (e) => {
💬 Comment:
보안을 위해 비밀번호를 평문으로 전송하는 대신
HTTPS를 사용하거나, 비밀번호 해싱을 고려해보세요.

🔍 Suggestion:

// 최소 길이 검증 추가
if (password.length < 8) {
  alert('비밀번호는 최소 8자 이상이어야 합니다.');
  return;
}

Line 25: localStorage.setItem('token', data.token);
💬 Comment:
Good! JWT 토큰 저장 방식이 적절합니다.
하지만 XSS 공격 대비를 위해 httpOnly 쿠키 사용도 고려해보세요.

Line 35: } catch (error) {
💬 Comment:
에러 처리가 잘 되어있네요! 👍
사용자에게 더 구체적인 에러 메시지를 보여주면 어떨까요?

# 3. 전체 리뷰 작성
Review changes → Comment/Approve/Request changes

💬 전체 코멘트:
전반적으로 깔끔한 코드입니다! 👏

**좋은 점:**
- useState를 활용한 상태 관리
- try-catch로 에러 처리
- 깔끔한 컴포넌트 구조

**개선 제안:**
1. 비밀번호 최소 길이 검증 추가
2. 에러 메시지 더 구체적으로
3. 로딩 상태 추가 (버튼 중복 클릭 방지)

**보안 관련:**
- HTTPS 사용 확인 필요
- 토큰 만료 시간 처리
- XSS 방어 고려

몇 가지 수정 후 승인하겠습니다.

Submit review: Request changes

Step 6: 피드백 반영

# === Developer 1 ===

# 1. 피드백 확인
# GitHub에서 알림 확인 → PR 페이지로 이동

# 2. 피드백 반영하여 코드 수정
# 동일한 브랜치에서 작업 계속

src/Login.js 파일을 다음과 같이 수정합니다:

```javascript
import React, { useState } from 'react';

function Login() {
  const [email, setEmail] = useState('');
  const [password, setPassword] = useState('');
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState('');

  const handleSubmit = async (e) => {
    e.preventDefault();
    setError('');

    if (password.length < 8) {
      setError('비밀번호는 최소 8자 이상이어야 합니다.');
      return;
    }

    setLoading(true);

    try {
      const response = await fetch('/api/login', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify(\{ email, password \})
      });

      if (response.ok) {
        const data = await response.json();
        localStorage.setItem('token', data.token);
        alert('로그인 성공!');
      } else {
        const errorData = await response.json();
        setError(errorData.message || '로그인에 실패했습니다.');
      }
    } catch (error) {
      console.error('Error:', error);
      setError('네트워크 오류가 발생했습니다. 다시 시도해주세요.');
    } finally {
      setLoading(false);
    }
  };

  return (
    <form onSubmit=\{handleSubmit\}>
      <h2>로그인</h2>
      \{error && <div style=\{\{ color: 'red' \}\}>\{error\}</div>\}
      <input
        type="email"
        placeholder="이메일"
        value=\{email\}
        onChange=\{(e) => setEmail(e.target.value)\}
        required
      />
      <input
        type="password"
        placeholder="비밀번호"
        value=\{password\}
        onChange=\{(e) => setPassword(e.target.value)\}
        required
      />
      <button type="submit" disabled=\{loading\}>
        \{loading ? '로그인 중...' : '로그인'\}
      </button>
    </form>
  );
}

export default Login;

3. 커밋 및 푸시

git add src/Login.js
git commit -m "fix: 코드 리뷰 피드백 반영

- 비밀번호 최소 길이 검증 추가
- 로딩 상태 관리 (중복 클릭 방지)
- 구체적인 에러 메시지 표시
- 에러 UI 개선

Related to #1"

git push origin feature/login-1

# 4. PR에 코멘트 추가
# GitHub PR 페이지에서:

💬 Comment:
@owner 피드백 반영 완료했습니다!

**변경사항:**
✅ 비밀번호 최소 8자 검증 추가
✅ 로딩 상태로 중복 클릭 방지
✅ 에러 메시지 구체화
✅ 에러 UI 개선

다시 검토 부탁드립니다. 🙏

# PR이 자동으로 업데이트됨!
# 새 커밋이 PR에 추가되어 표시됨

Step 7: 재검토 및 승인

# === Reviewer (Owner) ===

# 1. 변경사항 재검토
# Files changed → View changes

# 2. 승인
Review changes → Approve

💬 Comment:
완벽합니다! 🎉
모든 피드백이 잘 반영되었습니다.

**확인 사항:**
✅ 비밀번호 검증
✅ 로딩 상태 처리
✅ 에러 처리 개선
✅ 사용자 경험 향상

Approve!

Submit review: Approve

# 3. PR 승인 완료
# ✅ 1 approval (최소 요구사항 충족)

Step 8: Pull Request 병합

# === Developer 1 또는 Owner ===

# GitHub PR 페이지에서

# 1. 병합 방법 선택

# 옵션 A: Merge commit (기본)
# - 브랜치의 모든 커밋 유지
# - 병합 커밋 생성
"Merge pull request #5 from owner/feature/login-1"

# 옵션 B: Squash and merge (권장)
# - 모든 커밋을 하나로 합침
# - 깔끔한 히스토리
"feat: 사용자 로그인 기능 구현 (#5)"

# 옵션 C: Rebase and merge
# - 선형 히스토리
# - 개별 커밋 유지

# 2. Merge 버튼 클릭
Squash and merge → Confirm squash and merge

# 3. 브랜치 삭제
Delete branch 버튼 클릭

# 🎉 병합 완료!
# - main 브랜치에 코드 반영
# - Issue #1 자동으로 Closed
# - feature/login-1 브랜치 삭제

# 4. 로컬에서 정리
git checkout main
git pull origin main
git branch -d feature/login-1  # 로컬 브랜치 삭제

# 5. 원격 브랜치 정리
git remote prune origin

Step 9: 동시 작업 및 충돌 해결

# === 상황: Developer 1과 Developer 2가 같은 파일 수정 ===

# === Developer 1: 헤더 스타일 수정 ===
git checkout -b feature/header-style
# src/Header.css 수정
git commit -m "style: 헤더 배경색 변경"
git push origin feature/header-style
# PR #6 생성 및 승인 → Merge

# === Developer 2: 헤더에 로고 추가 (동시 작업) ===
git checkout -b feature/header-logo
# src/Header.css 수정 (같은 부분!)
git commit -m "feat: 헤더에 로고 추가"
git push origin feature/header-logo
# PR #7 생성

# ⚠️ GitHub에서 충돌 경고
# "This branch has conflicts that must be resolved"

# === Developer 2: 충돌 해결 ===

# 1. main의 최신 코드 받기
git checkout main
git pull origin main

# 2. 작업 브랜치로 돌아가기
git checkout feature/header-logo

# 3. main을 현재 브랜치에 병합
git merge main

# 자동 병합 실패!
# Auto-merging src/Header.css
# CONFLICT (content): Merge conflict in src/Header.css
# Automatic merge failed; fix conflicts and then commit the result.

# 4. 충돌 파일 확인
git status
# Both modified: src/Header.css

# 5. 충돌 해결
cat src/Header.css

# 충돌 표시:
<<<<<<< HEAD (현재 브랜치: feature/header-logo)
.header {
  background: white;
  height: 80px;
  display: flex;
  align-items: center;
  padding: 0 20px;
}

.logo {
  width: 150px;
  height: 50px;
}
=======
.header {
  background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
  height: 80px;
  display: flex;
  align-items: center;
  padding: 0 20px;
}
>>>>>>> main (메인 브랜치)

# 6. 수동으로 수정 (두 변경사항 모두 반영)
cat > src/Header.css << 'EOF'
.header {
  background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
  height: 80px;
  display: flex;
  align-items: center;
  padding: 0 20px;
}

.logo {
  width: 150px;
  height: 50px;
}
EOF

# 7. 충돌 해결 완료
git add src/Header.css
git commit -m "merge: main 브랜치 병합 및 충돌 해결

- Developer 1의 배경색 변경 반영
- 로고 스타일 유지"

# 8. 푸시
git push origin feature/header-logo

# 9. PR 업데이트 및 병합
# GitHub에서 충돌 해결 확인 → Merge 가능!

Step 10: 고급 협업 - Code Review Best Practices

# === 효과적인 코드 리뷰 ===

# 1. PR 크기 관리
# ✅ 좋은 PR
- 300줄 이하
- 단일 기능/버그 수정
- 리뷰 시간 30분 이내

# ❌ 나쁜 PR
- 1000줄 이상
- 여러 기능 혼재
- 리뷰 불가능

# 2. PR 템플릿 설정
# .github/pull_request_template.md

cat > .github/pull_request_template.md << 'EOF'
## 📝 변경사항
<!-- 무엇을 변경했나요? -->

## 🎯 변경 이유
<!-- 왜 이 변경이 필요한가요? -->

## 🧪 테스트
<!-- 어떻게 테스트했나요? -->

## 📸 스크린샷 (UI 변경 시)
<!-- 스크린샷을 첨부해주세요 -->

## 🔗 관련 이슈
Closes #

## ✅ 체크리스트
- [ ] 코드가 정상 작동합니다
- [ ] 테스트를 작성했습니다
- [ ] 문서를 업데이트했습니다
- [ ] 린터/포매터를 실행했습니다
- [ ] 관련 이슈를 링크했습니다

## 💭 리뷰어에게
<!-- 특별히 검토가 필요한 부분이 있나요? -->
EOF

# 3. 리뷰 코멘트 작성 팁

# ✅ 좋은 코멘트
"이 함수는 명확하네요! 다만 에러 처리를 추가하면 더 견고할 것 같습니다."
"좋은 아이디어입니다! 성능을 위해 useMemo를 고려해보세요."
"질문: 이 로직이 빈 배열일 때 어떻게 동작하나요?"

# ❌ 나쁜 코멘트
"이거 이상한데요." (구체적이지 않음)
"다시 하세요." (건설적이지 않음)
"왜 이렇게 했어요?" (비판적)

# 4. 리뷰 태그 활용
# [Q] 질문
# [NIT] 사소한 제안 (Nitpick)
# [BLOCKER] 반드시 수정 필요
# [SUGGESTION] 제안
# [PRAISE] 칭찬

예시:
[Q] 이 함수가 null을 반환할 수 있나요?
[NIT] 변수명을 더 명확하게 하면 어떨까요?
[BLOCKER] 보안 취약점: SQL Injection 가능
[SUGGESTION] 이 부분은 헬퍼 함수로 분리하면 좋을 것 같아요.
[PRAISE] 에러 처리가 완벽합니다! 👍

# 5. GitHub 리뷰 기능 활용

# Suggested changes (제안 변경)
```suggestion
// 이렇게 수정하면 어떨까요?
const result = items.filter(item => item.active);

코드 블록으로 설명

// 현재 코드의 문제점:
if (user) {
  // user가 undefined일 수 있음
}

// 개선안:
if (user && user.isActive) {
  // 안전한 접근
}

### Step 11: GitHub Actions로 자동화

```yaml
# .github/workflows/ci.yml
# PR 생성 시 자동으로 테스트 실행

name: CI

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

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout code
      uses: actions/checkout@v3

    - name: Setup Node.js
      uses: actions/setup-node@v3
      with:
        node-version: '18'

    - name: Install dependencies
      run: npm ci

    - name: Run linter
      run: npm run lint

    - name: Run tests
      run: npm test

    - name: Build
      run: npm run build

    - name: Comment PR
      if: github.event_name == 'pull_request'
      uses: actions/github-script@v6
      with:
        script: |
          github.rest.issues.createComment({
            issue_number: context.issue.number,
            owner: context.repo.owner,
            repo: context.repo.repo,
            body: '✅ All tests passed! Ready for review.'
          })

# PR 생성 시 자동으로:
# 1. 코드 체크아웃
# 2. 의존성 설치
# 3. 린터 실행
# 4. 테스트 실행
# 5. 빌드 테스트
# 6. 결과를 PR에 코멘트

# ✅ 모든 체크 통과 시 병합 가능
# ❌ 실패 시 병합 차단

Step 12: 프로젝트 관리 - GitHub Projects

# GitHub 웹사이트에서 Projects 탭

# 1. New project 생성
Name: Website Development
Template: Board (칸반 보드)

# 2. 컬럼 설정
- 📋 Backlog (할일)
- 🚧 In Progress (진행중)
- 👀 In Review (리뷰중)
- ✅ Done (완료)

# 3. Issue를 카드로 추가
- Backlog에 Issue #1, #2, #3 추가
- 작업 시작하면 In Progress로 이동
- PR 생성하면 In Review로 자동 이동
- Merge되면 Done으로 자동 이동

# 4. 마일스톤 설정
Milestones → New milestone
Title: v1.0 Release
Due date: 2024-02-01
Description: 첫 번째 릴리스

# Issue들을 마일스톤에 할당
# 진행률 자동 계산 (3/10 completed)

# 5. 라벨 활용
Labels → New label
- bug (빨강)
- enhancement (파랑)
- documentation (초록)
- high priority (주황)
- good first issue (보라)

# Issue에 라벨 추가하여 분류

🤔 자주 묻는 질문

Q1. 브랜치 네이밍 규칙은?

# 일반적인 브랜치 네이밍 규칙

# 1. 기능 개발
feature/기능명
feature/login
feature/payment-integration
feature/user-profile-123  # 이슈 번호 포함

# 2. 버그 수정
bugfix/버그명
bugfix/header-layout
bugfix/memory-leak-456

# 3. 긴급 수정 (프로덕션)
hotfix/보안패치
hotfix/security-patch
hotfix/payment-error

# 4. 릴리스
release/v1.0.0
release/v2.1.0

# 5. 문서
docs/readme-update
docs/api-documentation

# 6. 리팩토링
refactor/코드정리
refactor/component-structure

# 규칙:
✅ 소문자 사용
✅ 하이픈(-)으로 단어 구분
✅ 간결하고 명확하게
✅ 이슈 번호 포함 (선택)
❌ 띄어쓰기 사용 금지
❌ 특수문자 사용 최소화

# 예시:
git checkout -b feature/user-authentication-42
git checkout -b bugfix/fix-css-overflow-78
git checkout -b hotfix/critical-security-patch

Q2. 커밋을 잘못했을 때 어떻게 하나요?

# 상황별 해결 방법

# 1. 마지막 커밋 메시지 수정
git commit --amend -m "올바른 커밋 메시지"

# 2. 마지막 커밋에 파일 추가
git add forgotten-file.js
git commit --amend --no-edit

# 3. 커밋 취소 (변경사항 유지)
git reset HEAD~1
# 다시 수정 후 재커밋

# 4. 커밋 취소 (변경사항도 삭제)
git reset --hard HEAD~1
# ⚠️ 주의: 복구 불가능!

# 5. 특정 파일만 이전 상태로
git checkout HEAD -- file.js

# 6. 여러 커밋 정리 (Interactive Rebase)
git rebase -i HEAD~3

# 편집기에서:
pick abc123 커밋 1
squash def456 커밋 2  # 커밋 1에 합치기
squash ghi789 커밋 3  # 커밋 1에 합치기

# 저장하면 3개 커밋이 1개로 합쳐짐

# 7. 이미 푸시한 커밋 수정 (주의!)
git commit --amend
git push --force origin feature-branch

# ⚠️ 팀원들에게 알리고 사용!
# Force push는 협업 중 위험할 수 있음

# 8. 특정 커밋 되돌리기 (새 커밋 생성)
git revert abc123
# 안전한 방법 (히스토리 유지)

# 9. 커밋 순서 변경
git rebase -i HEAD~5
# 편집기에서 순서 변경

# 10. 실수로 삭제한 커밋 복구
git reflog  # 모든 이력 확인
git reset --hard abc123  # 복구

Q3. 충돌(Conflict)을 피하려면?

# 충돌 예방 전략

# 1. 자주 동기화 (가장 중요!)
# 작업 시작 전
git checkout main
git pull origin main
git checkout feature-branch
git merge main

# 작업 중간중간 (하루에 1-2회)
git fetch origin
git merge origin/main

# 2. 작은 단위로 자주 커밋
# ✅ 좋은 습관
git commit -m "feat: 사용자 입력 폼 추가"
git commit -m "feat: 유효성 검증 추가"
git commit -m "feat: API 연동"

# ❌ 나쁜 습관
# 3일 작업 후 한 번에 커밋

# 3. 브랜치 수명 짧게
# ✅ 이상적: 1-2일
# ❌ 위험: 1주일 이상

# 4. 작업 영역 분리
# 팀원 A: 로그인 페이지 (src/Login.js)
# 팀원 B: 회원가입 페이지 (src/Signup.js)
# → 충돌 없음!

# 5. 코드 리뷰 빠르게
# PR이 오래 대기하면 충돌 가능성 증가
# 24시간 내 리뷰 목표

# 6. 대규모 리팩토링은 별도 계획
# 전체 파일 구조 변경 시:
# - 팀원들에게 미리 공지
# - 다른 작업 일시 중단
# - 빠르게 병합

# 7. .gitignore 잘 관리
# 빌드 결과물, 로그 등은 커밋 안 함
node_modules/
build/
*.log
.env

# 8. 포매터/린터 통일
# .editorconfig, .prettierrc 사용
# 팀 전체가 동일한 코드 스타일

# 충돌이 발생해도 겁먹지 마세요!
# 침착하게 해결하면 됩니다.

Q4. 오픈소스 프로젝트에 기여하려면?

# 오픈소스 기여 워크플로우

# 1. 프로젝트 찾기
# - GitHub Explore (github.com/explore)
# - "good first issue" 라벨
# - 관심 있는 기술 스택

# 2. 저장소 Fork
# GitHub 웹사이트에서 "Fork" 버튼 클릭
# 본인 계정에 복사본 생성

# 3. Clone (원본이 아닌 Fork한 저장소)
git clone https://github.com/YOUR_USERNAME/project.git
cd project

# 4. Upstream 원격 추가 (원본 저장소)
git remote add upstream https://github.com/ORIGINAL_OWNER/project.git
git remote -v
# origin    (본인 fork)
# upstream  (원본 저장소)

# 5. 브랜치 생성
git checkout -b fix/typo-in-readme

# 6. 기여 가이드라인 확인
cat CONTRIBUTING.md
# - 코드 스타일
# - 테스트 요구사항
# - 커밋 메시지 규칙

# 7. 코드 수정
# 예: README.md 오타 수정
sed -i 's/occured/occurred/g' README.md

# 8. 테스트 실행
npm test
npm run lint

# 9. 커밋 (프로젝트 규칙 준수)
git add README.md
git commit -m "docs: fix typo in README

Changed 'occured' to 'occurred'"

# 10. Fork한 저장소에 푸시
git push origin fix/typo-in-readme

# 11. Pull Request 생성
# GitHub 웹사이트에서:
# 1. "Compare & pull request" 버튼
# 2. Base repository: 원본 저장소
# 3. Base: main
# 4. Head repository: 본인 fork
# 5. Compare: fix/typo-in-readme

# PR 설명:
## Description
Fixed a typo in the README file.

## Changes
- Changed 'occured' to 'occurred' in line 42

## Checklist
- [x] Read CONTRIBUTING.md
- [x] Tests pass
- [x] No linting errors

# 12. 메인테이너의 피드백 대기
# - 수정 요청 시 동일 브랜치에서 추가 커밋
# - 승인 시 병합됨!

# 13. Upstream 동기화 (지속적 기여 시)
git fetch upstream
git checkout main
git merge upstream/main
git push origin main

# 🎉 첫 오픈소스 기여 완료!

# 팁:
# - 작은 것부터 시작 (오타 수정, 문서 개선)
# - 코드 리뷰를 학습 기회로 활용
# - 커뮤니티 에티켓 준수
# - 인내심 갖기 (리뷰에 시간 걸릴 수 있음)

Q5. 대규모 팀 협업 전략은?

# 대규모 팀 (10명 이상) 협업 전략

# 1. Git Flow 전략
main (프로덕션)
├─ develop (개발)
│   ├─ feature/login (팀원 A)
│   ├─ feature/payment (팀원 B)
│   └─ feature/analytics (팀원 C)
├─ release/v1.0 (QA 테스트)
└─ hotfix/critical-bug (긴급 수정)

# 2. 팀 구조
Frontend Team
├─ feature/ui-components
├─ feature/user-dashboard
└─ feature/admin-panel

Backend Team
├─ feature/api-users
├─ feature/api-orders
└─ feature/database-migration

DevOps Team
├─ feature/ci-cd-pipeline
└─ feature/monitoring

# 3. 코드 오너십 (CODEOWNERS 파일)
# .github/CODEOWNERS
# 각 경로별 리뷰어 자동 지정

# Frontend
/src/components/ @frontend-team
/src/pages/ @frontend-team

# Backend
/server/ @backend-team
/api/ @backend-team

# DevOps
/.github/ @devops-team
/docker/ @devops-team

# 특정 파일
/package.json @tech-lead
/security/ @security-team

# 4. Branch Protection Rules
# Settings → Branches → Add rule

# main 브랜치 보호:
✅ Require pull request reviews (최소 2명)
✅ Require status checks (CI 통과 필수)
✅ Require branches to be up to date
✅ Include administrators (관리자도 규칙 준수)
❌ Allow force pushes (금지)
❌ Allow deletions (금지)

# develop 브랜치:
✅ Require pull request reviews (최소 1명)
✅ Require status checks

# 5. PR 크기 제한
# .github/workflows/pr-size.yml
# PR이 500줄 초과 시 경고

# 6. 자동화된 리뷰 요청
# PR 생성 시 자동으로:
# - 해당 팀 멤버 리뷰어 지정
# - Slack/Discord 알림
# - Jira 티켓 자동 연동

# 7. 릴리스 프로세스
# 1주일 스프린트:
월요일: 스프린트 시작, 브랜치 생성
화-목요일: 개발 및 PR
금요일: 코드 리뷰 및 병합
주말: QA 테스트
다음 월요일: 프로덕션 배포

# 8. 커뮤니케이션 채널
# Slack 채널:
- #dev-general (일반 논의)
- #dev-frontend (프론트엔드)
- #dev-backend (백엔드)
- #github-notifications (PR, 이슈)
- #deployments (배포 알림)

# 9. 문서화
# /docs
├─ ARCHITECTURE.md (시스템 구조)
├─ API.md (API 문서)
├─ SETUP.md (개발 환경 설정)
├─ CONTRIBUTING.md (기여 가이드)
└─ STYLEGUIDE.md (코드 스타일)

# 10. 정기 미팅
- Daily standup (15분): 진행 상황 공유
- PR review session (주 2회): 함께 리뷰
- Retrospective (스프린트 종료): 회고

# 대규모 팀은 프로세스가 중요합니다!
# 자동화와 명확한 규칙으로 효율성 극대화

🎓 다음 단계

GitHub 협업을 마스터했다면, 다음을 학습해보세요:

CI/CD란? - 자동화된 테스트와 배포 파이프라인
첫 웹사이트 배포하기 - GitHub Actions로 자동 배포
에러 로깅과 모니터링 - 프로덕션 환경에서 협업하기

실전 연습 프로젝트

# 팀 프로젝트 아이디어

# 초급 (2-3명)
1. 할일 관리 앱 (Todo App)
   - 역할: Frontend, Backend, 디자인
   - 기간: 1-2주

2. 간단한 블로그 플랫폼
   - 역할: UI, API, 데이터베이스
   - 기간: 2-3주

# 중급 (4-5명)
3. E-commerce 쇼핑몰
   - 역할: Frontend, Backend, DevOps, QA
   - 기간: 4-6주

4. 실시간 채팅 애플리케이션
   - 역할: Frontend, Backend, WebSocket, 보안
   - 기간: 3-4주

# 고급 (6-10명)
5. 소셜 미디어 플랫폼
   - 역할: 여러 팀으로 분리
   - 기간: 8-12주

# 연습 팁:
- 작은 프로젝트로 시작
- Git Flow 실습
- 코드 리뷰 의무화
- CI/CD 설정
- 문서화 습관

🎬 마무리

GitHub 협업의 핵심:

브랜치: 독립적인 작업 공간
Pull Request: 코드 리뷰와 품질 관리
이슈: 작업 추적과 소통
충돌 해결: 협업의 필수 스킬
자동화: CI/CD로 효율성 증가

협업은 단순히 도구 사용을 넘어, 팀원들과의 소통과 존중입니다. 명확한 커밋 메시지, 건설적인 코드 리뷰, 적극적인 피드백이 성공적인 협업의 비결입니다! 🤝✨

지금 바로 팀원들과 함께 프로젝트를 시작해보세요. 실전 경험이 최고의 학습입니다!

📖 정의​

🎯 비유로 이해하기​

공동 문서 작성​

레스토랑 주방​

⚙️ 작동 원리​

1. GitHub 협업 워크플로우​

2. 브랜치 전략 (Git Flow)​

3. Pull Request 프로세스​

💡 실제 예시​

준비: 팀 프로젝트 시작​

Step 1: 팀원들 합류​

Step 2: Issue로 작업 관리​

Step 3: 브랜치에서 작업하기​

4. 테스트 작성

5. 로컬에서 테스트

6. 작은 단위로 자주 커밋 (권장!)

7. 인증 로직 추가

... 코드 작성 ...

8. 테스트 추가

9. 원격에 푸시

💡 팁: 커밋 메시지 규칙

feat: 새 기능

fix: 버그 수정

docs: 문서 변경

style: 코드 포매팅

refactor: 리팩토링

test: 테스트 추가

chore: 빌드, 설정 변경

📸 스크린샷​

🔗 관련 이슈​

📋 체크리스트​

💬 리뷰어에게​

3. Create pull request 클릭

🎉 PR 생성 완료!

- 팀원들에게 자동 알림

- GitHub Actions CI가 자동 실행 (설정된 경우)

- 코드 리뷰 시작!

Step 6: 피드백 반영​

3. 커밋 및 푸시

Step 7: 재검토 및 승인​

Step 8: Pull Request 병합​

Step 9: 동시 작업 및 충돌 해결​

Step 10: 고급 협업 - Code Review Best Practices​

코드 블록으로 설명

Step 12: 프로젝트 관리 - GitHub Projects​

🤔 자주 묻는 질문​

Q1. 브랜치 네이밍 규칙은?​

Q2. 커밋을 잘못했을 때 어떻게 하나요?​

Q3. 충돌(Conflict)을 피하려면?​

Q4. 오픈소스 프로젝트에 기여하려면?​

Q5. 대규모 팀 협업 전략은?​

🎓 다음 단계​

실전 연습 프로젝트​

🎬 마무리​

📖 정의

🎯 비유로 이해하기

공동 문서 작성

레스토랑 주방

⚙️ 작동 원리

1. GitHub 협업 워크플로우

2. 브랜치 전략 (Git Flow)

3. Pull Request 프로세스

💡 실제 예시

준비: 팀 프로젝트 시작

Step 1: 팀원들 합류

Step 2: Issue로 작업 관리

Step 3: 브랜치에서 작업하기

📸 스크린샷

🔗 관련 이슈

📋 체크리스트

💬 리뷰어에게

Step 6: 피드백 반영

Step 7: 재검토 및 승인

Step 8: Pull Request 병합

Step 9: 동시 작업 및 충돌 해결

Step 10: 고급 협업 - Code Review Best Practices

Step 12: 프로젝트 관리 - GitHub Projects

🤔 자주 묻는 질문

Q1. 브랜치 네이밍 규칙은?

Q2. 커밋을 잘못했을 때 어떻게 하나요?

Q3. 충돌(Conflict)을 피하려면?

Q4. 오픈소스 프로젝트에 기여하려면?

Q5. 대규모 팀 협업 전략은?

🎓 다음 단계

실전 연습 프로젝트

🎬 마무리