GitHub 협업 매뉴얼

내 컴퓨터의 Git 저장소를 인터넷에 올려 공유하고, 여러 사람이 함께 코드를 다듬는 핵심 흐름  |  공식 문서: docs.github.com

대상 Git 버전2.40 이상
GitHub 웹 UI 기준2026년 6월
문서 수집일2026년 6월 13일
대상 독자Git 기초를 익힌 입문자 (바이브코딩 수업)

명령어 트리 (Command Tree)

GitHub 협업
├── [원격 연결]
│   ├── git clone <url>          원격 저장소를 통째로 복제(이력 포함, origin 자동 설정)
│   ├── git remote -v            연결된 원격 목록과 URL 확인
│   └── git remote add origin <url>  로컬 저장소에 원격을 새로 추가
│
├── [올리고 받기]
│   ├── git push -u origin main  로컬 커밋 업로드 + 업스트림(추적 관계) 설정
│   ├── git push                 업스트림 설정 후엔 인자 없이 업로드
│   ├── git fetch                원격의 새 커밋을 내려받기만(합치지 않음)
│   └── git pull                 fetch + merge: 받아서 현재 브랜치에 합치기
│
├── [GitHub 웹에서]
│   ├── Pull Request             변경을 병합하자는 제안 → 리뷰·토론·병합
│   ├── Issues                   할 일·버그·논의를 기록
│   └── README.md                저장소 첫 화면에 표시되는 소개 문서
│
└── [인증]
    ├── HTTPS + PAT             비밀번호 대신 Personal Access Token 사용
    └── SSH 키                  ssh-keygen으로 키 생성 → 공개키를 GitHub에 등록
💡 흐름 한 줄 요약: git clone으로 받고 → 브랜치에서 작업·커밋 → git push로 올리고 → GitHub에서 Pull Request로 리뷰·병합 → git pull로 최신화. 이 한 바퀴가 협업의 기본 리듬입니다.

1. GitHub와 원격 저장소란?

💡 배경 개념: Git과 GitHub는 어떻게 다른가요?

Git은 내 컴퓨터에서 도는 '버전 관리 도구'입니다. 커밋·이력·되돌리기 같은 일은 인터넷 없이도 내 노트북 안에서 다 됩니다. GitHub는 그렇게 만든 Git 저장소를 인터넷에 올려 공유하고 협업하게 해 주는 웹 서비스입니다. 비유하자면 Git은 내 책상 위에서 쓰는 워드프로세서이고, GitHub는 그 문서를 올려 두고 동료와 같이 보는 클라우드 드라이브에 가깝습니다.

'원격 저장소(remote)'는 GitHub 같은 서버에 올라가 있는 저장소의 사본입니다. 내 컴퓨터의 저장소(로컬)와 GitHub의 저장소(원격)는 별개로 존재하며, push(올리기)와 pull(받기)로 둘을 동기화합니다. 기본 원격 이름은 관례상 origin입니다.

📌 로컬 vs 원격. 내가 git commit한 것은 일단 내 컴퓨터에만 저장됩니다. GitHub에 올라가려면 반드시 git push를 해야 합니다. 반대로 동료가 올린 변경을 내 컴퓨터로 가져오려면 git pull이 필요합니다. 커밋했다고 자동으로 공유되는 게 아니라는 점이 핵심입니다.

이 문서에서 배우는 것


2. 원격 연결 (clone · remote)

git clone <url> — 원격을 통째로 복제

GitHub에 있는 저장소를 이력까지 모두 내 컴퓨터로 복제합니다. 받은 폴더는 곧바로 Git 저장소이며, 원본을 가리키는 원격 origin이 자동으로 설정됩니다(별도 init이나 remote add 불필요).

git clone https://github.com/사용자/저장소.git
git clone https://github.com/사용자/저장소.git my-folder   # 다른 폴더명으로 받기

git remote -v — 연결된 원격 확인

현재 저장소가 어떤 원격에 연결돼 있는지, 그 URL이 무엇인지 보여줍니다. 올리기 전에 '어디로 올라가는지' 확인할 때 유용합니다.

git remote -v
# origin  https://github.com/사용자/저장소.git (fetch)
# origin  https://github.com/사용자/저장소.git (push)

git remote add origin <url> — 원격 추가

내 컴퓨터에서 git init으로 직접 시작한 저장소에는 원격이 없습니다. GitHub에 빈 저장소를 만든 뒤, 그 URL을 origin이라는 이름으로 연결합니다.

git remote add origin https://github.com/사용자/저장소.git
git remote -v          # 잘 연결됐는지 확인
상황쓰는 방법
이미 GitHub에 있는 프로젝트를 받아 시작git clone (origin 자동 설정)
내 컴퓨터에서 만든 저장소를 GitHub와 연결git remote add origin <url>

3. 올리고 받기 (push · fetch · pull)

내 컴퓨터 (로컬) 로컬 저장소 .git (내 커밋들) GitHub (원격) 원격 저장소 origin git clone — 처음 통째로 복제 git push — 올리기 git pull / fetch — 받기 fetch = 받아 두기만 · pull = 받아서 현재 브랜치에 합치기(fetch + merge)

git push — 로컬 커밋을 원격에 올리기

내 컴퓨터에 쌓인 커밋을 원격으로 업로드합니다. 처음 올릴 때는 -u origin main으로 업스트림(추적 관계)을 설정합니다. 한 번 설정해 두면, 이후로는 git push만 쳐도 같은 곳으로 올라갑니다.

git push -u origin main   # 처음 한 번: 업스트림 설정하며 올리기 (-u = --set-upstream)
git push                  # 이후엔 인자 없이 올리기
💡 업스트림이란? '내 로컬 브랜치가 원격의 어느 브랜치와 짝인지'를 기억해 두는 연결입니다. -u로 한 번 짝을 지어 두면 git push·git pull을 인자 없이 쓸 수 있어 편합니다.

git fetch — 받아 두기만(합치지 않음)

원격에 새로 올라온 커밋을 내 컴퓨터로 내려받기만 합니다. 내가 작업 중인 브랜치와는 합치지 않으므로, 무엇이 새로 들어왔는지 안전하게 먼저 확인할 때 씁니다.

git fetch            # 원격의 새 커밋을 가져오되, 작업에는 손대지 않음

git pull — 받아서 합치기 (fetch + merge)

원격의 변경을 받아 현재 브랜치에 곧바로 합칩니다. 즉 git fetchgit merge를 한 번에 하는 명령입니다. 업스트림이 설정돼 있으면 인자 없이 git pull만으로 동작합니다.

git pull             # 원격 변경을 받아 현재 브랜치에 합치기 (= fetch + merge)
명령하는 일내 작업과 합쳐지나?
git push내 로컬 커밋을 원격에 올림해당 없음 (올리기)
git fetch원격의 새 커밋을 내려받기만아니오 (확인용, 안전)
git pull원격 변경을 받아 합침 (fetch + merge)예 (현재 브랜치에 병합)

force push는 위험합니다

git push --force는 원격의 이력을 내 것으로 덮어쓰는 명령입니다. 강력한 만큼 위험합니다.

git push --force              # ⚠️ 원격 이력을 통째로 덮어씀 — 매우 위험
git push --force-with-lease   # 그나마 안전: 남이 그새 올린 게 있으면 거부
force push는 원격 이력을 덮어써 협업자의 작업을 잃게 만들 수 있습니다. 여러 사람이 함께 쓰는 공유 브랜치(예: main)에는 절대 쓰지 마세요. 꼭 필요하다면, 남이 올린 변경이 있으면 거부해 주는 --force-with-lease가 그나마 안전합니다.

4. Pull Request (PR)

Pull Request는 GitHub의 핵심 협업 기능으로, 한마디로 "내 변경을 합치자는 제안"입니다. 곧바로 합치지 않고, 병합 전에 변경 내용을 토론하고 리뷰하는 과정을 거칩니다. 그래서 실수가 본 코드에 섞이기 전에 걸러집니다.

PR의 흐름 (웹 UI 단계)

📝 base와 compare 헷갈리지 않기. base = 합쳐질 곳(목적지, 보통 main), compare/head = 내 작업(출발지). "내 작업(compare)을 main(base)에 합치자"는 방향으로 읽으면 됩니다.

Draft PR (초안)

아직 작업이 끝나지 않았지만 진행 상황을 미리 공유하고 싶을 때 Draft PR(초안)로 엽니다. Draft 상태에서는 병합할 수 없으며, 준비가 되면 'Ready for review'로 전환합니다.

병합 방식 3가지

PR을 합칠 때 GitHub은 세 가지 병합 방식을 제공합니다.

방식하는 일
Merge commit브랜치의 커밋들을 그대로 base에 병합합니다.
Squash and merge브랜치의 여러 커밋을 하나로 합쳐서 병합합니다.
Rebase and merge브랜치의 커밋들을 base 위에 재배치해 병합합니다.

5. 이슈와 README

Issues — 할 일·버그·논의 기록

Issues는 할 일, 버그 신고, 논의할 주제를 기록해 두는 GitHub 기능입니다. "로그인이 안 됨", "이 기능을 추가하자" 같은 항목을 하나씩 만들어 두면, 팀이 무엇을 해야 하는지 한곳에서 추적할 수 있습니다.

README.md — 저장소의 첫인상

README.md는 저장소 첫 화면에 표시되는 소개 문서입니다. Markdown 형식으로 작성하며, 프로젝트가 무엇인지·어떻게 설치하는지·어떻게 쓰는지를 적습니다. 저장소에 들어온 사람이 가장 먼저 읽는 문서이므로, 이것만 봐도 프로젝트를 이해할 수 있게 쓰는 것이 좋습니다.

💡 README.md는 보통 저장소 루트에 둡니다. GitHub이 자동으로 인식해 저장소 메인 페이지 아래쪽에 예쁘게 렌더링해 보여 줍니다.

6. 인증 (HTTPS · SSH · PAT)

GitHub은 보안을 위해 비밀번호 대신 토큰이나 키로 인증합니다. 접속 방식은 크게 두 가지입니다.

① HTTPS + Personal Access Token (PAT)

clone URL이 https://...로 시작하면 HTTPS 방식입니다. 이때는 계정 비밀번호 대신 Personal Access Token(PAT)을 발급받아 비밀번호 자리에 입력합니다.

git clone https://github.com/사용자/저장소.git
# 인증을 물으면 비밀번호 대신 발급받은 PAT를 입력

② SSH 키

clone URL이 git@github.com:... 형태면 SSH 방식입니다. 내 컴퓨터에서 키 쌍(개인키·공개키)을 만든 뒤, 공개키를 GitHub에 등록해 두면 매번 입력 없이 접속됩니다.

ssh-keygen                 # 키 쌍 생성
# 생성된 공개키를 GitHub Settings의 SSH keys에 등록
clone URL 형태방식인증 수단
https://github.com/...HTTPSPersonal Access Token (PAT)
git@github.com:...SSH등록한 공개키
💡 URL 앞부분만 보면 어느 방식인지 바로 압니다. https://면 HTTPS, git@github.com:면 SSH입니다.

7. 협업 워크플로우

지금까지 배운 것을 하나의 흐름으로 이으면, 입문자가 따라 할 수 있는 표준 협업 한 바퀴가 됩니다.

git clone <url> 프로젝트 받기 (또는 fork 후 clone) git switch -c feature/x 작업용 브랜치 만들기 작업 → git commit 변경을 커밋으로 기록 git push -u origin feature/x 내 브랜치를 GitHub에 올리기 GitHub: Pull Request 열기 리뷰·토론 받기 GitHub: 병합 (Merge) base 브랜치에 합치기 git switch main 로컬에서 메인 브랜치로 이동 git pull 합쳐진 최신 내용으로 로컬 최신화 내 컴퓨터(로컬) GitHub 웹 로컬
git clone https://github.com/사용자/저장소.git
git switch -c feature/login        # 작업 브랜치 생성·이동
# ... 작업 후 ...
git commit -m "로그인 폼 추가"
git push -u origin feature/login   # 내 브랜치 올리기
# GitHub에서 Pull Request 열기 → 리뷰 → 병합
git switch main                    # 메인으로 이동
git pull                           # 병합된 최신 상태로 갱신
📌 왜 브랜치에서 작업하나요? main에 바로 커밋하지 않고 feature/x 브랜치에서 작업하면, 내 변경이 리뷰·병합되기 전까지 본 코드를 건드리지 않습니다. 여러 사람이 각자 브랜치에서 일하다 PR로 안전하게 합치는 것이 협업의 기본입니다.

참고 링크


Git 2.40+ · GitHub 웹 UI 2026년 6월 기준 · 한국어 교육 자료 · 문서 수집일 2026년 6월 13일
공식 문서: docs.github.com