공동작업 대백과

도키피디아 v1.0

Working Together

혼자 만들 때는
몰라도 됩니다.
같이 만들면 다릅니다.

혼자 쓸 때 깃허브는 그냥 백업이었습니다. 고치고, 저장하고, 올리면 끝이었습니다. 그런데 옆 반 선생님이 같은 파일을 동시에 고치기 시작하면 이야기가 달라집니다. 누가 먼저 올리느냐에 따라 누군가의 작업이 사라질 수 있기 때문입니다.

기준일 2026-09-02 · 깃허브 공식 문서 기준 · 처음 하는 분을 위해

00 — Before You Read

혼자 쓸 때와 무엇이 다른가

한 줄로 말하면 혼자일 때는 저장이 문제였지만, 여럿일 때는 순서가 문제입니다.

학년 자료를 공유 폴더에 두고 여럿이 고쳐 본 적 있으실 겁니다. 그때 무슨 일이 벌어졌는지 떠올려 보세요. 누군가 파일을 열어 둔 채 퇴근하고 다른 사람이 최종_최종_진짜최종.hwp를 만들고, 결국 누구 것이 최신인지 아무도 모르게 됩니다.

깃허브를 여럿이 쓸 때 배우는 것은 전부 이 문제를 막는 장치입니다. 브랜치는 남의 작업을 건드리지 않고 내 것만 고치는 방법이고, PR은 반영하기 전에 한 번 보자는 약속이며, 충돌은 두 사람이 같은 칸을 다르게 고쳤을 때 컴퓨터가 사람에게 물어보는 순간입니다.

혼자 쓸 때
  • 브랜치를 안 나눠도 큰일이 없습니다
  • 바로 main에 올려도 괜찮습니다
  • 충돌이 날 일이 거의 없습니다
  • 깃허브는 사실상 백업입니다
같이 쓸 때
  • 브랜치를 안 나누면 남의 작업 위에 덮어씁니다
  • main은 항상 작동하는 판으로 지켜야 합니다
  • 충돌은 사고가 아니라 정상 절차입니다
  • 깃허브가 회의록이자 결재판이 됩니다

이 문서와 깃허브 대백과의 분담

깃허브 대백과는 혼자 쓰는 사람을 위한 문서입니다. 가입, 저장소 만들기, 커밋과 푸시, 그리고 AI가 코드를 망쳤을 때 되돌리는 법이 거기 있습니다. 그 내용을 먼저 보고 오시는 편이 좋습니다.

이 문서는 그다음입니다. 사람이 둘 이상일 때만 필요한 것을 담았습니다.

이 문서가 답하는 것 ① 브랜치·PR·머지가 각각 무슨 일을 하는가 ② 동료와 한 저장소를 쓰면 하루가 어떻게 흘러가는가 ③ 충돌이 났을 때 무엇을 해야 하는가 ④ 권한을 어떻게 나눠야 사고가 안 나는가 ⑤ 쓰기 권한이 없는 사람은 어떻게 기여하는가.
읽는 법 08장 워크트리는 건너뛰어도 됩니다. 처음 하는 분에게는 필요 없는 기능이고 나중에 필요해질 때 돌아오면 됩니다. 나머지 장은 앞에서부터 순서대로 읽도록 짰습니다.

01 — Words

용어 대조표

한 줄로 말하면 낯선 말이 열 개쯤 나오는데, 하는 일은 학교에서 이미 해 보신 것과 거의 같습니다.

외우지 않아도 됩니다. AI가 이 말을 꺼냈을 때 무슨 뜻인지 알아듣기만 하면 됩니다. 가운데 칸은 이해를 돕는 비유이고 오른쪽 칸이 실제로 일어나는 일입니다. 비유만 읽고 넘어가면 나중에 막힙니다.

전문용어영문학교로 치면실제로 일어나는 일
저장소repository 학년 공유 폴더 하나 파일과 모든 수정 이력이 함께 담긴 묶음
클론clone 공유 폴더를 내 컴퓨터로 통째로 받아오기 저장소 전체를 이력까지 복사해 내 컴퓨터에 폴더로 만듦
커밋commit 고친 유인물에 날짜와 메모를 붙여 저장 지금 상태를 이력에 한 칸 새김. 아직 내 컴퓨터 안
푸시push 공유 폴더에 올리기 내 컴퓨터의 커밋을 깃허브로 보냄. 이때부터 남이 봄
풀pull 공유 폴더에서 최신본 내려받기 깃허브에 쌓인 남의 커밋을 내 컴퓨터로 가져와 합침
브랜치branch 원본은 그대로 두고 3반용 수정본을 따로 떠서 고치기 같은 저장소 안에 독립된 작업 줄기를 하나 더 만듦
PRpull request 고친 수정본을 원본에 반영해도 되는지 동료에게 확인 요청 브랜치를 main에 합쳐 달라는 요청. 무엇이 바뀌는지 줄 단위로 보여줌
리뷰review 동료가 읽고 의견 달기 PR에 코멘트·승인·변경 요청 중 하나를 남김
머지merge 확인받은 수정본을 원본에 반영 브랜치의 변경을 main에 실제로 합침
충돌conflict 두 사람이 같은 칸을 다르게 고쳐 와 어느 쪽을 쓸지 정해야 하는 상황 깃이 자동 병합을 포기하고 사람의 판단을 기다림
포크fork 권한 없는 남의 자료를 내 계정으로 복사해 고친 뒤 제안 남의 저장소를 내 계정 아래 통째로 복제
워크트리worktree 같은 문서의 여러 판을 창 여러 개로 동시에 열어 두기 저장소 하나를 폴더 여러 개로 펼쳐 브랜치를 동시에 열어 둠

← 옆으로 밀 수 있습니다

세 곳이 있습니다

공동작업이 헷갈리는 진짜 이유는 용어가 어려워서가 아니라, 파일이 놓인 자리가 셋이기 때문입니다. 내 컴퓨터, 깃허브, 그리고 동료의 컴퓨터입니다. 이 셋이 저절로 같아지지 않습니다.

내 컴퓨터와 깃허브와 동료 컴퓨터 사이에서 푸시와 풀이 오가는 그림 내 컴퓨터 고치고 커밋합니다 여기까지는 나만 봅니다 깃허브 저장소 origin 모두가 보는 곳 main이 여기 있습니다 PR도 여기서 오갑니다 동료 컴퓨터 각자 클론해 둡니다 따로 고칩니다 푸시 클론·풀 풀 푸시 커밋은 내 컴퓨터 안의 일입니다. 푸시를 해야 비로소 동료가 볼 수 있습니다.
origin과 upstream origin은 내가 클론해 온 저장소를 가리키는 이름입니다. 대개 동호회 공용 저장소가 여기입니다.
upstream은 포크를 떴을 때 원본을 가리키는 이름입니다. 07장에서만 나옵니다. 쓰기 권한이 있는 저장소를 쓴다면 origin 하나만 알면 됩니다.

02 — One Full Cycle

한 바퀴 돌려보기

한 줄로 말하면 브랜치 → 커밋 → 푸시 → PR → 리뷰 → 머지 → 풀. 이 일곱 걸음이 전부이고 나머지 장은 이 걸음을 하나씩 뜯어 봅니다.

타이머 소리가 안 난다는 제보를 받아 고친다고 해봅시다. 아래 그림에서 나와 동료가 각각 무엇을 하는지, 그리고 main이 언제 바뀌는지를 함께 보세요.

브랜치부터 풀까지 공동작업 일곱 단계가 나·동료·main 세 줄을 오가는 그림 main 나 동료 1 브랜치를 만듭니다 2 고치고 커밋합니다 3 깃허브로 푸시합니다 4 PR을 엽니다 5 동료가 리뷰합니다 6 main에 머지됩니다 7 동료도 풀합니다

일곱 걸음을 말로 풀면

  1. 브랜치를 만듭니다

    원본은 그대로 두고 timer-fix라는 이름의 작업 줄기를 하나 냅니다. 이 순간부터 내가 무엇을 고치든 main은 멀쩡합니다.

  2. 고치고 커밋합니다

    몇 번을 커밋해도 괜찮습니다. 아직 내 컴퓨터 안이라 아무도 안 봅니다.

  3. 깃허브로 푸시합니다

    여기서 처음으로 동료가 볼 수 있게 됩니다. 다만 main이 아니라 내 브랜치에 올라갑니다.

  4. PR을 엽니다

    "이 브랜치를 main에 합쳐도 될까요?"라는 요청입니다. 무엇이 어떻게 바뀌는지 줄 단위로 보이니, 동료는 이것만 보면 됩니다.

  5. 동료가 리뷰합니다

    읽어 보고 셋 중 하나를 남깁니다. 그냥 의견만 남기거나, 좋다고 승인하거나, 고쳐 오라고 합니다.

  6. 머지합니다

    승인이 나면 합칩니다. 이때 비로소 main이 바뀝니다. 합친 브랜치는 지웁니다.

  7. 동료도 풀합니다

    동료의 컴퓨터는 아직 옛날 판입니다. 풀을 받아야 최신이 됩니다. 이 마지막 걸음을 빼먹어서 생기는 사고가 제일 많습니다.

이렇게 말하세요

main은 건드리지 말고 timer-fix라는 작업 브랜치를 새로 만들어서 거기서 작업해줘. 다 되면 깃허브에 올리고, 무엇을 왜 고쳤는지 설명을 붙여서 PR까지 만들어줘.

터미널로 직접 한다면
# 1~2단계 $ git switch -c timer-fix $ git commit -am "타이머 소리 안 나는 문제 수정" # 3~4단계 $ git push -u origin timer-fix $ gh pr create --fill # 6~7단계 (머지는 깃허브 화면에서 눌러도 됩니다) $ git switch main && git pull $ git branch -d timer-fix
순서가 헷갈릴 때 기준 하나 main에서 직접 고치기 시작했다면 이미 틀렸습니다. 무엇을 하든 브랜치를 먼저 만드세요. 이 습관 하나로 공동작업 사고의 절반이 사라집니다.

03 — Branch

브랜치

한 줄로 말하면 원본 유인물은 그대로 두고 수정본을 따로 떠서 고치는 것입니다. 다 고친 뒤에 원본에 반영합니다.

브랜치 branch는 같은 저장소 안에 독립된 작업 줄기를 하나 더 만드는 기능입니다. 학년 자료 원본은 건드리지 않고 "3반용"이라는 사본을 떠서 고치는 것과 같습니다. 실제로는 파일을 복사하는 게 아니라 이력의 갈래를 하나 더 내는 것이라, 용량도 거의 늘지 않고 오갈 때도 즉시 바뀝니다.

main에서 작업 브랜치가 갈라져 나왔다가 다시 합쳐지는 그림 main timer-fix 여기서 갈라집니다 여기서 합쳐집니다 갈라져 있는 동안 main은 계속 멀쩡합니다. 동료는 아무 영향을 받지 않습니다.

이름은 무엇을 하는지만 적습니다

규칙을 복잡하게 정하면 지키지 못합니다. 영문 소문자와 붙임표만 쓰고, 무엇을 하는 브랜치인지 적으면 충분합니다.

좋은 이름

바로 알아봅니다
  • timer-fix
  • add-quiz-page
  • seat-shuffle

피할 이름

일주일 뒤 못 알아봅니다
  • test, new, work2
  • 수정 (한글·공백은 도구가 싫어합니다)
  • fix-20260902-final-v3

언제 만들고 언제 지우나

만들 때는 일을 시작하기 직전입니다. 고치기 시작한 다음에 만들려면 번거로워집니다. 지울 때는 머지된 직후입니다. 안 지우면 목록이 금세 스무 개가 되고 어느 게 살아 있는 작업인지 아무도 모르게 됩니다.

브랜치 하나는 일 하나여야 합니다. 타이머도 고치고 색도 바꾸고 글꼴도 손대면, 동료가 리뷰할 때 무엇을 봐야 할지 알 수 없고 문제가 생겨도 어느 부분 때문인지 못 가립니다.

이렇게 말하세요

지금 main에 있는지 확인하고, 최신으로 풀 받은 다음에 seat-shuffle 브랜치를 새로 만들어줘. 이번 브랜치에서는 자리 뽑기 기능만 손대고 다른 건 건드리지 마.

브랜치를 만들기 전에 할 일 먼저 main을 최신으로 풀 받으세요. 옛날 main에서 갈라져 나오면 동료가 그사이 올린 작업이 빠진 상태로 일하게 되고 나중에 합칠 때 충돌이 크게 납니다.

04 — Pull Request

PR과 리뷰

한 줄로 말하면 고친 수정본을 원본에 반영해도 되는지 동료에게 확인을 구하는 자리입니다. 무엇이 바뀌는지 줄 단위로 보여줍니다.

PR은 이름이 헷갈리게 지어졌습니다. 원말이 pull request인데 무엇을 당겨오는 게 아니라, 내 브랜치를 main에 합쳐 달라고 요청하는 것입니다. 기안을 올리고 결재를 기다리는 것과 비슷합니다.

PR을 열면 깃허브가 바뀐 줄만 골라 나란히 보여줍니다. 동료는 파일 전체를 읽을 필요 없이 이것만 보면 됩니다. 공동작업에서 PR이 값을 하는 대목이 여기입니다. 검토 비용을 크게 줄여 줍니다.

PR에 무엇을 적나

제목 한 줄과 본문 몇 줄이면 충분합니다. 다만 세 가지는 꼭 적으세요.

1

무엇을 고쳤나
  • 타이머가 끝나도 소리가 안 나던 문제

2

왜 고쳤나
  • 3반 수업에서 학생들이 시간을 못 알아챔

3

어떻게 확인했나
  • 크롬과 아이패드에서 각각 1분 타이머로 확인

3번을 적는 습관이 리뷰 품질을 가장 크게 바꿉니다. 동료가 무엇을 다시 확인해야 하는지 알게 되기 때문입니다.

아직 볼 필요 없을 때는 초안으로

작업이 덜 끝났는데 진행 상황을 공유하고 싶다면 초안 PR draft pull request로 엽니다. 초안은 합칠 수 없는 상태로 열리므로, 동료가 "이거 지금 봐야 하나" 고민하지 않아도 됩니다. 다 되면 준비 완료로 바꿔 리뷰를 요청합니다.

리뷰는 셋 중 하나입니다

깃허브 공식 문서가 정한 세 가지입니다. 동호회에서는 이 셋의 뜻만 맞춰 두어도 오해가 크게 줄어듭니다.

고르는 것공식 설명동호회에서는 이럴 때
코멘트
Comment		 "Leaves general feedback without explicitly approving or requesting changes." 궁금한 걸 묻거나 의견만 남길 때. 합쳐도 되는지를 정하는 건 아닙니다
승인
Approve		 "Signals that the changes are ready to merge." 합쳐도 되겠다고 볼 때. 승인이 곧 머지는 아닙니다. 합치는 건 따로 눌러야 합니다
변경 요청
Request changes		 "Flags feedback that the author should address before merging." 합치기 전에 고쳐야 할 게 있을 때. 무엇을 어떻게 고쳐야 하는지 함께 적어 주세요

← 옆으로 밀 수 있습니다

지적을 받으면 어떻게 하나

PR을 닫고 새로 열 필요가 없습니다. 같은 브랜치에 이어서 커밋하고 푸시하면 PR이 저절로 갱신됩니다. 동료는 새로 바뀐 부분만 다시 보면 됩니다.

이렇게 말하세요

PR에 달린 리뷰 코멘트를 읽고, 요청받은 것만 골라서 고쳐줘. 고치기 전에 무엇을 어떻게 바꿀 건지 먼저 알려주고, 내가 좋다고 하면 그때 같은 브랜치에 커밋해서 올려줘.

혼자 쓰는 저장소에서도 PR이 쓸모 있습니다 승인해 줄 동료가 없어도 PR을 열면 바뀐 줄을 한 화면에서 훑어볼 수 있고, 나중에 "이 기능을 왜 이렇게 만들었더라"를 되짚을 기록이 남습니다. 배포 사이트를 붙여 두었다면 PR마다 미리보기 주소까지 생깁니다(배포 대백과 참고).
열어 두고 잊지 마세요 PR을 열어 놓고 몇 주가 지나면 그사이 main이 바뀌어 충돌이 크게 자랍니다. 작게 열고 빨리 합치는 것이 가장 안전합니다. 하루 이틀 안에 끝날 크기로 나누세요.

05 — Merge

머지

한 줄로 말하면 확인받은 수정본을 원본에 반영하는 것입니다. 방식이 셋인데, 동호회라면 스쿼시 하나로 통일하면 됩니다.

깃허브에서 PR을 합칠 때 버튼이 세 가지로 갈립니다. 무엇이 다르냐면 합친 뒤 이력에 무엇이 남느냐입니다. 결과물 자체는 셋 다 같습니다.

머지 커밋·스쿼시·리베이스 세 방식이 남기는 이력을 비교한 그림 머지 커밋 스쿼시 리베이스 작업 커밋이 그대로 남고 합친 자국이 하나 더 생깁니다 여러 커밋이 하나로 뭉칩니다 main 이력이 가장 읽기 쉽습니다 작업 커밋이 일렬로 붙습니다 합친 자국은 남지 않습니다
방식공식 설명이럴 때
머지 커밋
merge commit		 "preserves every commit from the pull request branch and adds an explicit merge point" 작업 과정을 통째로 남겨야 할 때. 대신 이력이 금세 복잡해집니다
스쿼시
squash and merge		 "combines all commits in the pull request into a single commit on the base branch" 동호회에 권합니다. PR 하나가 커밋 하나가 되어 이력이 읽히고, 문제가 생기면 그 하나만 되돌리면 됩니다
리베이스
rebase and merge		 "adds each commit onto the base branch without a merge commit, for a linear history" 커밋을 하나하나 살리면서 이력은 곧게 두고 싶을 때. 커밋을 정갈하게 쌓는 습관이 있어야 값을 합니다

← 옆으로 밀 수 있습니다

고민되면 스쿼시 이유는 되돌리기입니다. PR 하나가 커밋 하나로 남으면, 나중에 "지난주 자리 뽑기 기능 때문에 터진 것 같다" 싶을 때 그 커밋 하나만 되돌리면 끝납니다. 머지 커밋 방식은 커밋 대여섯 개 중 어느 것이 원인인지부터 찾아야 합니다.
저장소 Settings에서 스쿼시만 남기고 나머지 둘을 꺼 두면 매번 고르지 않아도 됩니다.
합친 뒤에 할 일 ① 브랜치를 지웁니다(깃허브가 버튼을 띄워 줍니다) ② 내 컴퓨터에서 main으로 옮겨 풀을 받습니다 ③ 동료에게도 풀 받으라고 알립니다. ②를 빼먹고 다음 브랜치를 만들면 옛날 판에서 갈라져 나가게 됩니다.

06 — Conflict

충돌

한 줄로 말하면 두 사람이 같은 줄을 다르게 고쳐 왔을 때, 깃이 함부로 정하지 않고 사람에게 묻는 것입니다. 사고가 아닙니다.

충돌 conflict이라는 말이 무섭게 들리지만, 하는 일은 학년 회의와 같습니다. 두 선생님이 같은 칸을 다르게 채워 왔으면 누군가는 어느 쪽을 쓸지 정해야 합니다. 깃은 그 판단을 대신 하지 않고 멈춰 섭니다. 마음대로 한쪽을 지우지 않는다는 뜻이라 오히려 다행입니다.

같은 줄을 두 사람이 다르게 고쳐 충돌이 생기는 과정 그림 원래 파일 12번째 줄 소리를 3초 재생 나 5초로 바꿔서 푸시 동료 아예 끄도록 바꿔서 푸시 깃이 판단을 멈춥니다 어느 쪽을 쓸지 사람에게 묻습니다

충돌이 나는 조건은 좁습니다

같은 파일을 고쳤다고 나는 게 아닙니다. 같은 줄을 서로 다르게 고쳤을 때만 납니다. 한 사람은 10번째 줄, 다른 사람은 80번째 줄을 고쳤다면 깃이 알아서 둘 다 반영합니다.

그래서 충돌을 줄이는 방법도 단순합니다. 브랜치를 오래 끌지 않는 것과 한 브랜치에서 여러 일을 하지 않는 것입니다. 규칙을 외우는 것보다 이 두 습관이 훨씬 잘 듣습니다.

이렇게 말하세요

충돌이 났대. 어떤 파일 어느 부분이 부딪혔는지 먼저 설명해주고, 내 쪽과 동료 쪽이 각각 뭘 하려던 건지 알려줘. 어느 쪽을 살릴지는 내가 정할게. 묻지 말고 지우지는 마.

"먼저 설명해줘"를 빼지 마세요 그냥 "충돌 해결해줘"라고 하면 AI가 임의로 한쪽을 지웁니다. 지워지는 쪽은 대개 동료의 작업입니다. 동료는 자기 것이 사라진 줄도 모르고, 며칠 뒤에야 기능이 없어진 걸 발견하게 됩니다. 반드시 무엇과 무엇이 부딪혔는지 설명받고, 어느 쪽을 살릴지 직접 정하세요.
셋 중 하나를 고르는 겁니다 ① 내 것을 살린다 ② 동료 것을 살린다 ③ 둘을 합쳐 새로 쓴다. 실제로는 ③이 정답인 경우가 많습니다. 위 예시라면 "소리를 5초 재생하되 끌 수 있는 설정을 둔다"가 되겠지요. ③을 고려하지 않고 ①·② 중에서만 고르면 누군가의 의도가 통째로 사라집니다.

07 — Fork

포크

한 줄로 말하면 쓰기 권한이 없는 저장소에 기여하는 방법입니다. 내 계정으로 통째로 복사해 고친 뒤, 원본에 제안합니다.

동호회 밖 선생님이 우리 자료의 오타를 발견했다고 해봅시다. 그분에게는 우리 저장소에 쓸 권한이 없습니다. 권한을 주자니 부담스럽고, 안 주자니 고쳐 주겠다는 걸 못 받습니다. 포크 fork가 이 자리를 메웁니다.

포크를 뜨면 그 저장소가 그분 계정 아래에 통째로 복사됩니다. 거기서는 마음대로 고칠 수 있습니다. 다 고치면 우리 쪽으로 PR을 보냅니다. 우리는 그 PR을 읽어 보고 받을지 말지 정하면 됩니다. 권한을 내주지 않고도 기여를 받는 방법입니다.

원본 저장소와 내 포크와 내 컴퓨터 사이에서 포크·클론·푸시·PR이 오가는 그림 원본 저장소 upstream · 남의 계정 내 계정의 복사본 origin · 내 포크 내 컴퓨터 여기서 고칩니다 포크 클론 푸시 동기화 PR 보내기

포크한 뒤 원본이 바뀌면

포크는 뜬 그 순간의 복사본입니다. 원본이 그 뒤에 바뀌어도 저절로 따라오지 않습니다. 오래 두면 내 포크만 옛날 판으로 남아, 나중에 PR을 보낼 때 충돌이 크게 납니다. 그래서 동기화가 필요합니다.

깃허브 화면에서는 포크 저장소 첫 화면의 Sync fork를 누르고 Update branch를 고르면 끝납니다.

터미널로 직접 한다면
# 원본을 upstream 이라는 이름으로 한 번만 등록해 둡니다 $ git remote add upstream https://github.com/원본계정/저장소.git # 그다음부터는 이 세 줄 $ git fetch upstream $ git checkout main $ git merge upstream/main

공식 문서가 짚는 함정이 하나 있습니다. "Syncing your fork only updates your local copy." 위 세 줄은 내 컴퓨터만 최신으로 만듭니다. 깃허브의 내 포크까지 갱신하려면 푸시를 한 번 더 해야 합니다.

언제 포크를 쓰고 언제 안 쓰나 쓰기 권한이 있으면 포크를 뜨지 마세요. 브랜치로 하는 편이 단순하고 빠릅니다. 포크는 권한이 없을 때, 또는 남의 공개 저장소에 고침을 제안할 때 쓰는 방법입니다. 동호회 안에서 일한다면 대부분 브랜치면 충분합니다.

08 — Worktree

워크트리 심화

한 줄로 말하면 저장소 하나를 폴더 여러 개로 펼쳐 브랜치를 동시에 열어 두는 기능입니다. 처음 하는 분은 건너뛰셔도 됩니다.
먼저 밝혀 둡니다 이 장은 없어도 공동작업에 아무 지장이 없습니다. 브랜치를 갈아 끼우는 것만으로 충분합니다. 불편함을 느낀 뒤에 돌아오세요. 그전에 읽으면 쓸데없이 어렵기만 합니다.

어떤 불편함을 푸는가

타이머를 고치던 중에 급한 제보가 들어왔다고 해봅시다. 다른 브랜치로 옮겨야 하는데, 지금 하던 작업은 아직 커밋할 상태가 아닙니다. 어중간하게 커밋하기도, 버리기도 애매합니다. 바로 이 상황이 워크트리를 쓰는 유일한 이유입니다.

깃 공식 문서의 설명은 이렇습니다. "A git repository can support multiple working trees, allowing you to check out more than one branch at a time." 저장소 하나가 작업 폴더를 여러 개 가질 수 있고, 그래서 브랜치를 한 번에 하나 이상 열어 둘 수 있다는 뜻입니다.

저장소 하나가 작업 폴더 세 개로 펼쳐져 각각 다른 브랜치를 열어 둔 그림 저장소 하나 이력은 한 벌뿐입니다 my-app/ main을 열어 둠 my-app-timer/ timer-fix를 열어 둠 my-app-quiz/ add-quiz를 열어 둠 폴더는 여럿이지만 저장소는 하나입니다. 한쪽에서 커밋하면 다른 쪽에서도 그 이력이 보입니다.
터미널로 직접 한다면
# 새 브랜치를 새 폴더로 펼치기 $ git worktree add -b timer-fix ../my-app-timer # 지금 몇 개나 펼쳐 뒀는지 보기 $ git worktree list # 다 쓴 폴더 정리하기 (그냥 지우면 안 됩니다) $ git worktree remove ../my-app-timer

걸리는 제약 셋

  • 같은 브랜치를 두 폴더에 동시에 열 수 없습니다. 이미 열려 있으면 깃이 거절합니다
  • 처음 클론한 폴더는 지울 수 없습니다. 나중에 펼친 것만 정리됩니다
  • 정리 안 된 폴더는 지워지지 않습니다. 저장 안 한 수정이 남아 있으면 깃이 막아 줍니다
이미 쓰고 계실 수도 있습니다 paseo나 Orca 같은 오케스트레이터는 작업마다 워크트리를 하나씩 만들어 씁니다. 여러 작업을 동시에 돌리면서도 서로 안 부딪히는 것이 이 덕분입니다. 자세한 이야기는 작업환경 대백과에 있습니다.
폴더를 손으로 지우지 마세요 탐색기에서 워크트리 폴더를 그냥 삭제하면 저장소에 유령 등록만 남습니다. 그 브랜치를 다시 펼치려 하면 "이미 열려 있다"며 거절당하는데, 원인을 찾기가 꽤 성가십니다. 반드시 git worktree remove로 정리하세요.

09 — Permission

권한과 안전장치

한 줄로 말하면 개인 저장소로는 권한을 나눌 수 없습니다. 조직을 만들고 교사 인증을 하면 Team이 무료라, 규칙까지 걸 수 있습니다.

동호회가 커지면 반드시 나오는 질문이 있습니다. "새로 들어온 선생님께 권한을 어디까지 드려야 하나요?" 답은 저장소를 누가 가지고 있느냐에 따라 완전히 달라집니다.

개인 저장소에는 읽기 전용이 없습니다 깃허브 공식 문서가 못 박습니다. 개인 계정이 가진 저장소의 권한은 소유자와 협업자 둘뿐이고 비공개 저장소에서는 "collaborators can't have read-only access"입니다. 협업자로 부르면 곧바로 쓰기 권한이 갑니다.
즉 "일단 읽기만 하시라고 초대할게요"가 개인 저장소에서는 불가능합니다. 초대하는 순간 그분은 main에 직접 푸시할 수 있게 됩니다.
따져볼 것개인 저장소조직 저장소조직 + Team
권한 단계 소유자·협업자 둘뿐 읽기·분류·쓰기·관리·소유 다섯 다섯 + 팀 단위 배정
읽기 전용으로 초대 안 됩니다 됩니다 됩니다
main 직접 푸시 막기 규칙을 걸 수 없습니다 규칙을 걸 수 없습니다 보호 규칙으로 막습니다
리뷰 없이 머지 막기 약속으로만 약속으로만 규칙으로 강제
비용 무료 무료 교사 인증 시 무료

← 옆으로 밀 수 있습니다

보호 규칙은 Team부터입니다

"main에는 직접 못 올리게 하고 반드시 PR로만 받게 하고 싶다"는 요구를 들어주는 기능이 보호 규칙 rulesets입니다. 그런데 공식 문서가 대상을 이렇게 한정합니다. "for customers on GitHub Team and GitHub Enterprise plans." 무료 요금제로는 걸 수 없습니다.

교사에게는 길이 있습니다 깃허브 교육 프로그램은 인증된 교사에게 GitHub Team을 무료로 줍니다. 공식 안내 문구가 "free GitHub Team, which allows unlimited users and private repositories"입니다. 인원 제한도 비공개 저장소 제한도 없습니다. 코파일럿 Pro도 함께 딸려 옵니다.
재직증명서 한 장이면 됩니다. 신청 절차는 깃허브 대백과 7장에 있습니다. 동호회를 조직으로 만들고 여기에 Team을 붙이는 것이 가장 깔끔한 구성입니다.

규칙을 걸기 전까지는 약속으로

인증이 아직이거나 조직을 만들기 전이라면 규칙 대신 약속으로 갑니다. 아래 다섯 줄을 저장소 README에 적어 두면 그것만으로도 사고가 크게 줍니다.

우리 동호회 약속 (그대로 옮겨 쓰셔도 됩니다)

  1. main에는 직접 푸시하지 않습니다. 무엇을 하든 브랜치를 먼저 만듭니다
  2. PR에는 무엇을·왜·어떻게 확인했는지 세 줄을 적습니다
  3. 내 PR은 내가 머지하지 않고, 한 사람 이상 보고 나서 합칩니다
  4. 머지는 스쿼시로 통일하고 합친 브랜치는 바로 지웁니다
  5. 충돌은 혼자 지우지 않고, 부딪힌 두 사람이 함께 정합니다

조직을 만들 때 딱 하나만 기억한다면

소유자를 반드시 두 명 이상 만든 사람 혼자 소유자인 상태에서 그분이 전출하거나 휴직하면 동호회 자료 전체를 아무도 손댈 수 없게 됩니다. 실제로 자주 벌어지는 일입니다. 조직을 만든 그날 바로 두 번째 소유자를 지정하세요.

올리기 전 점검표

여섯 개가 다 켜졌다면 사람을 늘려도 됩니다. 마지막 항목은 한 번 올리면 이력에 남아 지우기 어려우니 특히 먼저 보세요.

10 — Common Traps

자주 막히는 곳

한 줄로 말하면 처음 여럿이 일할 때 나오는 사고는 거의 정해져 있습니다. 미리 알아 두면 대부분 안 겪습니다.
이런 일이왜 생기나어떻게 하나
main에 바로 올림 브랜치 만드는 걸 잊었습니다. 가장 흔합니다 커밋 전이면 브랜치를 만들어 옮기면 됩니다. 이미 올렸다면 동료에게 알리고 되돌립니다
합칠 때 충돌이 잔뜩 옛날 main에서 갈라져 나왔거나 브랜치를 오래 끌었습니다 브랜치를 만들기 전에 항상 풀부터. 브랜치는 하루 이틀 안에 끝낼 크기로
동료가 최신을 못 봄 머지까지는 됐는데 동료가 풀을 안 받았습니다 머지하면 동료에게 알립니다. 동료는 작업 시작 전에 풀부터 받는 습관을
브랜치가 스무 개 머지한 뒤 안 지웠습니다 머지 직후 깃허브가 띄우는 삭제 버튼을 그 자리에서 누릅니다
PR이 몇 주째 열려 있음 한 PR에 일을 너무 많이 담았습니다 기능 하나에 PR 하나로 쪼갭니다. 리뷰가 밀리면 직접 찾아가 부탁하세요
파일이 안 올라감 영상이나 큰 자료입니다. 50MiB부터 경고, 100MiB부터 차단됩니다 큰 파일은 링크만 적거나 Releases에 올립니다

← 옆으로 밀 수 있습니다

강제 푸시는 남의 작업을 지웁니다 --force가 붙은 푸시는 깃허브에 있던 이력을 내 것으로 덮어씁니다. 그사이 동료가 올린 커밋이 있었다면 흔적 없이 사라집니다. 동료는 자기 것이 없어진 줄도 모릅니다.
AI가 "푸시가 거절당했으니 강제로 밀겠다"고 하면 거기서 멈추세요. 거절당한 이유는 대개 동료가 먼저 올렸기 때문이고 그때 필요한 건 강제 푸시가 아니라 풀입니다.
이렇게 말하세요

푸시가 거절당했으면 강제로 밀지 말고 먼저 풀부터 받아줘. 받아 보고 충돌이 있으면 어디가 부딪혔는지 나한테 알려줘. force는 내가 하라고 하기 전에는 쓰지 마.

개인정보는 한 번 커밋하면 지워지지 않습니다 학생 명렬표나 연락처가 든 파일을 실수로 커밋했다면, 파일을 지우고 다시 커밋해도 이력에 그대로 남습니다. 저장소를 비공개로 돌려도 이미 본 사람은 되돌릴 수 없습니다.
  • 학생 정보가 든 파일은 애초에 저장소에 두지 않습니다. .gitignore에 먼저 적어 두세요
  • 시연이나 스크린샷에는 홍길동, 010-0000-0000 같은 가짜 값만 씁니다
  • 이미 올렸다면 이력에서 지우는 작업이 필요합니다. 혼자 하지 말고 도움을 받으세요
자세한 원칙은 배포 대백과 11장에 있습니다.
막혔을 때 물어보는 순서 ① 지금 어느 브랜치에 있나 ② 커밋은 했나 ③ 푸시는 했나. 이 셋만 확인하면 상황의 절반은 정리됩니다. AI에게도 이 세 가지를 먼저 알려주면 훨씬 정확하게 답합니다.

＋ — Reference

레퍼런스

화면과 요금 정책은 바뀝니다. 실제로 설정하기 전에는 아래 공식 페이지를 직접 여세요.

브랜치와 PR

포크와 워크트리

권한과 안전장치

시리즈 안내

  • 깃허브 대백과 · 가입, 저장소 만들기, 커밋과 푸시, 되돌리기, 교사 인증 절차
  • 작업환경 대백과 · 오케스트레이터가 워크트리를 어떻게 쓰는지
  • 배포 대백과 · PR마다 미리보기 주소가 생기는 이유, 개인정보를 어디에 두면 안 되는지

＋ — Sources

자료 출처

이 문서의 사실은 2026년 9월 2일에 깃허브와 깃 공식 문서로 확인했습니다. 요금 정책과 화면은 바뀌므로, 설정을 결정하기 전 원문을 다시 확인하시길 권합니다.

주요 인용

  • 리뷰 3종 "Leaves general feedback without explicitly approving or requesting changes." / "Signals that the changes are ready to merge." / "Flags feedback that the author should address before merging."
  • 머지 3종 "preserves every commit from the pull request branch and adds an explicit merge point" / "combines all commits in the pull request into a single commit on the base branch" / "adds each commit onto the base branch without a merge commit, for a linear history"
  • 워크트리 "A git repository can support multiple working trees, allowing you to check out more than one branch at a time."
  • 개인 저장소 권한 비공개 저장소에서 "collaborators can't have read-only access to repositories owned by a personal account"
  • 보호 규칙 "for customers on GitHub Team and GitHub Enterprise plans"
  • 교사 혜택 "free GitHub Team, which allows unlimited users and private repositories"
  • 포크 동기화 "Syncing your fork only updates your local copy of the repository."
  • 파일 한도 50 MiB부터 경고, "GitHub blocks files larger than 100 MiB."

참고할 법령

  • 개인정보 보호법 제28조의8 개인정보의 국외 이전. 깃허브는 국외 사업자입니다
  • 초·중등교육법 제30조의6 학생 관련 자료 제공의 제한

법령 해석이 필요한 사안은 소속 기관의 개인정보 보호 담당자에게 확인하시기 바랍니다.

이 문서에서 가장 빨리 낡을 곳 ① 보호 규칙의 요금제 조건 ② 교사 인증 혜택 구성 ③ 깃허브 화면의 버튼 이름 ④ 파일 크기 한도. 이 넷을 다음 점검에서 먼저 다시 봅니다.