권한이 없어도 기여할 수 있는 방법
다른 사람의 GitHub 저장소를 보면 직접 수정해서 올리고 싶을 때가 있습니다. 하지만 보통은 권한이 없습니다. 권한이 없는 저장소에는 push할 수 없습니다.
이때 사용하는 기능이 Fork입니다.
Fork는 원본 저장소를 내 GitHub 계정으로 복사하는 기능입니다. 원본 프로젝트를 그대로 가져오지만, 복사본의 주인은 내가 됩니다. 그래서 내 Fork 저장소에는 자유롭게 브랜치를 만들고, 커밋하고, push할 수 있습니다.
정리하면 흐름은 이렇습니다.
다른 사람의 저장소를 내 계정으로 Fork한다.
내 Fork 저장소를 로컬 컴퓨터로 clone한다.
새 브랜치를 만들고 수정한다.
내 Fork 저장소로 push한다.
원본 저장소에 Pull Request를 보낸다.
즉, Fork는 권한이 없는 프로젝트에 안전하게 참여하기 위한 중간 공간입니다. 원본 저장소를 바로 건드리지 않고, 내 복사본에서 작업한 뒤 원본 프로젝트 관리자에게 검토를 요청하는 방식입니다.

Fork와 Clone은 다릅니다
초보자가 자주 헷갈리는 부분이 있습니다. Fork와 clone은 비슷해 보이지만 역할이 다릅니다.
Fork: GitHub 안에서 원본 저장소를 내 계정으로 복사하는 것
Clone: GitHub에 있는 저장소를 내 컴퓨터로 내려받는 것
예를 들어 octo/example-project라는 오픈소스 저장소가 있다고 해보겠습니다. 이 저장소를 Fork하면 내 계정에 다음과 같은 저장소가 생깁니다.
myname/example-project이제 이 저장소는 내 계정에 있으므로 내가 push할 수 있습니다. 하지만 아직 내 컴퓨터에는 파일이 없습니다. 그래서 clone을 해야 합니다.
git clone https://github.com/myname/example-project.git
cd example-projectFork는 GitHub에서 복사하는 일이고, clone은 내 컴퓨터로 가져오는 일입니다. 이 차이를 이해하면 오픈소스 기여 흐름이 훨씬 쉬워집니다.
내 Fork 저장소에서 작업하기
저장소를 clone했다면 먼저 원격 저장소가 어떻게 연결되어 있는지 확인합니다.
git remote -v보통 다음처럼 나옵니다.
origin https://github.com/myname/example-project.git (fetch)
origin https://github.com/myname/example-project.git (push)여기서 origin은 내 Fork 저장소를 뜻합니다. 즉, 내가 push할 수 있는 저장소입니다.
이제 작업용 브랜치를 만듭니다. 원본의 main 브랜치에서 바로 작업하지 말고, 목적이 드러나는 이름으로 새 브랜치를 만드는 것이 좋습니다.
git switch -c fix-readme-typo브랜치 이름은 너무 길 필요는 없지만, 무엇을 수정하는지 알 수 있어야 합니다.
좋은 예시는 다음과 같습니다.
fix-readme-typo
update-install-guide
add-login-test
improve-error-message이제 파일을 수정하고 커밋합니다.
git status
git add README.md
git commit -m "Fix typo in README"커밋 메시지는 간단하되, 무엇을 바꿨는지 보여주면 됩니다. 오픈소스 프로젝트에서는 관리자가 많은 Pull Request를 확인하기 때문에, 커밋 메시지와 PR 제목이 명확할수록 좋습니다.
그다음 내 Fork 저장소로 push합니다.
git push -u origin fix-readme-typo여기서 중요한 점은 origin이 원본 저장소가 아니라 내 Fork 저장소라는 것입니다. 원본 저장소에 직접 push하는 것이 아닙니다.
upstream으로 원본 저장소 연결하기
Fork한 저장소로 작업하다 보면 시간이 지나면서 원본 프로젝트가 계속 업데이트됩니다. 다른 사람들이 새 기능을 추가하거나 버그를 고칠 수 있습니다.
내 Fork 저장소는 처음 Fork한 시점의 복사본입니다. 그래서 원본 프로젝트의 최신 변경 사항을 가져오려면 원본 저장소를 별도로 연결해야 합니다. 이때 보통 이름을 upstream이라고 합니다.
git remote add upstream https://github.com/octo/example-project.git다시 원격 저장소 목록을 확인합니다.
git remote -v이제 다음과 비슷하게 보입니다.
origin https://github.com/myname/example-project.git (fetch)
origin https://github.com/myname/example-project.git (push)
upstream https://github.com/octo/example-project.git (fetch)
upstream https://github.com/octo/example-project.git (push)이름의 의미는 이렇게 기억하면 됩니다.
origin: 내 Fork 저장소upstream: 원본 저장소
원본 저장소가 원격 목록에 보인다고 해서 내가 원본에 push할 수 있다는 뜻은 아닙니다. 권한이 없다면 원본 저장소로 push는 거절됩니다. 보통 우리는 upstream에서는 최신 내용을 가져오고, origin에는 내 작업을 올립니다.
원본 프로젝트의 최신 변경 사항을 가져오려면 다음 명령어를 사용합니다.
git fetch upstream그리고 내 main 브랜치에 원본의 최신 내용을 반영합니다.
git switch main
git merge upstream/main또는 프로젝트 정책에 따라 rebase를 사용하기도 합니다.
git switch main
git rebase upstream/main초보자라면 처음에는 merge가 더 이해하기 쉽습니다. 중요한 것은 작업을 시작하기 전에 원본 저장소의 최신 상태를 가져오는 습관입니다. 그래야 충돌 가능성이 줄어들고, 관리자가 PR을 검토하기도 편합니다.
내 로컬 main을 최신으로 맞춘 뒤, 내 Fork의 main도 GitHub에서 최신으로 보이게 하려면 다음처럼 push할 수 있습니다.
git push origin main이 작업은 필수는 아니지만, 내 Fork 저장소의 main도 원본과 비슷한 상태로 유지하고 싶을 때 유용합니다. 단, 기여 작업은 보통 main이 아니라 별도 작업 브랜치에서 진행합니다.
기여하기 전에 먼저 읽어야 할 것들
오픈소스 프로젝트에 기여할 때는 바로 코드를 수정하기보다 먼저 프로젝트의 규칙을 확인해야 합니다. 프로젝트마다 원하는 방식이 다릅니다.
먼저 README.md를 읽습니다. README에는 프로젝트 소개, 설치 방법, 실행 방법, 기본 사용법이 들어 있습니다. 작은 문서 수정이라도 프로젝트가 무엇을 하는지 알고 수정해야 합니다.
그다음 CONTRIBUTING.md 파일이 있는지 확인합니다. 이 파일은 기여자를 위한 안내문입니다. 보통 다음 내용이 들어 있습니다.
개발 환경 설정 방법
브랜치 이름 규칙
커밋 메시지 규칙
테스트 실행 방법
PR 작성 방법
코드 스타일 규칙
또한 Issue 목록도 확인해야 합니다. 이미 누군가 같은 문제를 제기했거나 작업 중일 수 있습니다. 중복 작업을 피하려면 관련 Issue가 있는지 먼저 검색하는 것이 좋습니다.
PR 템플릿도 중요합니다. Pull Request를 만들 때 자동으로 표시되는 양식이 있다면 빈칸을 성실히 채워야 합니다. 관리자는 그 내용을 보고 변경 이유, 테스트 여부, 관련 Issue를 빠르게 파악합니다.
오픈소스 기여는 단순히 코드를 올리는 일이 아닙니다. 프로젝트의 규칙을 존중하고, 관리자가 검토하기 쉬운 형태로 제안하는 과정입니다.
실전 예시: README 오타 수정 PR 보내기
가장 작은 오픈소스 기여는 문서 오타 수정입니다. 코드 변경보다 부담이 적고, Fork 흐름을 연습하기 좋습니다.
상황을 가정해보겠습니다. 원본 저장소 octo/example-project의 README에서 다음 문장을 발견했습니다.
This projet helps you learn GitHub.여기서 projet은 project의 오타입니다. 이 오타를 고쳐 PR을 보내겠습니다.
먼저 GitHub에서 원본 저장소에 들어가 Fork 버튼을 누릅니다. 그러면 내 계정에 myname/example-project 저장소가 생깁니다.
이제 내 Fork 저장소를 clone합니다.
git clone https://github.com/myname/example-project.git
cd example-project원본 저장소도 upstream으로 연결합니다.
git remote add upstream https://github.com/octo/example-project.git
git fetch upstream작업 전 main을 최신 상태로 맞춥니다.
git switch main
git merge upstream/main필요하다면 내 Fork의 main도 업데이트합니다.
git push origin main오타 수정용 브랜치를 만듭니다.
git switch -c fix-readme-typoREADME.md 파일을 열어 오타를 고칩니다.
This project helps you learn GitHub.변경 사항을 확인합니다.
git diff문제가 없다면 커밋합니다.
git add README.md
git commit -m "Fix typo in README"내 Fork 저장소로 push합니다.
git push -u origin fix-readme-typo이제 GitHub에서 내 Fork 저장소로 이동하면 Pull Request를 만들 수 있는 버튼이 보입니다. PR을 만들 때는 방향을 잘 확인해야 합니다.
base repository:
octo/example-projectbase branch:
mainhead repository:
myname/example-projectcompare branch:
fix-readme-typo
PR 제목은 간단히 씁니다.
Fix typo in README본문에는 변경 이유를 짧게 적습니다.
## 변경 내용
- README의 오타를 수정했습니다.
## 확인한 내용
- 문장 의미가 자연스럽게 유지되는지 확인했습니다.문서 오타 수정처럼 작은 기여라도 이렇게 명확히 작성하면 좋습니다. 관리자가 무엇을 바꿨는지 바로 이해할 수 있기 때문입니다.
PR을 보낸 뒤 해야 할 일
Pull Request를 보냈다고 끝은 아닙니다. 관리자가 댓글을 남길 수 있습니다. 예를 들어 문장 표현을 조금 다르게 바꿔달라고 요청할 수 있습니다.
이때 새 PR을 다시 만들 필요는 없습니다. 같은 브랜치에서 수정하고 다시 push하면 기존 PR에 자동으로 추가됩니다.
git switch fix-readme-typo
# 파일 수정
git add README.md
git commit -m "Update README wording"
git pushGitHub는 같은 브랜치에 push된 새 커밋을 기존 PR에 이어서 보여줍니다.
만약 원본 저장소의 main 브랜치가 그사이에 업데이트되었다면, 최신 변경 사항을 다시 가져와야 할 수 있습니다.
git fetch upstream
git switch main
git merge upstream/main
git switch fix-readme-typo
git merge main이 흐름은 원본의 최신 main을 내 로컬 main에 반영한 뒤, 다시 작업 브랜치에 합치는 방식입니다. 팀이나 프로젝트가 rebase를 선호한다면 git merge main 대신 rebase를 사용할 수도 있지만, 처음에는 merge로 이해해도 충분합니다.
충돌이 나면 이전 장에서 배운 것처럼 충돌 파일을 열어 정리한 뒤 커밋하면 됩니다.
Fork 기여 흐름 요약
Fork를 사용하면 권한이 없는 저장소에도 안전하게 기여할 수 있습니다. 핵심은 원본 저장소를 직접 수정하지 않고, 내 계정의 복사본에서 작업한 뒤 Pull Request로 제안하는 것입니다.
가장 기본 흐름은 다음과 같습니다.
# 1. 내 Fork 저장소 clone
git clone https://github.com/myname/example-project.git
cd example-project
# 2. 원본 저장소 upstream 연결
git remote add upstream https://github.com/octo/example-project.git
# 3. 원본 최신 내용 가져오기
git fetch upstream
git switch main
git merge upstream/main
# 4. 작업 브랜치 생성
git switch -c fix-readme-typo
# 5. 수정 후 커밋
git add README.md
git commit -m "Fix typo in README"
# 6. 내 Fork 저장소로 push
git push -u origin fix-readme-typo이후 GitHub에서 원본 저장소로 Pull Request를 만들면 됩니다.
처음부터 큰 기능을 추가하려고 하지 않아도 됩니다. 오타 수정, 설명 보완, 예제 코드 개선처럼 작은 기여부터 시작하면 충분합니다. 중요한 것은 프로젝트의 규칙을 읽고, 작은 변경을 명확하게 제안하는 습관입니다. Fork 흐름을 익히면 GitHub는 단순한 개인 저장 공간을 넘어, 전 세계 개발자와 함께 협업하는 도구가 됩니다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.
