100일 챌린지 Day 51 - Fork는 오픈소스 기여의 첫 단계입니다. 다른 사람의 저장소를 내 계정으로 복사하여 자유롭게 실험하고 개선할 수 있습니다.
배울 내용
- Fork의 개념과 Clone의 차이점
- Fork가 필요한 이유와 활용 시나리오
- 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 순서로 작업:
- Fork: 원본 저장소를 내 GitHub으로 복사 (서버 간)
- Clone: 내 Fork를 로컬로 다운로드
- 작업: 로컬에서 코드 수정
- Push: 내 Fork로 업로드
- 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 →