A-1: Git 으로 내 코드의 역사 남기기

안녕하세요, 홍순구 튜터입니다. 코드를 한 줄도 안 써본 분도, 이미 좀 써본 분도 모두 환영해요. 오늘부터 우리는 개발자라면 누구나, 매일 쓰는 도구 하나를 손에 익힙니다. 바로 Git 이에요.

먼저 솔직한 이야기부터 할게요. 현업에 처음 나간 신입 개발자들이 가장 많이 식은땀을 흘리는 게 뭔지 아세요? 어려운 알고리즘도, 복잡한 프레임워크도 아니에요. 바로 Git 입니다. "내 작업이 사라졌어요", "충돌이 떴는데 손도 못 대겠어요", "동료 코드를 실수로 날렸어요" — 이런 일로 첫 출근 주부터 멘붕에 빠지는 신입이 정말 많아요.

그런데 좋은 소식이 있어요. Git 은 무서운 게 아니라, 그냥 안 배워서 낯선 것뿐이에요. 이 강의를 끝낼 때쯤이면 여러분은 그 식은땀에서 자유로워집니다. 처음엔 다들 헷갈려요. 그러니 천천히, 하나씩 같이 가요.

오늘 우리가 할 일은 딱 하나예요. "내 코드의 역사를 남기는 법" 을 배웁니다. 아직 협업이나 GitHub 는 안 나와요. 오늘은 인터넷도 필요 없어요. 내 컴퓨터 안에서 나 혼자, 내 파일의 역사를 차곡차곡 쌓는 연습이에요.

   오늘의 여정 — 내 코드의 역사를 남기는 법

   ① 왜 '보고서_최종_진짜최종_v3' 의 비극이 생길까
   ② 검은 창과 친해지고, Git 에게 내 이름 알려주기
   ③ 빈 폴더가 '저장소' 가 되는 순간 — git init
   ④ Git 의 심장 — 세 개의 방
   ⑤ 첫 커밋을 찍어보자 — git add · git commit
   ⑥ 내가 걸어온 길 — git log
   ⑦ 무엇이 바뀌었나 — git diff
   ⑧ 6개월 뒤의 나를 구하는 커밋 메시지

①에서 "왜 Git 이 필요한가"를 몸으로 느끼고, ②③에서 실습 준비와 첫 저장소를 만들어요. ④에서 Git 의 핵심 그림을 머리에 넣고, ⑤에서 드디어 첫 커밋을 찍습니다. ⑥⑦에서 쌓인 역사를 읽는 법을, ⑧에서 "좋은 커밋 메시지"로 마무리해요.

💡 오늘 수업의 핵심 — "Git 은 내 코드의 매 순간을 사진처럼 찍어 역사로 남기는 도구다. 바꾼 것 중 담을 것만 골라(add) 한 장의 스냅샷으로 기록(commit)하면, 언제든 그 순간으로 돌아갈 수 있고 무엇이 왜 바뀌었는지 역사로 읽힌다."

🎯 학습 목표

• 왜 버전 관리가 필요한지(_최종 파일의 비극)와, Git 과 GitHub 가 어떻게 다른지를 자기 말로 설명합니다.
• 내 컴퓨터에 Git 을 준비하고(git config 로 이름·이메일 등록), 빈 폴더를 git init 으로 저장소로 만듭니다.
• 파일을 git add 로 골라 담아 git commit 으로 첫 역사를 남기고, git log·git diff 로 그 역사를 읽습니다.

Step 1: "왜 '보고서_최종_진짜최종_v3' 의 비극이 생기나"

본격적으로 Git 을 배우기 전에, Git 이 없을 때 무슨 일이 벌어지는지부터 봐요. 아마 한 번쯤은 겪어봤을 풍경이에요. 여러분 컴퓨터 어딘가에 이런 파일들, 혹시 있지 않나요?

 보고서.docx
 보고서_수정.docx
 보고서_최종.docx
 보고서_최종_진짜최종.docx
 보고서_최종_진짜최종_v3_이게진짜.docx   ← 어느 게 최신이지?

발표 전날 밤에 이 중 뭐가 진짜 최종인지 몰라 식은땀 흘려본 적, 다들 있을 거예요. 파일 이름 뒤에 _최종 을 붙여가며 버티는 이 방식엔 세 가지 큰 구멍이 있어요.

1. 어느 게 최신인지 헷갈린다. 이름만 봐서는 순서를 알 수 없어요. _이게진짜 다음에 또 고치면 뭐라고 붙여야 하죠?
2. "3일 전 그 문장으로 되돌리고 싶다" 가 안 된다. 이미 덮어썼다면 그 버전은 영영 사라졌어요.
3. 둘이 같은 파일을 동시에 고치면 한 명 작업이 통째로 날아간다. 나중에 합칠 방법이 없으니까요.

그리고 이 세 번째가 바로 현업에서 신입이 가장 크게 깨지는 지점이에요. 팀으로 일하면 같은 코드 파일을 여러 명이 동시에 고치는데, _최종 방식이라면 누군가의 하루치 작업이 흔적도 없이 사라질 수 있어요. 신입 때 "어? 내가 쓴 코드가 왜 없어졌지…" 하는 사고가 여기서 나와요. 오늘 배우는 Git 이 정확히 이 문제를 막아줍니다.

이 세 구멍을 한 방에 메우는 게 버전 관리 시스템(Version Control System, 줄여서 VCS) 이에요. 파일이 바뀐 모든 순간을 자동으로 기록하고, 언제든 과거로 되돌리고, 여러 사람의 작업을 안전하게 합쳐줘요.

그리고 그 VCS 중에서 전 세계가 사실상 표준으로 쓰는 게 Git 이에요. 오늘부터 우리가 배울 주인공이죠.

Git 과 GitHub 는 다르다 — 가장 먼저 풀어야 할 오해

여기서 입문자가 거의 100% 헷갈리는 걸 먼저 짚고 갈게요. Git 과 GitHub 는 다릅니다. 이름이 비슷해서 같은 거라고 생각하기 쉬운데, 역할이 완전히 달라요.

• Git 은 내 컴퓨터에서 도는 프로그램(도구) 이에요. 인터넷 없이 혼자서도 써요. 비유하자면 한글·워드 같은 문서 편집 프로그램.
• GitHub 는 그 Git 저장소를 인터넷에 올려 여럿이 함께 쓰게 해주는 웹 서비스(회사) 예요. 비유하자면 구글 드라이브 같은 공유 공간.

정리하면 이래요. Git 은 "도구", GitHub 는 "그 도구로 만든 걸 올려두는 공간" 이에요. GitHub 말고 GitLab·Bitbucket 같은 다른 공간도 있지만, 가장 널리 쓰이는 GitHub 를 기준으로 배울게요.

오늘(A-1)부터 A-3 까지는 인터넷 없이 순수 Git 만 다뤄요. GitHub 는 여럿이 협업하는 법을 배우는 A-4 부터 등장합니다. 그러니 지금은 "Git = 내 컴퓨터 안의 도구" 하나만 기억하면 충분해요.

💡 한 줄 정리

Git 은 파일이 바뀐 모든 순간을 기록해 "되돌리기"와 "안전하게 합치기"를 가능하게 하는 버전 관리 도구이고, GitHub 는 그걸 인터넷에 올려 함께 쓰는 공유 공간으로, 둘은 서로 다른 것이다.

Step 2: "검은 창과 친해지고, Git 에게 내 이름 알려주기"

Git 을 쓰려면 터미널(terminal) 이라는 검은 창이 필요해요. 많은 입문자가 이 검은 창을 무서워하는데, 사실 별거 아니에요. 마우스로 폴더를 더블클릭하는 대신, 글자로 명령을 입력하는 창일 뿐이에요. 오늘은 Git 을 쓰는 데 꼭 필요한 명령 서너 개만 가볍게 익히고 넘어갈게요. (터미널을 깊이 다루는 건 linux 과목이 따로 맡아요.)

터미널 여는 법부터요. 맥은 스포트라이트(Cmd+Space)에서 "터미널"을 검색해 열고, 윈도우는 Git 을 설치하면 같이 깔리는 Git Bash 를 쓰면 돼요. 창이 떴다면, 우리가 쓸 명령은 딱 이 셋이에요.

pwd          # 지금 내가 어느 폴더에 있나 (print working directory)
ls           # 이 폴더 안에 뭐가 있나 (list)
cd 폴더이름   # 그 폴더로 들어가기 (change directory)

cd .. 는 한 단계 위 폴더로 나가는 거예요. 이 정도면 오늘 실습은 충분해요. 검은 창은 "글자로 길 찾기"라고 생각하면 편해요.

Git 설치 확인하고, 내 이름 등록하기

Git 이 깔려 있는지부터 봐요.

git --version
# 출력 예시:
# git version 2.54.0

이렇게 버전 번호가 뜨면 설치된 거예요. 만약 "command not found" 가 뜨면 아직 설치가 안 된 거니, git-scm.com 에서 내 운영체제용 설치 파일을 받아 설치하면 돼요.

이제 Git 에게 내가 누구인지 알려줄 차례예요. 앞으로 남기는 모든 커밋에 "누가 작성했는지" 도장이 찍히거든요.

git config --global user.name "soongu"
git config --global user.email "hong@example.com"

여기에 더해, 새 저장소의 기본 브랜치 이름을 main 으로 맞춰둘게요. 한 줄만 더 쳐요.

git config --global init.defaultBranch main

왜 이걸 하냐면, 예전 Git 은 기본 브랜치 이름이 master 였는데 요즘은 main 이 표준이에요. GitHub 도 새 저장소를 전부 main 으로 만들고요. 이 한 줄을 미리 박아두면, 내 Git 버전이 뭐든 항상 main 으로 시작해서 헷갈릴 일이 없어요. (master 라는 이름은 오래된 저장소에서 가끔 보게 될 텐데, "예전 기본값이구나" 정도로만 알면 돼요.)

그리고 나중에 팀으로 협업할 때를 위해, 한 줄만 미리 해둘게요. Windows 는 줄바꿈을 CRLF 로, Mac·Linux 는 LF 로 저장해요. 한 팀에 두 운영체제가 섞이면 내용은 똑같은데도 git 이 "파일이 통째로 바뀌었다" 고 오해하는 일이 생겨요. 아래 한 줄이면 git 이 줄바꿈을 알아서 맞춰줘서 그 오해를 막아줘요. 지금 혼자 연습할 땐 티가 안 나도, 미리 해두면 나중에 편해요.

# Mac·Linux 는 input, Windows 는 true
git config --global core.autocrlf input

잘 들어갔는지 확인해볼까요?

git config --global user.name
# 출력 예시:
# Hong Soongu

GUI 로는 — GitHub Desktop 이나 VS Code 같은 도구를 처음 설치하면 이름·이메일을 똑같이 한 번 물어봐요. 그게 방금 우리가 친 git config 와 같은 일이에요.

💡 한 줄 정리

터미널은 글자로 명령을 내리는 창일 뿐이고, git config --global 로 이름·이메일과 기본 브랜치(main)를 한 번 등록해두면 그 컴퓨터의 모든 저장소에 공통으로 적용된다.

Step 3: "빈 폴더가 '저장소' 가 되는 순간 — git init"

이제 진짜 첫 저장소를 만들어봐요. 먼저 연습용 폴더 하나를 만들고 그 안으로 들어가요. 일기를 쓴다고 생각하고 my-diary 라고 할게요. (코드일 필요도 없어요. Git 은 어떤 파일이든 관리하니까요.)

mkdir my-diary
cd my-diary

지금 이 폴더는 그냥 보통 폴더예요. 여기에 마법의 한 줄을 걸어볼게요.

git init
# 출력 예시:
# Initialized empty Git repository in /Users/hong/my-diary/.git/

이 순간, 평범하던 폴더가 Git 저장소(repository) 가 됐어요. 뭐가 달라졌을까요? 숨겨진 폴더 하나가 생겼어요.

ls -a
# 출력 예시:
# .   ..   .git

저 .git 폴더가 Git 의 모든 비밀이 담긴 곳이에요. 앞으로 남길 모든 역사가 여기 차곡차곡 쌓여요. 절대 직접 열어서 건드리면 안 돼요 — Git 이 알아서 관리하니 우리는 명령만 내리면 돼요.

이제 저장소의 상태를 물어보는 가장 중요한 명령을 만나볼게요.

git status
# 출력 예시:
# On branch main
# No commits yet
# nothing to commit (create/copy files and use "git add" to track)

On branch main 보이시죠? 우리가 Step 2 에서 기본 브랜치를 main 으로 맞춰둔 게 여기서 확인돼요. 아직 커밋이 하나도 없으니 No commits yet 이라고 알려주고요. git status 는 앞으로 수십 번 칠 명령이에요. "Git 아, 지금 상황이 어때?" 하고 묻는 거죠.

나중에 익숙해지면 git status -s 로 짧게 요약해 보는 것도 편해요(s 는 short). 파일 상태를 한 줄에 기호로 압축해서 보여주거든요.

GUI 로는 — GitHub Desktop 의 "Create a New Repository" 버튼이 바로 이 git init 이에요.

💡 한 줄 정리

git init 한 줄이면 평범한 폴더가 Git 저장소가 되고(숨은 .git 폴더 생성), git status 로 언제든 "지금 상태"를 물어볼 수 있다.

Step 4: "Git 의 심장 — 세 개의 방"

이제 오늘 가장 중요한 그림 하나를 머리에 넣을 거예요. 이 그림만 손에 익으면 add 와 commit 이 한눈에 들어와요. Git 은 파일을 세 개의 공간으로 나눠 다뤄요.

      작업 폴더              스테이징 영역             저장소 (.git)
  Working Directory          Staging Area              Repository
  ────────────────────   ───────────────────────     ─────────────────
  지금 편집 중인 파일    이번에 커밋할 것만 골라     영구히 남은 역사(커밋들)

  (파일 수정)  ── git add ──▶  (담김)  ── git commit ──▶  커밋 = 스냅샷

• 작업 폴더: 지금 내가 파일을 고치고 있는 실제 폴더예요. 책상 위라고 생각해요.
• 스테이징 영역(Staging Area — git 이 속으로는 index 라고도 불러요): "이번 커밋엔 이것만 담을래" 하고 골라 담는 장바구니예요. git add 로 담아요. 가끔 명령 출력에 index 라고 뜨면 이 장바구니를 가리키는 거예요.
• 저장소: git commit 을 하면 장바구니에 담긴 게 커밋 하나로 영구 기록돼요. 앨범에 사진을 붙이는 거죠.

처음엔 "고친 거 그냥 다 저장하면 되지, 왜 굳이 장바구니에 골라 담아?" 싶을 거예요. 그런데 이 장바구니 단계가 현업에서 빛을 발해요. 한 번 작업하다 보면 여러 가지를 한꺼번에 고치게 되는데(로그인 버그도 고치고, 오타도 고치고, 색깔도 바꾸고), 그걸 의미 단위로 나눠서 커밋해야 나중에 역사가 읽혀요.

스테이징은 "고친 것 전부"가 아니라 "지금 이 커밋에 담을 것만" 정확히 고르게 해줘요. 현업에서 코드 리뷰를 받을 때, "이 커밋은 로그인 버그 수정"처럼 한 가지만 담겨 있으면 리뷰어가 훨씬 읽기 편하죠. 그 출발점이 바로 이 장바구니예요.

💡 한 줄 정리

Git 은 작업 폴더 → 스테이징 영역(장바구니) → 저장소의 세 공간으로 파일을 다루고, git add 로 담을 것만 골라 git commit 으로 한 장의 스냅샷을 남긴다.

Step 5: "첫 커밋을 찍어보자 — git add · git commit"

그림을 머리에 넣었으니 직접 해봐요. 먼저 일기 파일을 하나 만들어요. (에디터로 만들어도 되고, 터미널에서 한 줄로 만들어도 돼요.)

echo "오늘 Git 을 처음 배웠다." > diary.txt

이제 상태를 물어봐요.

git status
# 출력 예시:
# On branch main
# No commits yet
# Untracked files:
#   diary.txt

Untracked files — Git 이 "어, diary.txt 라는 새 파일이 보이는데 아직 내가 추적 안 하는 애야" 라고 알려주는 거예요. 이제 장바구니에 담아볼게요.

git add diary.txt
git status
# 출력 예시:
# Changes to be committed:
#   new file:   diary.txt

Changes to be committed 로 바뀌었죠? 장바구니에 담긴 거예요. 드디어 첫 커밋을 찍어요.

git commit -m "첫 일기 작성"
# 출력 예시:
# [main (root-commit) a1b2c3d] 첫 일기 작성
#  1 file changed, 1 insertion(+)

해냈어요! 방금 여러분은 인생 첫 커밋을 남겼어요. 출력을 잠깐 읽어볼까요. a1b2c3d 는 이 커밋의 고유한 이름표(해시, hash) 예요. 세상에 단 하나뿐인 지문 같은 거죠. -m 뒤의 "첫 일기 작성" 은 커밋 메시지 — "이 커밋에서 뭘 했는지" 설명이에요.

커밋은 그 순간 프로젝트 전체를 찍은 스냅샷(snapshot) 이에요. 다시 상태를 보면 깨끗해요.

git status
# 출력 예시:
# On branch main
# nothing to commit, working tree clean

working tree clean — "고친 것 없이 다 기록됐어" 라는 뜻이에요. 이 깨끗한 상태가 마음 편한 상태예요.

GUI 로는 — GitHub Desktop 에서 왼쪽 파일 목록의 체크박스를 켜는 게 git add, 아래 "Commit to main" 버튼이 git commit 이에요. VS Code 라면 Source Control 패널에서 파일 옆 + 가 add, 위쪽 ✓ 가 commit 이고요. 버튼이든 명령이든 하는 일은 똑같아요.

💡 한 줄 정리

git add 파일 로 장바구니에 담고 git commit -m "메시지" 로 한 장의 스냅샷을 남기면, 그 커밋은 고유한 해시와 설명 메시지를 갖는 영구 기록이 된다.

Step 6: "내가 걸어온 길 — git log"

커밋을 하나 더 쌓아볼게요. 일기에 한 줄을 더해요.

echo "둘째 날, git add 와 commit 을 익혔다." >> diary.txt
git add diary.txt
git commit -m "둘째 날 일기 추가"

이제 저장소에 커밋이 둘이 됐어요. 지금까지 걸어온 길을 봐요.

git log
# 출력 예시:
# commit 7f8e9d0a... (HEAD -> main)
# Author: Hong Soongu <hong@example.com>
# Date:   ...
#
#     둘째 날 일기 추가
#
# commit a1b2c3d4...
# Author: Hong Soongu <hong@example.com>
# Date:   ...
#
#     첫 일기 작성

내가 남긴 커밋이 최신순으로 쭉 나와요. 각 커밋의 해시·작성자·날짜·메시지가 다 보이죠. 그런데 이렇게 보면 좀 길어요. 한 줄로 요약해서 보는 옵션이 있어요.

git log --oneline
# 출력 예시:
# 7f8e9d0 둘째 날 일기 추가
# a1b2c3d 첫 일기 작성

훨씬 깔끔하죠? 해시 앞 7자리와 메시지만 보여줘요. 현업에선 이 git log 가 코드의 역사책이에요. "이 기능 언제 들어왔지?", "이 부분 누가 바꿨지?" 를 전부 여기서 찾아요. 신입이 낯선 프로젝트에 처음 투입되면, 제일 먼저 git log 로 그 코드가 걸어온 길을 읽어요.

다만 git log 가 콕 집어주지 못하는 게 하나 있어요. "바로 이 한 줄" 을 마지막으로 누가 바꿨는지예요. 그건 git blame 이라는 명령이 줄 단위로 짚어주는데, 심화 단계인 A-8 에서 만나요.

GUI 로는 — GitHub Desktop 의 "History" 탭, VS Code 의 Timeline 패널이 같은 역사를 보기 좋게 보여줘요.

💡 한 줄 정리

git log 는 지금까지 쌓은 커밋을 최신순으로 보여주는 역사책이고, git log --oneline 으로 해시와 메시지만 한 줄씩 깔끔하게 훑을 수 있다.

Step 7: "무엇이 바뀌었나 — git diff"

커밋하기 전에 "내가 뭘 바꿨더라?" 를 확인하고 싶을 때가 많아요. 그때 쓰는 게 git diff 예요. 일기를 또 고쳐볼게요. 이번엔 아직 add 하지 말고 상태만 봐요.

echo "셋째 날, git diff 로 변경을 확인했다." >> diary.txt
git diff
# 출력 예시:
# diff --git a/diary.txt b/diary.txt
# @@ ... @@
#  오늘 Git 을 처음 배웠다.
#  둘째 날, git add 와 commit 을 익혔다.
# +셋째 날, git diff 로 변경을 확인했다.

읽는 법은 간단해요. 맨 앞에 + 가 붙은 줄은 새로 추가된 줄, - 가 붙으면 지워진 줄이에요. 방금 한 줄을 더했으니 + 한 줄이 보이죠. 즉 git diff 는 "작업 폴더에서 고쳤지만 아직 장바구니에 안 담은 변경" 을 보여줘요.

그럼 장바구니에 담은 뒤엔요? add 를 하고 git diff 를 다시 치면 아무것도 안 나와요. 이미 담겼으니까요. 담긴 변경을 보려면 --staged 를 붙여요.

git add diary.txt
git diff
# (아무것도 안 나옴 — 작업 폴더와 장바구니가 같아서)

git diff --staged
# 출력 예시:
# +셋째 날, git diff 로 변경을 확인했다.

현업에선 커밋 버튼을 누르기 직전에 git diff 로 자기 점검을 해요. "엉뚱한 파일이 섞이진 않았나, 디버깅용으로 넣어둔 줄을 빼먹진 않았나" 를 확인하는 거죠. 이 습관 하나가 사고를 많이 막아줘요.

참고로 git diff HEAD~2 처럼 쓰면 "두 커밋 전과 지금" 을 비교할 수도 있어요. 브랜치끼리 비교하는 git diff 브랜치A..브랜치B 도 있는데, 브랜치는 다음 시간(A-2)에 배우니 그때 다시 만나요.

GUI 로는 — 사실 변경 비교는 GUI 가 빛나는 영역이에요. GitHub Desktop 이나 VS Code 는 바뀐 줄을 빨강·초록 색으로 좌우에 나란히 보여줘서, 글자만 있는 터미널보다 훨씬 한눈에 들어와요. 명령으로 원리를 알아두면 GUI 화면도 바로 읽혀요.

💡 한 줄 정리

git diff 는 아직 담지 않은 변경을, git diff --staged 는 장바구니에 담은 변경을 +(추가)·-(삭제)로 보여줘서, 커밋 전에 무엇이 바뀌었는지 점검하게 해준다.

Step 8: "6개월 뒤의 나를 구하는 커밋 메시지"

마지막으로, 명령은 아니지만 현업에서 진짜 중요한 이야기를 할게요. 바로 커밋 메시지 예요. 커밋할 때마다 적는 그 한 줄, 별것 아닌 것 같지만 여기서 신입과 고수가 갈려요.

이런 커밋 메시지들, 어떤가요?

 수정
 ㅇㅇ
 asdf
 버그 고침

당장은 편해요. 그런데 6개월 뒤에 git log 를 열어보면 재앙이에요. "수정"이 뭘 수정했다는 거지? "버그 고침"이면 어떤 버그? 과거의 내가 미래의 나에게 아무것도 안 알려준 거예요. 팀이라면 더해요 — 동료가 여러분의 "ㅇㅇ" 커밋을 보고 한숨을 쉬게 되죠.

좋은 메시지는 "무엇을 왜 바꿨는지" 를 한 줄로 말해줘요.

 로그인 실패 시 에러 메시지 표시 추가
 일기 목록을 최신순으로 정렬
 오타 수정: '안녕하세요' 맞춤법 교정

차이가 느껴지죠? 입문 단계에서 지킬 관습은 딱 두 가지예요. ① 첫 줄은 50자 안쪽으로 짧게 요약, ② "추가", "수정", "정렬" 처럼 무엇을 했는지가 드러나게. 이거면 충분해요. (팀마다 쓰는 더 엄격한 메시지 규칙도 있는데, 그건 협업을 배우는 A-6 에서 가볍게 다뤄요.)

너무 부담 갖진 마세요. 처음엔 누구나 "수정"이라고 써요. 오늘부터 한 줄에 조금만 더 신경 쓰는 것, 그게 6개월 뒤의 나와 미래의 팀 동료를 구하는 습관의 시작이에요.

💡 한 줄 정리

커밋 메시지는 미래의 나와 팀이 읽는 설명이므로, "수정" 같은 빈 메시지 대신 무엇을 했는지가 드러나는 한 줄 요약(50자 안쪽)으로 적는 습관을 들인다.

마무리

오늘 정말 많은 걸 했어요. 빈 폴더를 저장소로 만들고, 첫 커밋을 찍고, 역사를 읽고 비교하는 것까지 — 개발자가 매일 반복하는 가장 기본적인 호흡을 손에 익혔어요. 처음치고 훌륭해요.

오늘 배운 핵심 세 가지

• 💡 하나 — 버전 관리는 _최종 의 비극을 끝낸다. Git 은 파일이 바뀐 모든 순간을 기록해 되돌리기와 안전한 합치기를 가능하게 하고, Git(도구)과 GitHub(공유 공간)는 서로 다른 것이다.
• 💡 둘 — 세 개의 방과 add·commit. 작업 폴더에서 고친 것을 git add 로 장바구니에 담고 git commit 으로 한 장의 스냅샷(고유 해시 + 메시지)을 남긴다.
• 💡 셋 — 역사는 읽고 점검하는 것. git log 로 걸어온 길을 보고, git diff 로 무엇이 바뀌었는지 확인하며, 좋은 커밋 메시지로 미래의 나와 팀을 돕는다.

다음 시간 예고

지금까지 우리 일기의 역사는 한 줄기로 곧게 뻗어 있었어요. 첫 커밋 → 둘째 커밋 → 셋째 커밋, 이렇게요. 그런데 만약 "원래 일기는 그대로 두고, 새로운 형식을 실험해보고 싶다" 면 어떻게 할까요? 본체를 망가뜨리지 않고 평행 우주를 하나 만들어서 거기서 마음껏 실험한 뒤, 마음에 들면 본체에 합치는 거예요. 그게 바로 브랜치(branch) 예요.

다음 시간엔 이 브랜치를 따서 작업하고, 다시 본체에 합치는(merge) 법을 배워요. 그리고 현업 신입들이 가장 무서워하는 그것, 충돌(conflict) 도 정면으로 만나서 "사실 별거 아니구나" 를 같이 확인할 거예요. 한 줄기였던 역사가 가지를 치기 시작합니다.

과제

오늘 배운 건 머리로만 알면 손이 안 따라와요. 꼭 여러분 컴퓨터에서 직접 연습 저장소를 만들어 손으로 쳐보세요. 일기든 메모든 할 일 목록이든, 내용은 뭐든 좋아요.

[기초] 내 첫 저장소와 첫 두 커밋

빈 폴더 my-practice 를 만들어 git init 으로 저장소로 만드세요. 그 안에 파일 두 개(예: hello.txt, todo.txt)를 만들고, 각각 따로 의미 있는 메시지로 커밋해 커밋 두 개를 쌓으세요. 마지막에 git log --oneline 으로 두 커밋이 잘 남았는지 확인하고, 그 출력 두 줄을 적어 제출하세요. (On branch main 이 보이는지도 확인해보세요.)

[응용] 변경을 골라 담기 — diff 로 점검하고 의미 단위로 나누기

기초 과제의 저장소에서, 기존 파일 하나를 수정하고 새 파일 하나를 추가하세요(두 가지 변경을 동시에 만든 상황). 커밋하기 전에 git diff 로 무엇이 바뀌었는지 확인하세요. 그다음, 한꺼번에 담지 말고 수정한 파일만 먼저 add 해서 커밋하고, 새 파일은 그다음 커밋으로 분리하세요. 왜 이렇게 둘로 나눠 커밋하는 게 나중에 도움이 되는지 한두 문장으로 적어보세요.

[심화] 6개월 뒤의 동료가 읽을 히스토리 만들기

작은 시나리오를 하나 정하세요(예: "간단한 할 일 목록을 만들어가는 과정"). 그 과정을 커밋 네다섯 개로 남기되, 동료가 git log --oneline 만 봐도 무슨 작업을 어떤 순서로 했는지 스토리가 읽히도록 메시지를 쓰세요.

다 만든 뒤엔, 일부러 똑같은 작업을 "수정", "ㅇㅇ", "asdf" 같은 나쁜 메시지로 적은 버전과 나란히 비교해, 6개월 뒤의 나(혹은 팀 동료)에게 어느 쪽이 선물이 되는지 적어보세요.

생각해볼 주제

1. 스테이징(장바구니)은 왜 있을까 — 귀찮음 너머의 이유

많은 입문자가 git add 단계를 귀찮아해요. "고친 거 그냥 다 저장하면 되지" 싶죠. 만약 Git 에 스테이징 영역이 아예 없어서 작업 폴더에서 고친 것이 무조건 전부 커밋된다면, 팀으로 일할 때 어떤 곤란한 상황이 생길까요? 비밀번호가 적힌 파일이나, 아직 덜 끝낸 다른 작업까지 한 커밋에 섞이는 장면을 떠올려 보세요.

2. 좋은 커밋 메시지의 가치는 언제 드러나나

혼자 연습할 땐 커밋 메시지를 "수정"이라고 대충 써도 당장은 불편하지 않아요. 그렇다면 좋은 커밋 메시지가 진짜로 빛을 발하는 순간은 언제일까요? "미래의 나"와 "팀 동료"라는 두 독자를 떠올리면서, 좋은 메시지가 왜 그들에게 선물이 되는지 생각해 보세요.

3. Git 과 클라우드 자동 동기화의 결정적 차이

구글 드라이브 같은 클라우드도 파일을 자동 저장하고 일부 버전 기록도 남겨줘요. 그런데도 거의 모든 개발팀이 드라이브가 아니라 Git 으로 코드를 관리해요. 그 결정적인 이유는 무엇일까요? 오늘 본 세 가지 키워드 — 의미 단위 기록·정확한 되돌리기·충돌을 눈에 보이게 — 를 단서로 풀어 보세요.