GitHub 협업 실습 예시

로컬 저장소를 GitHub와 연결해 함께 일하는 흐름(push → PR → pull)을 시나리오로 익히는 가이드  |  ← 매뉴얼로 돌아가기

대상 환경Git 2.40 이상 · GitHub 웹 UI 2026년 6월 기준
이 파일의 목적매뉴얼을 보완하는 실습·교육용 시나리오 예시집
매뉴얼 문서GitHub_Manual.html — 각 시나리오에서 링크로 연결됩니다
작성일2026년 6월 13일
● 초급 GitHub와 연결하기 로컬 저장소를 원격(GitHub)에 올리고, 받아오고, 변경을 다시 올리는 기본 흐름
G-1 초급 로컬 프로젝트를 GitHub에 처음 올리기
내 컴퓨터에서 커밋까지 마친 프로젝트(my-site)가 있습니다. 이제 이걸 GitHub에 올려 백업하고 공유하려 합니다. 전제: 로컬에서 git init·커밋을 이미 한 상태이고, GitHub 계정이 있습니다.
단계별 실행
  1. GitHub 웹에서 빈 저장소 만들기

    오른쪽 위 +New repository를 누릅니다. 이름을 적고, README·.gitignore·license는 체크하지 않은 채(빈 상태로) Create repository를 누릅니다. 다음 화면에 나오는 저장소 URL을 복사합니다.

  2. 로컬에 원격 연결하기

    복사한 URL을 origin이라는 이름으로 등록합니다.

  3. 연결 확인

    git remote -v로 origin이 제대로 잡혔는지 봅니다.

  4. 첫 push로 업로드

    -u를 붙여 업스트림까지 설정합니다.

git remote add origin https://github.com/내계정/my-site.git
git remote -v                   # origin이 등록됐는지 확인
git push -u origin main         # 로컬 main을 원격 origin에 올림
로컬 커밋이 통째로 GitHub로 올라가고, origin/main이 만들어집니다. -u(=--set-upstream)는 "앞으로 이 브랜치는 origin/main과 짝"이라고 기록해 둡니다. 그래서 다음부터는 git push만 쳐도 같은 곳으로 올라갑니다.
원격의 기본 이름은 관례상 origin입니다. clone한 저장소는 이 이름이 자동으로 잡히지만, 직접 올릴 때는 G-1처럼 한 번 등록해 줘야 합니다.
G-2 초급 남의 저장소를 clone 해서 받기
동료가 만든 프로젝트, 혹은 참고하려는 오픈소스를 통째로 내 컴퓨터로 받아 와서 직접 실행해 보려 합니다. 전제: 받을 저장소의 URL을 알고 있습니다(GitHub 저장소 페이지의 초록색 Code 버튼에서 복사).
사용 명령어
단계별 실행
  1. 받을 위치로 이동

    프로젝트들을 모아 두는 폴더로 갑니다.

  2. clone으로 통째로 복제

    URL 뒤의 이름으로 폴더가 새로 생깁니다.

  3. 들어가서 origin 확인

    clone은 원격을 origin으로 자동 등록합니다.

cd ~/projects
git clone https://github.com/someone/cool-app.git
cd cool-app
git remote -v                   # origin이 자동으로 잡혀 있음
clone은 전체 커밋 이력까지 그대로 복제하고, 받아 온 곳을 origin으로 자동 연결합니다. 그래서 G-1처럼 remote add를 따로 할 필요가 없습니다. 바로 git pull로 최신 변경을 받거나, 작업 후 push할 수 있습니다.
URL 뒤에 폴더 이름을 덧붙이면 그 이름으로 받습니다: git clone <url> my-folder. 같은 이름 폴더가 이미 있으면 clone이 거부되니, 다른 이름을 주거나 빈 위치에서 실행하세요.
G-3 초급 변경을 push로 올리기
G-1에서 프로젝트를 GitHub에 올린 뒤, 코드를 더 고쳐 커밋했습니다. 이 새 커밋을 GitHub에도 반영하려 합니다. 전제: 이미 -u로 한 번 push해 업스트림이 설정돼 있습니다.
사용 명령어
단계별 실행
  1. 변경을 로컬에 커밋

    먼저 로컬에 기록해야 올릴 거리가 생깁니다.

  2. push로 원격에 반영

    업스트림이 설정돼 있으니 git push만으로 충분합니다.

  3. GitHub 웹에서 확인

    저장소 페이지를 새로고침하면 방금 커밋이 보입니다.

git add index.html
git commit -m "메인 페이지 배너 문구 수정"
git push                        # 업스트림 설정돼 있으면 이거면 끝
push로컬에 쌓인 커밋을 원격으로 올릴 뿐입니다. 커밋하지 않은 변경은 올라가지 않으니, 항상 "add → commit → push" 순서를 기억하세요.
"rejected (non-fast-forward)"라고 거부되면, 원격에 내가 아직 안 받은 커밋이 있다는 뜻입니다. 이럴 땐 --force로 덮지 말고 먼저 git pull로 받아 합친 뒤 다시 push하세요(D-2 참고).
● 중급 브랜치로 협업하기 기능별 브랜치를 올려 Pull Request로 제안하고, 원격 변경을 받아 동기화하는 단계
D-1 중급 브랜치 push 하고 Pull Request 열기
팀 저장소에서 새 기능(로그인)을 맡았습니다. main에 직접 올리지 않고, 기능 브랜치에서 작업한 뒤 Pull Request(PR)로 검토를 요청하려 합니다. 전제: 저장소를 clone했거나 이미 origin이 연결돼 있습니다.
단계별 실행
  1. 기능 브랜치 만들고 이동

    switch -c로 새 브랜치를 만들면서 그쪽으로 옮겨 갑니다.

  2. 작업하고 커밋

    로그인 관련 변경을 이 브랜치에 쌓습니다.

  3. 브랜치를 원격에 push

    새 브랜치라 -u로 업스트림을 잡아 줍니다.

  4. GitHub 웹에서 PR 열기

    push 직후 저장소 페이지를 열면 노란 알림과 함께 Compare & pull request 버튼이 보입니다. 누른 뒤 base(합쳐질 대상, 보통 main)와 compare(내 브랜치)가 맞는지 확인합니다. 제목과 설명을 적고 Create pull request를 누릅니다.

git switch -c feature/login
# ... 로그인 기능 작업 ...
git add .
git commit -m "로그인 폼·세션 처리 추가"
git push -u origin feature/login
PR은 "내 브랜치(compare)의 변경을 base 브랜치에 합쳐 달라"는 제안서입니다. 만들면 동료가 변경 내용을 줄 단위로 보고 댓글·리뷰를 달 수 있습니다. 합의되면 GitHub 웹의 Merge 버튼으로 base에 병합합니다.
아직 작업 중이라 "리뷰는 아니고 진행 상황만 공유"하고 싶다면 PR 생성 시 Create draft pull request를 고르세요. Draft PR은 병합 버튼이 잠겨 있어 실수로 합쳐지지 않습니다. 준비되면 Ready for review로 전환합니다.
D-2 중급 pull로 원격 변경 받아오기
동료가 그사이 main에 커밋을 올렸습니다. 내 컴퓨터의 main을 최신 상태로 맞춘 뒤 이어서 작업하려 합니다. 전제: 내 로컬에 아직 커밋하지 않은 변경은 없습니다(깨끗한 상태).
사용 명령어
단계별 실행
  1. (원하면) 먼저 fetch로 받아만 두기

    fetch는 원격 변경을 가져만 오고 내 브랜치엔 합치지 않습니다. 무엇이 새로 왔는지 먼저 보고 싶을 때 씁니다.

  2. pull로 받아서 합치기

    pull은 fetch + merge입니다. 받은 변경을 현재 브랜치에 바로 합칩니다.

  3. 최신인지 확인

    log로 동료의 커밋이 들어왔는지 봅니다.

git fetch origin                # 받아만 둠(합치지 않음)
git log origin/main --oneline   # 새로 온 커밋 미리 보기
git pull                        # 받아서 현재 브랜치에 합침
git log --oneline -5
fetch는 "원격 상태만 내려받기", pull은 "내려받아 내 브랜치에 합치기"입니다. pull = fetch + merge라고 기억하면 됩니다. 충돌 없이 합쳐지면 동료의 커밋이 그대로 내 이력에 들어옵니다.
작업 시작 전에 습관적으로 git pull을 한 번 돌리면, 오래된 코드 위에 작업하다 나중에 충돌이 커지는 일을 줄일 수 있습니다.
D-3 중급 README 추가하기
GitHub에 올린 저장소 첫 화면이 비어 있습니다. 프로젝트가 무엇이고 어떻게 실행하는지 알려 주는 README.md를 추가해 첫인상을 만들려 합니다. 전제: 저장소가 이미 GitHub에 연결돼 있습니다.
사용 명령어
단계별 실행
  1. 저장소 루트에 README.md 작성

    제목·소개·실행법을 Markdown으로 적습니다.

  2. 커밋하고 push

    로컬에 기록한 뒤 원격에 올립니다.

  3. GitHub에서 확인

    저장소 첫 화면 아래에 README 내용이 렌더링돼 보입니다.

printf "# my-site\n\n바이브코딩으로 만든 간단한 소개 페이지.\n\n## 실행\n브라우저로 index.html 열기\n" > README.md
git add README.md
git commit -m "README 추가: 프로젝트 소개·실행법"
git push
README.md는 Markdown으로 쓴 소개 문서입니다. GitHub는 저장소 첫 화면에 이 파일을 자동으로 예쁘게 표시해 줍니다. 방문자가 가장 먼저 보는 얼굴이라 짧고 명확하게 쓰는 게 좋습니다.
파일을 직접 만들기 번거롭다면 GitHub 웹에서 Add a README 버튼으로 브라우저에서 바로 작성·커밋할 수도 있습니다. 이 경우 로컬에는 git pull로 받아 오면 됩니다.
● 고급 병합과 충돌 다루기 PR을 병합하고 브랜치를 정리하며, 협업 중 생기는 충돌을 안전하게 해결
P-1 고급 PR 리뷰 받고 병합 후 정리
D-1에서 연 PR이 리뷰를 통과했습니다. 이제 main에 병합하고, 역할을 다한 기능 브랜치를 원격·로컬 모두에서 깔끔히 정리하려 합니다. 전제: PR이 열려 있고 리뷰어의 승인을 받았습니다.
단계별 실행
  1. GitHub 웹에서 병합

    PR 페이지 아래의 Merge pull requestConfirm merge를 누릅니다. 그러면 내 브랜치 변경이 base(main)에 합쳐집니다.

  2. 원격 브랜치 삭제

    병합 직후 나타나는 Delete branch 버튼으로 더 이상 필요 없는 원격 기능 브랜치를 지웁니다.

  3. 로컬을 최신 main으로 맞추기

    main으로 옮긴 뒤 pull로 방금 병합된 내용을 받습니다.

  4. 로컬 기능 브랜치 삭제

    병합이 끝났으니 로컬에서도 지웁니다.

git switch main
git pull                        # 방금 병합된 변경을 로컬 main에 반영
git branch -d feature/login     # 다 쓴 로컬 브랜치 정리
병합이 끝난 기능 브랜치는 역할을 다했습니다. 원격은 GitHub 웹의 Delete branch로, 로컬은 git branch -d로 지우면 저장소가 깔끔하게 유지됩니다. -d는 "이미 병합된 브랜치만" 지우므로, 안 합쳐진 작업을 실수로 날릴 위험이 적습니다.
git branch -d가 "병합되지 않았다"며 거부하면, 정말 그 브랜치가 main에 합쳐졌는지 다시 확인하세요. 확실히 버려도 되는 경우에만 대문자 -D로 강제 삭제합니다.
P-2 고급 협업 중 충돌나는 pull 해결
git pull을 했더니 "CONFLICT"가 떴습니다. 나와 동료가 같은 파일의 같은 부분을 각자 다르게 고친 탓입니다. 충돌을 직접 풀어 합치려 합니다. 전제: 내 로컬에 커밋한 변경이 있고, 원격에도 겹치는 변경이 들어와 있습니다.
단계별 실행
  1. 충돌 파일 확인

    status가 "both modified"로 충돌한 파일을 알려 줍니다.

  2. 충돌 마커를 찾아 직접 정리

    편집기로 파일을 열면 <<<<<<< / ======= / >>>>>>> 마커가 보입니다. 위는 내 변경, 아래는 원격 변경입니다. 원하는 최종 모습으로 코드를 고치고 세 마커 줄을 모두 삭제합니다.

  3. 해결한 파일을 add

    add는 "이 파일 충돌을 해결했다"는 표시입니다.

  4. commit으로 병합 마무리

    커밋하면 합치기가 완료됩니다.

git pull                        # 여기서 CONFLICT 발생
git status                      # both modified: app.js 확인
# 편집기로 app.js 열어 마커(<<<<<<< ======= >>>>>>>) 정리·삭제
git add app.js
git commit -m "main 변경과 충돌 해결 (로그인 검증 통합)"
충돌은 Git이 "두 변경 중 무엇을 살릴지 자동으로 못 정하겠다"고 사람에게 넘기는 상태입니다. 마커 사이에서 어느 쪽을 남길지(혹은 둘을 섞을지) 직접 정하고, 마커를 지운 뒤 add → commit하면 병합이 끝납니다.
충돌이 무섭다고 git push --force로 원격을 덮지 마세요. 공유 브랜치에서 force push는 동료가 올린 커밋을 통째로 날릴 수 있습니다. 충돌은 위처럼 pull로 받아 합쳐서 푸는 것이 안전합니다.

Git 2.40+ · GitHub 웹 UI 2026년 6월 기준 · 2026년 6월 13일 작성
← GitHub 매뉴얼  |  되돌리기 실습 →