바이브 코딩을 위한 Git & GitHub
부록

부록 B — 자주 묻는 질문 20선

교사 독자들이 워크숍과 연수 자리에서 실제로 가장 많이 묻는 스무 개의 질문을 모았습니다. 각 답변은 두세 문장으로 짧게, 필요한 곳에는 유추를 곁들였습니다. 순서는 아무 곳부터 읽어도 됩니다.

(1) Git과 GitHub는 같은 건가요?

아닙니다. Git은 내 컴퓨터에 설치하는 버전 관리 프로그램이고, GitHub는 Git으로 관리한 저장소를 올려두는 인터넷 창고입니다. Git이 워드 프로세서라면 GitHub는 구글 드라이브입니다.

(2) GitHub Desktop과 VSCode Source Control 중 뭘 먼저 익혀야 하나요?

GitHub Desktop 먼저입니다. 커밋·푸시·브랜치 개념을 클릭으로 체득한 뒤에 VSCode Source Control로 넘어가면 훨씬 빠릅니다. 두 도구는 같은 일을 하므로 하나만 확실히 익히면 나머지는 저절로 따라옵니다.

(3) 커밋을 너무 자주 찍어도 괜찮나요?

괜찮습니다. 오히려 드물게 찍는 것이 문제가 됩니다. 한 가지 의미 있는 변경이 끝날 때마다 찍는 것이 기본이고, "이 시점으로 돌아올 일이 있을까"가 기준이 됩니다.

(4) 학생에게 저장소를 공유해도 되나요?

공개(Public) 저장소로 둔다면 누구나 볼 수 있으므로 학생 이름·얼굴 사진 등이 담긴 저장소는 비공개(Private)로 두는 편이 안전합니다. 수업 자료만 담은 저장소라면 공개 링크로 공유해도 좋습니다.

(5) 비공개 저장소도 GitHub에 무료인가요?

무료입니다. 개인 계정에서 비공개 저장소 개수에 제한이 없습니다. 협업자 수에 일부 제한이 있으나 대부분의 학급 프로젝트에서는 신경 쓸 일이 없습니다.

(6) 브랜치를 삭제하면 그 안의 커밋도 사라지나요?

이미 main에 병합된 커밋이라면 남고, 병합되지 않은 브랜치 고유 커밋은 사라집니다. GitHub Desktop은 병합되지 않은 브랜치를 삭제할 때 경고창을 띄우므로 그 경고를 무시하지 않는 한 실수할 일은 적습니다.

(7) API 키를 실수로 커밋했습니다. 히스토리에서 완전히 지울 수 있나요?

히스토리에서 키 문자열을 지우는 것은 이론상 가능하나(git filter-repo 등) 번거롭고 실수 여지가 큽니다. 현실적으로는 10장에서 다룬 것처럼 키 자체를 즉시 폐기하고 새 키를 발급받는 쪽이 훨씬 안전하고 빠릅니다.

(8) class-2b 같은 웹사이트를 Vercel에 올리려면 어떻게 하나요?

Vercel에 가입하고 GitHub 저장소를 연결하면 Import 한 번으로 끝납니다. 이후 커밋을 Push할 때마다 Vercel이 자동으로 새 버전을 배포합니다. 주소는 프로젝트이름.vercel.app 형태로 바로 받습니다.

(9) 학교 컴퓨터에 GitHub Desktop을 설치할 수 없습니다.

학교 전산 정책상 설치가 막혀 있다면 브라우저에서 GitHub.com을 직접 사용하는 방법이 있습니다. 파일 업로드·수정·커밋·브랜치 만들기까지 모두 웹에서 됩니다. 기능은 제한되지만 본문의 대부분을 그대로 따라갈 수 있습니다.

(10) Copilot 교육용 무료 신청은 어떻게 하나요?

GitHub Education(education.github.com)에 학교 이메일로 신청하면 됩니다. 재직증명서나 교사 신분증 사진이 필요할 수 있습니다. 승인되면 GitHub Copilot과 추가 학습 리소스가 무료로 열립니다.

(11) 내 저장소를 다른 선생님이 수정할 수 있게 하려면요?

두 가지 방법이 있습니다. 첫째, 그 선생님을 Collaborator로 초대해 직접 수정 권한을 줍니다. 둘째, 9장에서 본 것처럼 Fork → Pull Request 흐름으로 받습니다. 학년부 단위 공동 관리는 전자가, 일회성 기여는 후자가 자연스럽습니다.

(12) 커밋 메시지는 한글로 써도 되나요?

괜찮습니다. 이 책의 예시도 대부분 한글과 영문 prefix를 섞어 씁니다. 중요한 것은 언어가 아니라 "왜 변경했는지"가 한 줄에 담기는가입니다.

(13) main 브랜치에 직접 커밋해도 되나요?

혼자 작업하는 소규모 학급 사이트라면 문제없습니다. 다만 10장의 .env 사고처럼 되돌리기 힘든 실수를 줄이려면, 실험적 변경은 새 브랜치를 따고 결과가 안정될 때만 main으로 합치는 습관을 들이는 편이 좋습니다.

(14) 두 컴퓨터(학교·집)에서 같은 저장소를 쓰려면요?

한쪽에서 작업이 끝나면 Push, 다른 쪽에서 시작할 때 Pull. 이 두 단어만 기억하면 됩니다. "퇴근 전 Push, 집에서 Pull" 순서를 지키면 같은 파일을 두 번 쓰는 충돌을 거의 피할 수 있습니다.

(15) Pull Request와 Merge Request는 다른가요?

부르는 이름만 다르고 하는 일은 같습니다. GitHub에서는 Pull Request(PR), GitLab에서는 Merge Request(MR)라 부릅니다. 이 책은 GitHub 기준이므로 Pull Request로 통일해 설명합니다.

(16) 저장소 이름을 나중에 바꿀 수 있나요?

바꿀 수 있습니다. GitHub 저장소 페이지의 Settings → Repository name에서 변경합니다. 이미 Clone 받은 선생님·학생 쪽에서는 원격 주소를 한 번 갱신해 줘야 하므로 학기 중간 변경은 신중히 결정합니다.

(17) README 파일은 꼭 필요한가요?

꼭은 아니지만 있으면 편합니다. 저장소 첫 화면에 자동으로 표시되어 "이 프로젝트가 무엇인지·어떻게 쓰는지"를 안내하는 안내문 역할을 합니다. 2026 교실에서는 학급 운영 안내·준비물·평가 일정의 메인 페이지로도 쓰입니다.

(18) 이미지·영상 파일도 GitHub에 올려도 되나요?

작은 이미지(수백 KB 수준)는 괜찮습니다. 다만 영상이나 수십 MB 이상의 큰 파일은 저장소가 무거워지므로 Google Drive·YouTube에 올리고 링크만 저장소에 두는 방식이 일반적입니다. 저장소당 권장 상한은 1GB 이하입니다.

(19) 커밋을 실수로 잘못 찍었어요. 되돌릴 수 있나요?

6장에서 다룬 Revert가 가장 안전한 방법입니다. GitHub Desktop History 탭에서 해당 커밋을 우클릭하고 "Revert this commit"을 누르면 취소 커밋이 하나 추가됩니다. 히스토리를 지우지 않으므로 언제든 다시 돌아올 수 있습니다.

(20) 이 책을 덮은 뒤에 무엇부터 해야 하나요?

오늘 내가 맡은 업무 하나를 Git 저장소로 만들어 GitHub에 올립니다. 학급 공지, 수행평가 안내, 동아리 계획 무엇이어도 좋습니다. 책에서 만든 class-2b가 아니라 "내 손의 프로젝트"에 첫 커밋을 찍는 순간, Git은 드디어 내 도구가 됩니다.