Fork vs git clone 비교

오픈소스 프로젝트에 PR을 보낼 일이 생겼다. 평소엔 협업 레포에서 git clone만 써왔는데, Fork는 처음이라 헷갈렸다. 둘이 비슷해 보여도 remote 구성과 권한 모델이 달라서, 작업 방식을 나란히 놓고 정리해뒀다.

Fork 워크플로우

Fork는 원본 레포지토리를 내 GitHub 계정으로 복제하는 동작이다. 원본을 직접 건드릴 수 없을 때, 내 공간에서 자유롭게 작업한 뒤 PR로 의견을 제시하기 위한 방식이다.

순서는 이렇다.

1. Fork 하고 싶은 프로젝트에서 Fork 버튼 클릭.
2. 내 리파지토리로 돌아와서 Fork 한 프로젝트를 git clone.
3. git remote add upstream <원본 프로젝트 url>로 원본 remote 추가.

세 번째가 중요했다. 작업하면서 원본의 수정사항을 받아오려면 원본을 가리키는 remote가 따로 필요했기 때문이다. 이걸 안 해두고 git fetch나 git pull을 하면, 원본 프로젝트의 수정사항이 아니라 Fork 해온 내 리파지토리의 수정사항만 반영된다. origin은 내 Fork를 가리키고 있어서다.

그래서 명령을 구분해서 써야 한다.

git pull upstream main    # 원본의 최신 변경 받기
git fetch upstream        # 원본 변경 가져와서 확인만
git push origin feature   # 내 Fork에 푸시

내 Fork에서 작업 후 push하면 원본 리파지토리로 pull request를 보낼 수 있다. 원본 개발자가 merge하면 내 커밋이 원본 리파지토리에 반영되고, 그 리파지토리의 Contributors 목록(커밋 기여자 통계)에 자동으로 집계된다. 쓰기 권한이 부여되는 collaborator가 되는 것은 아니다. 다음 PR도 동일하게 Fork → 작업 → PR 흐름을 거쳐야 한다.

git clone 워크플로우

git clone은 협업 권한이 있는 레포를 그대로 내려받아 작업하는 방식이다. 회사 레포나 팀 프로젝트에서 주로 쓴다.

순서는 단순하다.

1. clone 하고 싶은 프로젝트에서 code 버튼 클릭 후 url 복사.
2. 프로젝트가 위치할 폴더에서 git clone <프로젝트 url>.
3. (Node.js 프로젝트라면) node_modules는 보통 .gitignore에 등록되어 있어 clone 결과에 포함되지 않는다. npm install(또는 yarn install, pnpm install)로 의존성을 설치했다.

작업 후 push하면 clone 한 리파지토리에 바로 반영된다. 단, 쓰기 권한을 부여받아야 가능하다. pull도 마찬가지로 실행하면 곧바로 원본의 수정사항이 반영된다. remote가 처음부터 원본을 가리키고 있기 때문이다.

둘을 나란히 놓고 보면

Fork는 작업 중에도 원본 파일의 수정사항을 받아오려고 원본용 새 remote(upstream)를 추가하는 단계가 핵심이었다. clone은 그게 필요 없는 대신, 다른 사람 작업 내용을 직접 변경할 수 있는 만큼 branch와 merge에 더 신경 써야 했다.