한 번에 훑어보기

01 시작은 이 질문 세 개였습니다

수업은 Git이라는 단어가 아니라 겪어 본 불편에서 출발했습니다.

발표자료.pptx
발표자료_수정.pptx
발표자료_최종.pptx
발표자료_진짜최종.pptx
발표자료_최종_수정_마지막.pptx   ← 어떤 게 진짜 최신이지?

여기에 사람이 늘면 질문이 늘어납니다. 철수와 영희가 같은 login.html 을 고쳤을 때 누구 파일을 써야 하는지, 그리고 어제까지 되던 로그인이 오늘 안 될 때 어제 코드로 어떻게 돌아가는지.

이 세 가지 — 무엇이 최신인가 · 누구 걸 쓰나 · 어떻게 되돌리나 — 를 한꺼번에 푸는 게 버전 관리입니다.

02 Git — 개발자를 위한 세이브 포인트

중요한 순간마다 기록을 남기고, 필요하면 그 지점으로 돌아갑니다. 그 기록 하나가 Commit 입니다. 게임 세이브와 다른 점이 하나 있는데, Git은 상태만이 아니라 누가 · 언제 · 무엇을 · 어떻게 바꿨는지까지 남깁니다.

정확한 이름은 버전 관리 시스템(VCS). 리눅스를 만든 리누스 토르발스가 2005년에 만들었습니다. 전 세계 개발자가 동시에 건드리는 리눅스를 감당해야 했는데 쓰던 상용 도구(BitKeeper)를 더는 무료로 쓸 수 없게 되면서, 직접 만든 것입니다.

그런데 Git은 내 컴퓨터에 설치하는 프로그램입니다. 그러면 GitHub는 뭘까요?

03 Git 과 GitHub 는 다른 것입니다

Git

프로그램입니다. 내 컴퓨터에 설치합니다. 인터넷이 끊겨도 Commit 은 됩니다.

GitHub

웹 서비스입니다. 회원가입을 합니다. Git으로 관리하는 프로젝트를 올려두고 나누는 곳입니다.

GitHub 없이도 Git 은 씁니다. 그런데도 다들 GitHub를 쓰는 이유는 다섯 가지였습니다 — 백업 · 협업 · 변경 이력 · 남의 코드 열어보기 · 포트폴리오. 마지막 것 때문에 뒤에서 이메일 설정 하나가 중요해집니다.

두 곳이 서로 다른 공간이라는 걸 잡았으면, 이제 그 사이를 코드가 어떻게 오가는지 볼 차례입니다.

04 코드가 거쳐 가는 4개의 공간

이 4칸을 하나씩 지나가 봅니다. 첫 칸에서 둘째 칸으로 넘어가기 전에, 먼저 짚고 갈 오해가 하나 있습니다.

05 Ctrl + S 는 Commit 이 아닙니다

Ctrl + S 는 그냥 파일 저장입니다. 이 시점에 Git은 아직 아무것도 기록하지 않았습니다. Commit은 "이 상태를 하나의 버전으로 기억해줘" 라고 Git에게 말하는 것이고, 거기엔 이름표(메시지)가 붙습니다.

수정
수정2
최종
aaa

로그인 기능 추가
회원가입 유효성 검사 추가
게시판 검색 오류 수정

메시지만 봐도 무엇이 바뀌었는지 알 수 있어야 합니다. 나중에 그 줄들이 곧 프로젝트의 역사가 됩니다.

그런데 Commit 하기 직전에 한 단계가 더 있었습니다. 왜 굳이 한 칸을 더 두는 걸까요?

06 Stage — 이번에 보낼 것만 고른다

파일 셋을 고쳤어도 이번 Commit에 넣고 싶은 건 둘뿐일 수 있습니다. 택배 상자에 보낼 것만 골라 담듯, 이번 버전에 포함할 파일을 먼저 고릅니다. 이 고르는 과정이 Stage 이고, 그 물건들이 놓이는 자리가 Staging Area 입니다.

고친 것   login.html   login.js   README.md
담은 것   login.html   login.js              ← 이번 Commit 에 들어갈 것

여기까지가 전부 내 컴퓨터 안이었습니다. 이제 처음으로 인터넷을 탑니다.

07 Push 와 Pull — 방향이 전부입니다

여기에 Clone 까지 넣으면 네 단어가 됩니다. 헷갈릴 때는 "프로젝트가 있나 없나" 로 가릅니다.

Ctrl + S  =  파일 저장
Commit    =  Git 버전 기록   (아직 내 컴퓨터)
Push      =  Local  → Remote
Pull      =  Remote → Local

방향을 잡았으면, 이제 실제로 손이 움직인 순서를 되짚어 봅니다.

08 처음 한 번만 하는 설정

Commit에는 작성자 정보가 같이 남습니다. 그 이름표를 미리 정해 둔 것이 이 세 줄이었습니다.

git config --global user.name  "홍길동"
git config --global user.email "github가입이메일@example.com"
git config --global init.defaultBranch main

git config --global user.name     # 확인 — 값이 되돌아오면 성공

설정이 끝났으니 실제 순서입니다. 혼자 할 때와 팀으로 할 때가 다릅니다.

09 실제 작업 순서

코드 작성
   ↓
Stage
   ↓
Commit
   ↓
Push

PULL    ← 작업 시작 전
WORK
STAGE → COMMIT
PULL    ← 올리기 직전 한 번 더
PUSH

왜 Push 전에 다시 Pull 하나? 내가 개발하는 동안 팀원이 새 커밋(D)을 올렸을 수 있습니다. 내 것(E)만 밀어 올리면 GitHub의 D와 부딪힙니다. Pull로 D를 먼저 받아 합친 뒤 Push합니다.

내 컴퓨터   A B C + E        ← 내가 만든 것
GitHub     A B C + D        ← 그 사이 팀원이 올린 것
                            → PULL 로 D 를 받아 A B C D E 를 만든 뒤 PUSH

이 순서를 VS Code 버튼으로 눌렀는데, 그 버튼들이 실제로는 무슨 명령어였는지 맞춰 봅니다.

10 VS Code 버튼 ↔ 명령어

VS Code는 Git을 대신하는 게 아니라 PC에 설치된 Git을 불러 씁니다. 그래서 Git이 없으면 버튼도 안 먹습니다.

명령어는 다 외울 필요 없습니다. 실제로 쓴 건 여덟 개뿐이었습니다.

11 핵심 명령어 여덟 개

그리고 VS Code 화면에서 파일 옆에 붙던 글자 하나가, 사실 같은 정보를 말하고 있었습니다.

12 파일 옆 글자와, 막혔을 때 보는 곳

마지막 한 가지 — 팀으로 하면 언젠가 반드시 만나는 상황이 있습니다.

13 Conflict 와 Branch — 맛만 봤습니다

철수와 영희가 같은 줄을 고쳤습니다. Git 입장에서는 답이 없습니다. 그래서 멈추고 사람에게 묻습니다 — 이게 Conflict(충돌) 입니다.

그리고 Branch 는 돌아가고 있는 코드를 망가뜨리지 않고 새 기능을 시험하려고 내는 갈래입니다. 다만 첫 시간에는 여기까지만 — Commit · Push · Pull · Clone 이 정확해진 다음에 갑니다.

여기까지가 수업 한 바퀴입니다. 이제 스스로 확인할 차례입니다.

14 스스로 확인하기

답이 바로 안 나오면, 위에서 그 마디로 돌아가면 됩니다.

문제로 확인했으면, 손으로 한 것도 빠진 게 없는지 훑어봅니다.

15 실습 10 — 해 본 것 표시하기

항목을 누르면 체크됩니다. 안 한 게 있으면 그것만 다시 해 보세요.

1. 바탕화면에 git-study 폴더 + index.html (<h1>Hello Git!</h1>)
2. Source Control → Initialize Repository (= git init)
3. + 버튼으로 Stage — Staged Changes 로 자리가 옮겨가는지 확인
4. 메시지 첫 페이지 생성 으로 Commit
5. GitHub에서 git-study Repository 생성 (README 체크 안 함)
6. Publish to GitHub — 브라우저에서 저장소가 생겼는지 확인
7. <p>Git과 GitHub를 공부하고 있습니다.</p> 추가 → Stage → Commit → Push
   (Commit만 하고 GitHub 새로고침 → 안 바뀜을 먼저 확인)
8. GitHub 웹에서 <h2>GitHub에서 수정했습니다.</h2> 추가하고 Commit changes
9. VS Code에서 Pull — 내 파일이 실제로 바뀌는지 눈으로 확인
10. Ctrl+Shift+P → Git: Clone 으로 다른 폴더에 받아 보기

다 됐다면, 오늘 들고 갈 것은 결국 다섯 줄입니다.

16 오늘 들고 가는 다섯 줄

다음 시간에는 여기서 이어집니다 — Branch → Merge → Conflict → Pull Request → Code Review.