포스트

[GitHub 100일 챌린지] Day 51 - Fork 개념 이해

[GitHub 100일 챌린지] Day 51 - Fork 개념 이해

100일 챌린지 Day 51 - Fork는 오픈소스 기여의 첫 단계입니다. 다른 사람의 저장소를 내 계정으로 복사하여 자유롭게 실험하고 개선할 수 있습니다.

배울 내용

  1. Fork의 개념과 Clone의 차이점
  2. Fork가 필요한 이유와 활용 시나리오
  3. Fork한 저장소와 원본 저장소의 관계

1. Fork란 무엇인가?

Fork의 정의

Fork는 다른 사용자의 GitHub 저장소를 내 GitHub 계정으로 복사하는 것입니다.

graph LR
    A[원본 저장소<br/>facebook/react] -->|Fork| B[내 저장소<br/>myname/react]
    B -->|독립적으로<br/>작업| C[수정/개선]
    C -->|Pull Request| A

Fork vs Clone 차이점

특징 Fork Clone
위치 GitHub 서버 간 복사 GitHub → 로컬 컴퓨터
결과 내 GitHub 계정에 저장소 생성 내 컴퓨터에 코드 다운로드
권한 원본 저장소와 독립적 원본 저장소 권한 필요
용도 오픈소스 기여, 독립 개발 로컬 작업
연결 원본과 연결 유지 가능 원격 저장소와 연결
Fork와 Clone을 함께 사용하는 이유는?

Fork → Clone 순서로 작업:

  1. Fork: 원본 저장소를 내 GitHub으로 복사 (서버 간)
  2. Clone: 내 Fork를 로컬로 다운로드
  3. 작업: 로컬에서 코드 수정
  4. Push: 내 Fork로 업로드
  5. Pull Request: 원본 저장소에 기여 제안
1
2
3
4
5
6
7
8
# 1. Fork (웹에서 버튼 클릭)
# 2. Clone (내 Fork를 로컬로)
git clone https://github.com/내계정/저장소.git

# 3. 작업 후 Push (내 Fork로)
git push origin main

# 4. Pull Request (웹에서 생성)

2. Fork가 필요한 이유

권한 문제 해결

graph TB
    subgraph "❌ Fork 없이 (불가능)"
        A1[원본 저장소<br/>facebook/react] -.->|직접 Push<br/>❌ 권한 없음| A2[수정 실패]
    end

    subgraph "✅ Fork 사용 (가능)"
        B1[원본 저장소<br/>facebook/react] -->|Fork| B2[내 저장소<br/>myname/react]
        B2 -->|Push<br/>✅ 내 저장소| B3[수정 성공]
        B3 -->|Pull Request| B1
    end

Fork가 필요한 상황

1. 오픈소스 프로젝트 기여

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# 시나리오: React 프로젝트에 버그 수정 기여

# 1. facebook/react를 Fork → myname/react 생성
# 2. myname/react를 Clone하여 로컬 작업
git clone https://github.com/myname/react.git

# 3. 버그 수정 브랜치 생성
git checkout -b fix-button-bug

# 4. 코드 수정 후 커밋
git commit -m "fix: Resolve button rendering issue"

# 5. 내 Fork로 Push
git push origin fix-button-bug

# 6. Pull Request 생성 (웹에서)
# facebook/react ← myname/react

2. 타인의 프로젝트를 기반으로 독립 개발

1
2
3
4
5
6
7
8
9
10
11
# 시나리오: 블로그 테마를 Fork해서 내 스타일로 커스터마이징

# 1. 마음에 드는 Jekyll 테마 Fork
# original-author/awesome-theme → myname/awesome-theme

# 2. 내 방식대로 수정
git clone https://github.com/myname/awesome-theme.git
# 색상, 레이아웃, 기능 변경

# 3. 독립적으로 유지보수
# 원본과 연결 유지 불필요

3. 실험과 테스트

1
2
3
4
5
6
7
8
9
10
11
# 시나리오: 프로젝트의 새로운 기능 실험

# 1. Fork로 안전한 실험 환경 확보
git clone https://github.com/myname/project-fork.git

# 2. 실험적인 기능 추가
git checkout -b experimental-feature
# 과감한 변경 시도

# 3. 성공 시 PR, 실패 시 삭제
# 원본 프로젝트는 영향 받지 않음

3. Fork와 원본 저장소의 관계

독립성과 연결성

graph TB
    subgraph "Original Repository"
        O[facebook/react<br/>Main Branch]
    end

    subgraph "Forked Repository"
        F[myname/react<br/>Main Branch]
    end

    subgraph "Local Repository"
        L[내 컴퓨터<br/>로컬 작업]
    end

    O -.->|Fork<br/>최초 1회| F
    O -.->|Upstream<br/>동기화 가능| L
    F -->|Clone| L
    L -->|Push| F
    F -.->|Pull Request| O

    style O fill:#e1f5ff
    style F fill:#fff4e1
    style L fill:#f0f0f0

저장소 간 관계 용어

용어 의미 예시
Upstream 원본 저장소 (Fork 출처) facebook/react
Origin 내 Fork된 저장소 myname/react
Local 내 컴퓨터의 로컬 저장소 C:/projects/react
1
2
3
4
5
6
7
8
# 저장소 관계 확인
git remote -v

# 일반적인 출력:
# origin    https://github.com/myname/react.git (fetch)
# origin    https://github.com/myname/react.git (push)
# upstream  https://github.com/facebook/react.git (fetch)
# upstream  https://github.com/facebook/react.git (push)

4. Fork 동작 방식

Fork 시 복사되는 것

복사되는 것:

  • 모든 코드 파일
  • 전체 커밋 히스토리
  • 브랜치 구조
  • 태그 정보

복사되지 않는 것:

  • Issues (이슈)
  • Pull Requests
  • Wiki 페이지
  • GitHub Actions 워크플로우 실행 기록
  • Discussions

Fork의 독립성

1
2
3
4
5
6
7
8
9
10
# Fork 후 각 저장소는 독립적으로 운영

# 원본 저장소 (facebook/react)
# - 메인 개발팀이 관리
# - 매일 수십 개의 커밋

# 내 Fork (myname/react)
# - 내가 자유롭게 수정
# - 원본의 변경사항 자동 반영 ❌
# - 원하는 시점에 수동으로 동기화 가능

5. Fork 실습 시나리오

시나리오 1: 문서 오타 수정 기여

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# 1. 오픈소스 프로젝트에서 README 오타 발견
# 원본: microsoft/vscode-docs

# 2. Fork 버튼 클릭 → myname/vscode-docs 생성

# 3. Clone
git clone https://github.com/myname/vscode-docs.git
cd vscode-docs

# 4. 브랜치 생성
git checkout -b fix-typo-readme

# 5. README.md 오타 수정
# "donwload" → "download"

# 6. 커밋
git add README.md
git commit -m "docs: Fix typo in README (donwload → download)"

# 7. Push to Fork
git push origin fix-typo-readme

# 8. Pull Request 생성 (GitHub 웹에서)

시나리오 2: 새 기능 추가 제안

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# 1. Fork: awesome-cli-tool
# 2. Clone & 브랜치 생성
git clone https://github.com/myname/awesome-cli-tool.git
git checkout -b feature-new-command

# 3. 새 기능 개발
# - 새로운 CLI 명령어 구현
# - 테스트 코드 작성
# - 문서 업데이트

# 4. 커밋 및 Push
git add .
git commit -m "feat: Add new 'export' command"
git push origin feature-new-command

# 5. Pull Request with detailed description

6. Fork 사용 시 주의사항

라이선스 확인

1
2
3
4
5
6
7
8
9
10
11
12
# Fork 전 필수 확인 사항**확인해야 할 것**:
1. 저장소 라이선스 종류 (LICENSE 파일)
2. Fork 및 수정 허용 여부
3. 상업적 사용 가능 여부
4. 출처 표기 의무 여부

⚠️ **주의**:
- MIT, Apache 2.0: 자유롭게 Fork 가능
- GPL: Fork 시 동일 라이선스 적용 필요
- 라이선스 없음: 저작권법 적용 (허가 필요)

Fork ≠ 소유권 이전

1
2
3
4
5
6
7
8
9
# ❌ 잘못된 인식
"Fork하면 이제 내 프로젝트야!"
# Fork해도 원본 저작권은 유지됩니다.

# ✅ 올바른 이해
"Fork는 협업을 위한 복사본"
# - 원본 라이선스 준수 필요
# - 원본 저작자 표기 유지
# - 라이선스에 따른 의무 이행

Fork 수와 Star 수

1
2
3
4
5
6
**GitHub 프로젝트 인기 지표**:
- **Star**: 프로젝트가 마음에 듦 (북마크)
- **Fork**: 실제로 코드를 사용하거나 기여할 의도

Fork가 많다 = 실제로 많이 사용되는 프로젝트
Star가 많다 = 관심도가 높은 프로젝트

7. 실전 예시: 유명 프로젝트 Fork 구조

React 프로젝트 구조

1
2
3
4
5
6
7
8
9
10
11
12
13
facebook/react (원본)
├── ⭐ 220k stars
├── 🍴 45k forks
├── Issues: 1,234
└── Pull Requests: 234

myname/react (내 Fork)
├── Forked from facebook/react
├── 내 브랜치들
│   ├── fix-hooks-bug
│   ├── experimental-feature
│   └── docs-improvement
└── Pull Requests → facebook/react

전형적인 Fork 워크플로우

sequenceDiagram
    participant O as 원본 저장소<br/>(Upstream)
    participant F as 내 Fork<br/>(Origin)
    participant L as 로컬 저장소

    O->>F: 1. Fork (웹에서 버튼 클릭)
    F->>L: 2. Clone
    L->>L: 3. 브랜치 생성 & 작업
    L->>F: 4. Commit & Push
    F->>O: 5. Pull Request
    O->>O: 6. 코드 리뷰
    O->>O: 7. Merge (기여 완료!)

8. Fork 활용 팁

1. Fork 전 프로젝트 평가

1
2
3
4
5
6
7
8
9
10
**좋은 Fork 대상**:
- 활발한 커밋 활동 (최근 1개월 내)
- 명확한 Contributing 가이드
- 친절한 코드 리뷰 문화
- CI/CD 자동화 구축

⚠️ **주의가 필요한 경우**:
- 1년 이상 업데이트 없음
- Issue/PR이 방치됨
- 문서화 부족

2. Fork 후 첫 단계

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# Fork 직후 권장 작업

# 1. Clone
git clone https://github.com/myname/project.git
cd project

# 2. Upstream 원격 저장소 추가
git remote add upstream https://github.com/original/project.git

# 3. 원격 저장소 확인
git remote -v
# origin    https://github.com/myname/project.git
# upstream  https://github.com/original/project.git

# 4. Upstream에서 최신 변경사항 가져오기
git fetch upstream

# 5. 로컬 main 브랜치 업데이트
git checkout main
git merge upstream/main

정리

완료 체크:

  • Fork와 Clone의 차이를 설명할 수 있다
  • Fork가 필요한 3가지 상황을 이해했다
  • Upstream, Origin, Local의 관계를 그림으로 그릴 수 있다
  • Fork한 저장소의 독립성과 연결성을 이해했다
  • Fork 전 라이선스 확인의 중요성을 인식했다

핵심 요약:

  • Fork = 다른 사람의 저장소를 내 GitHub으로 복사
  • Clone은 로컬로 다운로드, Fork는 서버 간 복사
  • Fork는 오픈소스 기여의 필수 첫 단계
  • Upstream(원본), Origin(내 Fork), Local(내 컴퓨터) 구조 이해

다음 단계:

  • Upstream과 Origin 원격 저장소 관리
  • Fork와 원본 저장소 동기화 방법
  • Fork 기반 협업 워크플로우 구축

다음: Day 52 - Upstream과 Origin


이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.