오픈소스와 팀 협업의 꽃 — Fork·Clone과 Pull Request로 첫 기여하기

이 글은 Git 입문 시리즈의 6편입니다. 브랜치와 병합(merge)이 아직 낯설다면, 먼저 5편. 평행 우주에서 안전하게 개발 (Branch & Conflict)을 보고 오시면 훨씬 수월합니다.

지금까지 우리는 내 저장소 안에서만 Git을 다뤘습니다. 커밋하고, 브랜치를 치고, GitHub에 올리고. 그런데 개발의 진짜 재미는 여기서부터예요. 바로 남이 만든 프로젝트에 내 코드를 보태는 것 — 오픈소스 기여입니다.

"내가 감히 유명한 오픈소스에 코드를?" 싶으시죠? 저도 처음엔 그 세계가 까마득해 보였어요. 그런데 알고 보면 그 모든 협업이 딱 하나의 흐름 위에서 돌아갑니다. 가져오고(fork·clone) → 고치고(branch·commit·push) → 정중히 제안하기(Pull Request). 이 한 줄이 전부예요.

이번 글에서는 남의 프로젝트를 내 것으로 복제하는 fork와 clone의 차이부터, 내 변경을 원본에 제안하는 Pull Request(PR)를 만들고, 길어진 작업 동안 원본의 최신 변경을 따라잡는 동기화까지 — 오픈소스 첫 기여의 전 과정을 따라가 봅니다.

clone과 fork, 뭐가 다를까

둘 다 "남의 저장소를 복사한다"는 점은 같습니다. 그런데 복사본이 어디에 생기느냐가 결정적으로 달라요. 1편에서 GitHub을 '사진 올리는 인스타그램'에 비유했죠. 그 비유를 그대로 이어가 볼게요.

구분	clone(클론)	fork(포크)
복사본 위치	내 컴퓨터(로컬)로 내려받기	원본을 통째로 내 GitHub 계정에 복제
인스타에 비유하면	남의 사진첩을 내 폰에 저장	남의 계정 전체를 내 계정으로 리포스트
원본 수정 권한	권한 있어야 원본에 push 가능	내 사본은 내 맘대로, 원본은 안전
주로 언제	내 저장소·팀 저장소를 받아 작업	남의 오픈소스에 기여할 때

핵심은 이거예요. 남의 오픈소스에는 보통 내가 직접 push할 권한이 없습니다. 아무나 원본을 고치면 큰일 나니까요. 그래서 먼저 원본을 fork해서 '내 소유의 복사본'을 GitHub에 만들고, 거기서 마음껏 작업한 뒤, "제 변경을 원본에 반영해 주실래요?" 하고 정중히 요청하는 겁니다. 그 요청이 바로 Pull Request예요.

그럼 clone은 안 쓰나요? — 아니에요, 둘은 짝꿍입니다. fork는 GitHub(웹) 안에서 원본 → 내 계정으로 복사하는 것이고, 그렇게 만든 내 사본을 실제로 코딩하려면 내 컴퓨터로 clone해 와야 합니다. fork로 사본을 만들고, clone으로 그 사본을 손에 쥐는 순서예요.

오픈소스 기여, 전체 그림부터

명령어를 치기 전에 큰 그림을 먼저 봅시다. 길어 보여도 5단계가 전부이고, 4·5편에서 배운 것들이 그대로 쓰입니다.

• 1. Fork — 원본 저장소를 내 GitHub 계정으로 복제한다. (웹에서 버튼 한 번)
• 2. Clone — 내 사본을 내 컴퓨터로 내려받는다. (3편에서 본 그 clone)
• 3. Branch & 작업 — 기능용 브랜치를 치고(5편) 코드를 고쳐 커밋한다.
• 4. Push — 내 사본(GitHub)에 브랜치를 올린다.
• 5. Pull Request — "이 변경을 원본에 합쳐주세요" 하고 제안한다.

1~2단계: Fork하고 내 컴퓨터로 가져오기

Fork는 GitHub 웹에서 합니다. 기여하고 싶은 저장소 페이지 오른쪽 위의 Fork 버튼을 누르면, 잠시 뒤 내아이디/저장소이름 형태로 똑같은 저장소가 내 계정에 생깁니다. 이게 내 소유의 복사본이에요.

이제 그 사본을 내 컴퓨터로 내려받습니다. 내 계정에 생긴 저장소의 초록색 Code 버튼에서 주소를 복사해 clone하면 됩니다.

git clone https://github.com/내아이디/저장소이름.git
cd 저장소이름

clone을 하면 Git이 원격 저장소에 origin이라는 별명을 자동으로 붙여줍니다. 여기서 origin은 방금 clone해 온 곳, 즉 '내 GitHub 사본'이에요. (원본이 아니라요. 이 구분이 곧 중요해집니다.)

원본을 가리키는 이름표, upstream 달기

작업이 길어지면 원본 저장소에도 다른 사람들의 새 코드가 계속 쌓입니다. 그 최신 변경을 따라잡으려면, 내 사본(origin)과 별개로 원본을 가리키는 이름표가 하나 더 필요해요. 관례적으로 이 이름은 upstream(상류)이라고 붙입니다.

git remote add upstream https://github.com/원본주인/저장소이름.git
git remote -v          # 등록된 원격 목록 확인 (origin과 upstream이 보임)

이제 정리하면 이렇습니다. origin = 내 사본, upstream = 원본. 강을 떠올리면 쉬워요. 원본은 물이 흘러나오는 상류(upstream), 내 사본은 그걸 받아 작업하는 하류인 셈이죠.

3~4단계: 브랜치 치고 작업하고 push하기

이제부터는 5편에서 배운 그대로입니다. 원본 코드는 건드리지 말고, 기능용 브랜치를 하나 쳐서 거기서 작업해요. (main에 바로 작업하지 않는 게 협업의 기본 예의입니다.)

git switch -c fix-typo      # 작업용 브랜치 생성 + 이동
# ... 코드 수정 ...
git add .
git commit -m "오타 수정: README의 잘못된 링크 교정"

커밋까지 했으면, 이 브랜치를 내 사본(origin)에 올립니다. 원본이 아니라 내 사본으로요 — 어차피 원본엔 권한이 없으니까요.

git push -u origin fix-typo

왜 굳이 브랜치를 칠까요? — main에 바로 작업하면, PR을 올린 뒤 리뷰를 기다리는 동안 다른 작업을 시작하기가 곤란해집니다. 기능마다 브랜치를 따로 두면 PR도 깔끔하게 하나씩 분리되고, 원본 관리자도 변경을 검토하기 훨씬 쉬워요.

5단계: Pull Request 올리기

push를 마치고 내 사본 저장소 페이지(GitHub)에 가보면, 방금 올린 브랜치에 대해 "Compare & pull request"라는 초록 버튼이 떠 있습니다. 누르면 PR 작성 화면이 열려요.

여기서 확인할 건 딱 하나, 화살표의 방향입니다. 원본주인/저장소:main ← 내아이디/저장소:fix-typo 형태, 즉 "내 브랜치를 원본의 main으로 보낸다"가 맞는지 보세요. 그다음 제목과 설명을 적습니다.

• 제목 — 무엇을 바꿨는지 한 줄로. (커밋 메시지와 같은 원칙이에요.)
• 설명 — 왜 이 변경이 필요한지, 어떻게 테스트했는지 적습니다. 리뷰어가 가장 궁금해하는 부분이에요.

Create pull request를 누르면 끝. 이제 공은 원본 관리자에게 넘어갑니다. 관리자는 코드를 보고 댓글로 수정을 요청하거나, 좋으면 Merge 버튼으로 원본에 합쳐줍니다. 리뷰 중 고칠 게 생기면 어떻게 할까요? 그냥 같은 브랜치에 다시 커밋하고 push하면 PR에 자동으로 반영됩니다. PR을 새로 만들 필요가 없어요.

PR은 'Pull Request', 즉 당겨가 달라는 요청이에요 — 내가 원본에 밀어넣는(push) 게 아니라, "제 변경사항을 당겨가(pull) 주세요" 하고 정중히 부탁하는 겁니다. 그래서 강제로 끼어드는 게 아니라, 리뷰와 토론을 거쳐 합의된 코드만 원본에 들어가요. 이 점이 오픈소스를 건강하게 굴러가게 하는 핵심입니다.

원본이 바뀌었을 때 — fork 동기화

기여를 한두 번 하다 보면 마주치는 상황이 있어요. 내가 작업하는 사이 원본에 다른 사람들의 코드가 잔뜩 쌓이는 겁니다. 내 사본은 fork한 그 시점에 멈춰 있으니, 점점 뒤처지죠. 이럴 때 아까 달아둔 upstream이 빛을 발합니다.

git switch main              # 내 main으로 이동
git fetch upstream           # 원본(upstream)의 최신 변경을 가져오기(아직 합치진 않음)
git merge upstream/main      # 그 변경을 내 main에 합치기
git push origin main         # 최신화된 내 사본도 GitHub에 반영

fetch는 원본의 변경을 '가져오기만' 하고, merge가 실제로 내 코드에 합칩니다. (3편에서 pull = fetch + merge라고 했던 것, 기억나시죠?) 이렇게 주기적으로 원본을 따라잡아 두면, 나중에 PR을 올릴 때 충돌이 확 줄어듭니다.

작업은 항상 최신 상태에서 시작하세요 — 새 기능에 손대기 전에 위의 동기화를 먼저 해두는 습관을 들이면 좋아요. 한참 작업한 뒤에야 원본이 크게 바뀐 걸 발견하면, 그만큼 충돌을 푸는 일이 고단해집니다. '시작 전 동기화'가 협업 스트레스를 가장 크게 줄여줍니다.

정리 — 이제 오픈소스가 두렵지 않습니다

복잡해 보였던 오픈소스 기여도, 결국 우리가 시리즈 내내 배운 조각들의 조합이었어요. 큰 흐름만 다시 짚어볼게요.

• fork & clone — 원본을 내 계정에 복제(fork)하고, 그 사본을 내 컴퓨터로 가져온다(clone). origin은 내 사본, upstream은 원본.
• branch · commit · push — 기능용 브랜치에서 작업하고 내 사본에 올린다. 원본은 늘 안전.
• Pull Request — "이 변경을 합쳐주세요" 하고 제안한다. 리뷰와 합의를 거쳐 원본에 반영된다.
• fetch · merge — upstream으로 원본의 최신 변경을 주기적으로 따라잡는다.

여기까지 오셨다면, 이제 마음에 드는 오픈소스의 오타 하나라도 고쳐 PR을 보내볼 수 있습니다. 그 작은 첫 기여가 생각보다 짜릿하더라고요. 다음 7편에서는 시리즈의 마지막으로, 실무에서 빛을 발하는 고급 스킬들(stash, rebase, tag 등)을 모아 정리하며 Git 입문 여정을 마무리하겠습니다.

Git 입문 시리즈

← 이전 글 5편. 평행 우주에서 안전하게 개발 (Branch & Conflict)

다음 글 → 7편. 프로 개발자의 마지막 퍼즐 (고급 실무 스킬)

참고 자료

• Pro Git 2판 (한국어) — GitHub 프로젝트에 기여하기
• GitHub Docs — Fork a repository
• GitHub Docs — Syncing a fork (fork 동기화)
• GitHub Docs — Creating a pull request from a fork