GitHub 다운로드·clone·fork 차이: 작업 목적별로 고르는 법

파일 내용만 쓰면 되는 경우는 다운로드(ZIP), 내 컴퓨터에서 Git으로 변경 이력을 관리하며 작업하는 경우는 복제(clone), 원본 저장소에 변경을 제안하거나 원본을 바탕으로 내 GitHub 프로젝트를 시작하는 경우는 포크(fork)가 GitHub 문서가 제시하는 용도입니다 (GitHub Docs). 문서는 fork한 뒤에도 로컬에서 작업하려면 저장소를 clone할 수 있다고 설명합니다 (GitHub Docs). 이 점에서 fork와 clone은 이어서 쓸 수 있는 관계로 해석할 수 있습니다.

네 가지 기준으로 세 방식을 비교합니다

GitHub 문서는 저장소 파일의 사본을 얻는 방법이 여러 가지라고 설명합니다 (GitHub Docs). 파일 스냅숏(특정 시점의 파일 상태)을 zip 파일로 내려받기, Git으로 로컬 컴퓨터에 clone하기, fork해서 GitHub에 새 저장소 만들기가 그것입니다 (GitHub Docs).

이 글은 작업 목적, 로컬에 남는 변경 이력, GitHub 저장소와의 관계, 원본에 변경을 제안할 수 있는지라는 네 가지 기준으로 세 방식을 나란히 놓습니다. 이 기준은 파일만 받기, 이력 관리, 변경 제안이라는 독자의 세 가지 목적을 그대로 옮긴 이 글의 선택입니다.

비교 표: 변경 이력과 GitHub 저장소에서 갈립니다

표를 한 줄로 줄이면, clone은 내 컴퓨터에 이력 전체를 가져오고 fork는 GitHub 위에 upstream과 연결된 내 소유 저장소를 만든다는 차이로 해석할 수 있습니다 (GitHub Docs, GitHub Docs). clone이 복사되는 곳은 로컬 기기일 수도 있고, codespace를 만들 때의 원격 가상 머신일 수도 있습니다 (GitHub Docs).

내 상황에는 무엇이 맞나요

파일 내용만 필요하면 다운로드

GitHub 문서는 흥미로운 콘텐츠를 찾았을 때 Git이나 버전 관리 없이 사본을 얻는 간단한 방법으로 다운로드를 소개합니다 (GitHub Docs). 문서상 절차는 파일 목록 위의 Code를 누른 뒤 Download ZIP을 누르는 것이고, 끝나면 저장소 파일 사본이 zip 파일로 로컬 컴퓨터에 저장됩니다 (GitHub Docs).

애플리케이션 최신 버전이나 설치 파일·실행 파일을 받으려는 경우에는 릴리스나 태그의 소스 코드 아카이브 문서를 보라고 안내합니다 (GitHub Docs). 내려받은 파일의 변경을 추적하거나 원본과 계속 맞춰 갈 계획이라면 다운로드는 맞지 않는다고 보는 것이 이 글의 해석입니다 (GitHub Docs).

변경 이력을 관리하며 작업하려면 clone

clone은 로컬에서 Git으로 변경을 추적·관리하려는 경우에 맞고, 문서는 이런 사용자가 로컬 변경을 GitHub 저장소와 동기화하려 할 가능성이 높다고 설명합니다 (GitHub Docs). 병합 충돌 해결, 파일 추가·삭제, 큰 커밋 push를 쉽게 하려는 목적도 문서에 적혀 있습니다 (GitHub Docs). 내 저장소뿐 아니라 다른 사람의 저장소도 프로젝트에 기여하기 위해 clone할 수 있습니다 (GitHub Docs).

쓰기 권한이 없는 원본에 변경을 제안하려면 fork와 pull request

fork는 쓰기 권한이 없는 프로젝트에 기여할 때 유용하다고 문서는 밝힙니다 (GitHub Docs). 반대로 쓰기 권한이 있고 공유 저장소에서 협업한다면 fork 대신 브랜치(같은 저장소 안의 별도 작업 갈래)를 쓰라고 안내합니다 (GitHub Docs).

문서가 설명하는 일반적인 흐름은 fork하고, 내 사본에서 작업하고, 준비되면 pull request(내 변경을 원본에 반영해 달라는 제안)를 여는 것입니다 (GitHub Docs). pull request를 만들기 전에 변경을 내 fork의 브랜치에 push해 두어야 하며, 이때 base 브랜치는 병합 대상이고 compare 브랜치는 내 변경이 담긴 fork의 브랜치입니다 (GitHub Docs). 문서에 적힌 단계는 fork를 만든 원본 저장소로 이동하는 것과, 새 pull request를 만드는 페이지에서 compare across forks를 누르는 것입니다 (GitHub Docs).

로컬에서 편집하고 싶다면 fork한 뒤 다시 clone할 수 있습니다 (GitHub Docs). 따라서 이 상황은 fork와 clone 중 하나를 고르는 문제가 아니라 둘을 이어 쓰는 흐름으로 이해할 수 있습니다.

원본과 다른 방향을 시험하려면 fork

fork는 upstream에 영향을 주지 않고 변경을 실험하거나, 나중에 독립할 수도 있는 새 방향을 탐색할 때 유용하다고 문서는 설명합니다 (GitHub Docs). upstream으로부터 독립이 필요할 때도 fork를 쓰라고 안내합니다 (GitHub Docs).

비교의 한계와 주의

이 글의 포크 설명은 GitHub Free, Pro, & Team 문서를 기준으로 합니다 (GitHub Docs).

• 공개 범위: fork의 공개 범위는 upstream을 따르며, 공개 저장소의 fork는 공개, 비공개 저장소의 fork는 비공개이고 fork만 따로 바꿀 수 없습니다 (GitHub Docs).
• 만들 수 있는 조건: 문서는 공개 저장소는 fork할 수 있다고 밝히고 (GitHub Docs), 비공개 저장소는 접근 권한이 있고 소유자가 허용할 때 fork할 수 있다고 설명합니다 (GitHub Docs). 다만 GitHub Free를 쓰는 조직으로는 비공개 저장소를 fork할 수 없으며 (GitHub Docs), 저장소·조직·엔터프라이즈 정책이 fork 가능 여부와 생성 위치를 제한할 수 있습니다 (GitHub Docs).

이 글은 작업 목적에 따른 선택을 설명하며, 각 방식의 모든 명령과 권한 설정을 안내하는 글은 아닙니다. 실제 작업 전에는 연결된 공식 문서와 저장소의 기여 안내를 함께 확인하세요.

• fork를 삭제해도 코드 기여가 저장소 네트워크에 남을 수 있으며, upstream 소유자는 네트워크의 모든 fork를 읽을 수 있습니다 (GitHub Docs).
• Actions 워크플로가 있는 fork 브랜치에서 메인테이너 편집을 허용하면 secrets가 드러나거나 다른 브랜치 접근이 생길 수 있다고 문서는 경고합니다 (GitHub Docs).