A-2: 브랜치로 평행 우주 열고 다시 합치기

다시 만났어요, 홍순구 튜터입니다. 지난 시간 우리는 빈 폴더를 저장소로 만들고, 첫 커밋을 찍고, git log 로 걸어온 길을 읽는 것까지 했어요. 개발자가 매일 반복하는 가장 기본적인 흐름을 익혔죠. 잘 따라오셨어요.

그때 우리 일기의 역사는 한 줄기로 곧게 뻗어 있었어요. 첫 커밋 → 둘째 커밋 → 셋째 커밋, 이렇게 일직선으로요. 그런데 살다 보면 이런 순간이 와요. "원래 일기는 그대로 두고, 완전히 새로운 형식을 한번 실험해보고 싶다. 근데 잘못되면 원래대로 돌아가고 싶어." 한 줄기 역사 위에서 막 고치자니, 실험이 망하면 되돌리기가 번거롭죠.

그래서 오늘 우리는 가지를 칩니다. 본체(main)는 안전하게 그대로 두고, 옆에 평행 우주를 하나 열어서 거기서 마음껏 실험하는 거예요. 이게 바로 브랜치(branch) 입니다. 실험이 마음에 들면 본체에 합치고(merge), 마음에 안 들면 그 우주를 통째로 지워버리면 돼요. 본체는 손도 안 댔으니까요.

그리고 오늘, 현업 신입들이 가장 식은땀 흘리는 그것을 정면으로 만납니다. 바로 충돌(conflict) 이에요. 미리 한마디 할게요 — 충돌은 무서운 게 아니에요. Git 이 고장 난 것도, 여러분이 뭘 잘못한 것도 아니에요. "여기는 둘이 다르게 고쳤으니 네가 직접 골라줘" 하고 Git 이 정중하게 물어보는 것뿐이에요. 오늘 끝나면 "아, 이거였어? 별거 아니네" 하게 될 거예요. 같이 천천히 가요.

   오늘의 여정 — 가지를 치고, 다시 합치기

   ① 한 줄기였던 역사에 가지를 친다 — 브랜치란
   ② 가지를 만들고 옮겨 타기 — git branch · switch
   ③ 가지에서 일하고, 본체와 따로 노는지 확인
   ④ 가장 단순한 합치기 — fast-forward
   ⑤ 갈래가 벌어졌을 때 — 3-way 병합
   ⑥ 신입이 무서워하는 그것 — 충돌은 왜 생기나
   ⑦ 충돌을 손으로 풀기
   ⑧ 하던 일을 잠깐 접어두기 — git stash

①②③에서 브랜치를 만들고 옮겨 타며 "정말 따로 노는구나" 를 손으로 확인해요. ④⑤에서 합치는 두 가지 방법을 배우고, ⑥⑦에서 충돌을 만들고 직접 풀어봅니다. ⑧에서 "하던 일을 잠깐 접어두는" 편리한 도구로 가볍게 마무리해요.

💡 오늘 수업의 핵심 — "브랜치는 본체(main)를 건드리지 않고 평행 우주에서 마음껏 실험하게 해주고, 실험이 끝나면 git merge 로 다시 본체에 합친다. 두 갈래가 같은 곳을 고쳐 충돌이 나도, 사람이 직접 골라 안전하게 합치면 그만이다."

🎯 학습 목표

• 브랜치가 왜 필요한지(본체 보호·평행 실험)를 이해하고, git branch·git switch 로 가지를 만들고 옮겨 탑니다.
• 가지에서 작업한 변경을 git merge 로 본체에 합치고, fast-forward 와 3-way 병합이 어떻게 다른지 그래프로 구분합니다.
• 병합 충돌이 왜 생기는지 알고, 충돌 표시를 읽어 직접 해결하며, git stash 로 하던 일을 잠깐 접어둡니다.

Step 1: "한 줄기였던 역사에 가지를 친다 — 브랜치란"

먼저 그림으로 시작할게요. 지난 시간 우리가 쌓은 역사는 이렇게 한 줄기였어요. 커밋이 시간 순으로 이어진 점들이었죠.

   지난 시간까지 — 한 줄기 역사
   A───B───C        ← main

여기서 A, B, C 는 우리가 찍은 커밋이에요. 그리고 맨 오른쪽 ← main 이 중요해요. main 은 가장 최신 커밋 C 를 가리키는 이름표예요. 브랜치라는 게 사실 별게 아니에요. "어느 커밋을 가리키는 이름표" 일 뿐이에요. 지금까지 우리는 main 이라는 이름표 하나만 쓰고 있었던 거죠.

한 가지만 더 짚을게요. 이름표만 화살표를 갖는 게 아니에요. 커밋끼리도 서로를 가리켜요. 각 커밋은 자기 바로 앞(부모) 커밋을 가리키는 화살표를 속에 품고 있어서, git 은 최신 커밋 하나만 알면 거기서 부모를 거슬러 올라가며 전체 역사를 읽어내요. 우리가 그리는 A───B───C 화살표는 보기 좋으라고 시간 순으로 그린 거고, git 내부의 진짜 화살표는 그 반대로 자식이 부모를 가리키는 방향이에요.

이제 여기에 가지를 쳐볼게요. 본체는 그대로 두고, 새 이름표를 하나 더 만들어 실험용 우주를 여는 거예요.

   이번 시간 — 가지를 친다
   A───B───C        ← main (안정된 본체, 손 안 댐)
            \
             D───E  ← new-format (실험 중인 가지)

main 은 여전히 C 를 가리키며 안전하게 있고, new-format 이라는 새 가지에서 D, E 를 실험해요. 실험이 마음에 들면 main 에 합치고, 망하면 new-format 만 지우면 끝이에요. 본체는 처음부터 끝까지 안전했죠.

현업에선 이게 기본 중의 기본

현업에서 일하는 모습을 잠깐 그려볼게요. 팀의 main 브랜치는 항상 동작하는, 배포 가능한 상태로 지켜져요. 새 기능을 만들 땐 누구도 main 에서 바로 고치지 않아요. 대신 login-feature 같은 가지를 따서 거기서 만들고, 다 되면 합쳐요. 이렇게 하면 내가 기능을 만들다 코드가 반쯤 깨져 있어도, 본체 main 은 멀쩡하니 다른 동료들 작업에 지장이 없어요.

지금은 혼자 일기 저장소로 연습하지만, 이 "본체는 지키고 가지에서 실험한다" 는 감각이 나중에 팀으로 일할 때 그대로 쓰여요. 오늘 그 첫 단추를 끼우는 거예요.

💡 한 줄 정리

브랜치는 "어느 커밋을 가리키는 이름표" 일 뿐이고, 가지를 치면 본체(main)를 안전하게 둔 채 평행 우주에서 마음껏 실험한 뒤 마음에 들 때만 합칠 수 있다.

Step 2: "가지를 만들고 옮겨 타기 — git branch · git switch"

그림을 머리에 넣었으니 직접 가지를 쳐봐요. 지난 시간 만든 my-diary 저장소에서 이어가요. 먼저 지금 어떤 브랜치들이 있는지 물어봐요.

git branch
# 출력 예시:
# * main

* main 에서 별표(*)는 "지금 내가 여기 서 있다" 는 표시예요. 아직 가지가 main 하나뿐이죠. 이제 새 가지를 만들어요.

git branch new-format

조용히 만들어졌어요. 다시 목록을 보면 둘이 됐어요.

git branch
# 출력 예시:
#   new-format
# * main

가지는 생겼는데, 별표는 아직 main 에 있죠? 만든 것과 그리로 옮겨 타는 건 다른 일이에요. new-format 으로 갈아타볼게요.

git switch new-format
# 출력 예시:
# Switched to branch 'new-format'

이제 별표가 옮겨갔어요.

git branch
# 출력 예시:
# * new-format
#   main

방금 무슨 일이 일어난 걸까요? 그림으로 보면 이래요. 아직 새 커밋을 안 찍었으니 두 이름표는 같은 커밋을 가리켜요. 달라진 건 "지금 내가 선 곳" 뿐이에요.

   switch 전:  지금 위치 → main
   switch 후:  지금 위치 → new-format

   A───B───C   ← main, new-format 이 둘 다 여기를 가리킴
               (아직 안 갈라짐. '지금 위치' 만 new-format 으로 옮겨감)

한 줄로 줄이는 단축법, 그리고 checkout 이야기

"만들고 → 옮겨 타기" 두 번이 번거롭죠? -c 옵션(create)을 쓰면 만들면서 곧장 갈아타기 가 한 줄로 돼요. 현업에서 가장 많이 쓰는 형태예요.

git switch -c new-format
# 출력 예시:
# Switched to a new branch 'new-format'

여기서 한 가지 짚고 갈게요. 오래된 자료나 동료의 화면을 보면 git checkout 이라는 명령을 자주 볼 거예요. 예전엔 하나의 checkout 명령이 너무 많은 일(브랜치 이동 + 파일 되돌리기)을 했어요.

헷갈리기 쉬워서, 요즘 Git 은 이걸 둘로 쪼갰어요 — 브랜치를 옮겨 타는 건 git switch, 파일을 되돌리는 건 git restore(다음 시간에 배워요). 그래서 우리는 더 또렷한 switch 를 1순위로 쓸게요.

checkout 도 여전히 잘 동작하니, 동료가 쓰는 걸 봐도 "아, switch 와 같은 거구나" 하면 돼요.

GUI 로는 — GitHub Desktop 이나 VS Code 화면 왼쪽 아래(또는 위쪽)에 현재 브랜치 이름이 늘 떠 있어요. 그걸 클릭하면 브랜치 목록이 뜨고, "New Branch" 로 만들거나 목록에서 골라 갈아탈 수 있어요. 방금 우리가 친 git branch + git switch 와 똑같은 일이에요.

💡 한 줄 정리

git branch 이름 으로 가지를 만들고 git switch 이름 으로 옮겨 타며(git switch -c 로 한 번에), 옮겨 타기 전까지는 새 가지도 같은 커밋을 가리킬 뿐 "지금 내가 선 곳" 만 바뀐다.

Step 3: "가지에서 일하고, 본체와 따로 노는지 확인"

가지를 만들었으니 거기서 진짜로 일을 해봐요. 정말 본체와 따로 노는지 두 눈으로 확인하는 게 이번 Step 의 목표예요. new-format 가지에 서 있는 상태에서, 일기에 새 형식을 한 줄 더해 커밋해요.

git switch new-format
echo "[새 형식] 2026-06-15 / 날씨: 맑음 / 기분: 좋음" >> diary.txt
git add diary.txt
git commit -m "일기에 새로운 형식(날짜/날씨/기분) 시험 적용"

자, 이제 가지에서 커밋을 하나 찍었어요. 그림으로는 이렇게 갈라진 거예요.

   A───B───C        ← main (그대로 C 에 머물러 있음)
            \
             D       ← new-format ← 지금 위치 (방금 찍은 커밋)

여기서 가장 중요한 확인을 해봐요. 본체(main)로 돌아가면, 방금 더한 줄이 정말 사라져 있을까요?

git switch main
cat diary.txt
# 출력 예시:
# 오늘 Git 을 처음 배웠다.
# 둘째 날, git add 와 commit 을 익혔다.
# (방금 더한 '[새 형식]' 줄이 안 보임!)

신기하죠? main 으로 오니 diary.txt 가 새 형식 줄을 더하기 전 모습으로 돌아와 있어요. 파일을 누가 지운 게 아니에요. new-format 가지의 변경은 그 우주에만 있고, main 우주는 그 일을 모르는 거예요. 진짜 평행 우주처럼 따로 노는 거죠.

다시 new-format 으로 가면 그 줄이 되살아나요.

git switch new-format
cat diary.txt
# 출력 예시:
# 오늘 Git 을 처음 배웠다.
# 둘째 날, git add 와 commit 을 익혔다.
# [새 형식] 2026-06-15 / 날씨: 맑음 / 기분: 좋음   ← 돌아옴!

git switch 로 가지를 옮길 때마다 작업 폴더의 파일 내용이 그 가지의 모습으로 통째로 바뀌어요. 이게 브랜치의 핵심이에요. 한 폴더 안에서 여러 평행 우주를 오가며 일하는 거죠.

💡 한 줄 정리

가지에서 커밋한 변경은 그 가지에만 존재하고, git switch 로 본체에 돌아가면 작업 폴더가 본체의 모습으로 통째로 바뀌어 두 브랜치가 서로 독립적으로 따로 논다.

Step 4: "가장 단순한 합치기 — fast-forward"

실험이 마음에 들었다고 해봐요. 이제 new-format 의 변경을 본체 main 에 합칠(merge) 차례예요. 합치기엔 두 가지 모양이 있는데, 오늘은 가장 단순한 것부터 봐요.

규칙은 간단해요. 합쳐 받을 쪽(본체)으로 먼저 가서, 가져올 가지를 merge 한다. 우리는 main 에 new-format 을 합칠 거니까, main 으로 가서 merge 해요.

git switch main
git merge new-format
# 출력 예시:
# Updating c3d4e5f..3c4d5e6
# Fast-forward
#  diary.txt | 1 +
#  1 file changed, 1 insertion(+)

출력에 Fast-forward 라는 말이 보이죠? 이게 가장 단순한 병합이에요. 왜 "빨리 감기(fast-forward)" 라고 부를까요? 그림을 보면 단번에 이해돼요.

   병합 전 — main 은 C 에 그대로, 가지에 D 가 있음
   A───B───C        ← main
            \
             D       ← new-format

   git merge new-format (fast-forward) — main 이름표가 D 로 미끄러져 따라감
   A───B───C───D     ← main, new-format
   (새 커밋 안 생김. main 이름표만 앞으로 이동)

main 이 가지를 친 뒤로 한 발짝도 안 움직였기 때문에, 합칠 게 따로 없어요. Git 은 그냥 main 이름표를 D 로 쓱 옮기기만 하면 돼요. 마치 비디오를 빨리 감듯이요. 그래서 새 병합 커밋도 안 생기고, 역사가 한 줄로 깔끔하게 이어져요.

합쳤으니 이제 new-format 가지는 역할을 다했어요. 가지를 정리해요.

git branch -d new-format
# 출력 예시:
# Deleted branch new-format (was 3c4d5e6).

-d 는 delete 예요. "어, 가지를 지워도 괜찮나요? 작업이 사라지는 거 아니에요?" 걱정 마세요. new-format 의 커밋 D 는 이미 main 에 합쳐졌으니, 이름표만 떼는 거예요. 내용은 main 에 멀쩡히 남아 있어요.

혹시 아직 안 합친 가지를 -d 로 지우려 하면, Git 이 "이거 합친 적 없는데 정말 지울 거야?" 하고 막아줘요. 그만큼 안전장치가 있다는 뜻이에요. (정말 버리고 싶을 때 강제로 지우는 법, 그리고 실수로 지운 걸 되살리는 법은 다음 시간에 배워요.)

GUI 로는 — GitHub Desktop 의 "Branch" 메뉴에서 "Merge into current branch" 를 고르면 방금 한 merge 와 똑같아요. 합친 뒤 브랜치 목록에서 가지를 우클릭해 "Delete" 하면 git branch -d 고요.

💡 한 줄 정리

합쳐 받을 본체로 가서 git merge 가지 를 하면 합쳐지고, 본체가 가지를 친 뒤 움직이지 않았다면 이름표만 앞으로 옮기는 fast-forward 로 새 커밋 없이 한 줄로 이어진다.

Step 5: "갈래가 벌어졌을 때 — 3-way 병합"

방금 fast-forward 는 본체가 안 움직였을 때의 이야기였어요. 그런데 현업에선 더 흔한 상황이 있어요. 내가 가지에서 일하는 동안, 본체도 따로 전진하는 경우예요. 팀에선 내가 기능을 만드는 사이 동료가 main 에 다른 걸 합치니까요.

직접 그 상황을 만들어봐요. main 에서 새 가지 add-weather 를 따서 날씨 파일을 추가해요.

git switch -c add-weather
echo "맑음 / 22도" > weather.txt
git add weather.txt
git commit -m "weather.txt 추가: 날씨 기록 파일 분리"

이제 본체도 전진시켜요. main 으로 돌아가 다른 파일을 고쳐 커밋해요. (가지에서 만진 weather.txt 가 아니라 diary.txt 를 건드려요 — 일부러 서로 다른 파일을.)

git switch main
echo "둘째 줄: 오늘은 브랜치를 배웠다." >> diary.txt
git add diary.txt
git commit -m "diary: 브랜치 학습 기록 추가"

이제 양쪽이 각자 다른 방향으로 한 발짝씩 갔어요. 이 상태에서 합치면 어떻게 될까요?

git merge add-weather
# (편집기가 열리며 병합 커밋 메시지를 묻는다 — 기본값 "Merge branch 'add-weather'" 그대로 저장)
# 출력 예시:
# Merge made by the 'ort' strategy.
#  weather.txt | 1 +
#  1 file changed, 1 insertion(+)

이번엔 Fast-forward 가 아니라 Merge made by ... 가 떴어요. 그리고 fast-forward 때와 달리, 병합 커밋(merge commit) 이라는 새 커밋이 하나 생겼어요. 왜 그럴까요? 그림으로 두 경우를 나란히 봐요.

   ① fast-forward — 본체가 안 움직였을 때
      가지를 친 뒤 main 이 그대로면 이름표만 앞으로.
      A───B───C───D       ← 한 줄로 깔끔

   ② 3-way 병합 — 양쪽이 각자 전진했을 때
      main 도 F 로 가고, 가지도 E 로 갔다면 합류점 M 이 생긴다.
      A───B───C───F───M   ← main
               \     /
                E───┘   (M = 병합 커밋)

①은 본체가 안 움직여서 그냥 따라가면 됐죠. 그런데 ②는 main(F)과 가지(E)가 갈라진 두 갈래예요. 이 둘을 하나로 모으려면, "양쪽을 다 품은 새 합류 지점" 이 필요해요. 그게 병합 커밋 M 이에요. Git 은 갈라지기 전 공통 조상(C)과 양쪽 끝(F, E) 세 지점을 비교(three-way) 해서 합치기 때문에 3-way 병합이라고 불러요.

그리고 현업 팀에선 이 3-way 병합이 사실 더 흔해요. 내가 가지에서 기능을 만드는 동안 동료들도 main 에 자기 작업을 계속 합치니까, 합칠 때쯤이면 본체가 이미 저만치 전진해 있거든요. 그래서 양쪽이 갈라진 3-way 병합이 자연스럽게 일어나요. 다음 과목들에서 코드를 GitHub 에 올려 협업할 때 병합 커밋이 자주 보이는 건 그래서예요.

겁먹을 거 없어요. 서로 다른 파일을 고쳤다면(우리처럼 weather.txt vs diary.txt), Git 이 알아서 둘 다 살려서 깔끔하게 합쳐줘요. 병합 커밋 메시지는 기본값을 그냥 써도 충분하고요. 합친 역사를 한번 볼까요?

git log --oneline --graph
# 출력 예시:
# *   8a9b0c1 Merge branch 'add-weather'
# |\
# | * 5e6f7a8 weather.txt 추가: 날씨 기록 파일 분리
# * | 2b3c4d5 diary: 브랜치 학습 기록 추가
# |/
# * 3c4d5e6 일기에 새로운 형식(날짜/날씨/기분) 시험 적용

--graph 를 붙이면 갈래가 갈라졌다 합쳐지는 모양이 글자로 그려져요. 왼쪽의 * 와 선들이 아까 그림이랑 똑 닮았죠?

💡 한 줄 정리

본체와 가지가 각자 전진해 갈라졌을 땐 양쪽을 품는 병합 커밋(M) 이 새로 생기는 3-way 병합이 일어나고, 서로 다른 곳을 고쳤다면 Git 이 알아서 둘 다 살려 합쳐준다.

Step 6: "신입이 무서워하는 그것 — 충돌은 왜 생기나"

자, 드디어 오늘의 클라이맥스예요. 현업 신입들이 첫 주에 가장 식은땀 흘리는 그것, 충돌(conflict) 입니다. 먼저 안심부터 시키고 갈게요. 충돌은 에러가 아니에요. 여러분이 뭘 잘못한 것도 아니에요. 그냥 Git 이 혼자 판단하기 곤란한 상황에서 "이건 사람인 네가 골라줘" 하고 정중히 멈춰 서는 것뿐이에요.

언제 생길까요? Step 5 에선 양쪽이 서로 다른 파일을 고쳐서 Git 이 알아서 합쳤죠. 충돌은 그 반대예요. 두 갈래가 같은 파일의 같은 줄을 서로 다르게 고쳤을 때 생겨요. Git 입장에선 "둘 중 누구 말을 들어야 하지?" 알 수가 없는 거죠.

직접 만들어봐요. 먼저 본체에 제목 파일을 하나 만들어 공통 출발점을 깔아요.

git switch main
echo "제목: 나의 일기" > title.txt
git add title.txt
git commit -m "title.txt 추가: 일기 제목"

이제 가지를 따서, 가지에서는 제목을 "성장 일기" 로 바꿔요.

git switch -c edit-title
echo "제목: 나의 성장 일기" > title.txt
git add title.txt
git commit -m "제목을 '성장 일기'로 변경"

그리고 본체로 돌아와, 같은 줄을 "코딩 일기" 로 다르게 바꿔요.

git switch main
echo "제목: 나의 코딩 일기" > title.txt
git add title.txt
git commit -m "제목을 '코딩 일기'로 변경"

같은 title.txt 의 같은 줄을, 한쪽은 "성장 일기", 한쪽은 "코딩 일기" 로 고친 거예요. 이제 합쳐봐요.

git merge edit-title
# 출력 예시:
# Auto-merging title.txt
# CONFLICT (content): Merge conflict in title.txt
# Automatic merge failed; fix conflicts and then commit the result.

CONFLICT 가 떴어요! 처음 보면 가슴이 철렁하죠. 그런데 마지막 줄을 읽어보세요. "fix conflicts and then commit the result" — "충돌을 고치고 나서 커밋해" 라고 Git 이 친절하게 다음 할 일을 알려주고 있어요. 무서운 게 아니라 안내문이에요.

파일을 열어보면 Git 이 표시를 남겨놨어요.

cat title.txt
# 출력 예시:
# <<<<<<< HEAD
# 제목: 나의 코딩 일기
# =======
# 제목: 나의 성장 일기
# >>>>>>> edit-title

처음엔 외계어 같지만, 읽는 법은 정말 간단해요.

   <<<<<<< HEAD
   제목: 나의 코딩 일기        ← 지금 내 브랜치(main, HEAD)의 내용
   =======
   제목: 나의 성장 일기        ← 합치려는 브랜치(edit-title)의 내용
   >>>>>>> edit-title

   ─── 가운데 ======= 를 경계로, 윗칸은 '나', 아랫칸은 '상대' ───
   ─── 둘 중 무엇을 남길지 사람이 직접 고른다 ───

<<<<<<< 부터 ======= 까지가 현재 내 브랜치(HEAD, 여기선 main) 의 내용, ======= 부터 >>>>>>> 까지가 합치려는 가지(edit-title) 의 내용이에요. Git 이 "이 두 개가 부딪혔어. 어느 걸 남길래? 아니면 둘을 섞을래?" 하고 양쪽을 다 보여주는 거예요. 결정은 사람 몫이고요.

이번 Step 에선 충돌이 왜, 어떻게 생기는지, 그리고 이 표시를 읽는 법까지 익혔어요. 실제로 고르고 마무리하는 건 바로 다음 Step 에서 해요.

💡 한 줄 정리

충돌은 에러가 아니라 두 갈래가 같은 파일의 같은 줄을 다르게 고쳐 Git 이 사람에게 결정을 넘기는 상황이고, <<<<<<< / ======= / >>>>>>> 표시로 내 쪽과 상대 쪽 내용을 나란히 보여준다.

Step 7: "충돌을 손으로 풀기"

충돌 표시를 읽었으니, 이제 풀 차례예요. 푸는 건 생각보다 싱거워요. 딱 두 단계예요 — ① 파일을 열어 원하는 모습으로 고치고(표시 지우기), ② add 하고 commit 한다.

지금 title.txt 는 이 상태죠.

<<<<<<< HEAD
제목: 나의 코딩 일기
=======
제목: 나의 성장 일기
>>>>>>> edit-title

여기서 우리가 할 일은, <<<<<<<, =======, >>>>>>> 세 줄을 모두 지우고, 최종적으로 남기고 싶은 내용만 남기는 거예요. "코딩 일기" 를 고를 수도, "성장 일기" 를 고를 수도, 아니면 둘을 합쳐 새로 쓸 수도 있어요. 우리는 둘을 합쳐볼게요. 편집기로 파일을 이렇게 고쳐요.

제목: 나의 코딩 성장 일기

표시 세 줄이 싹 사라지고, 깔끔한 한 줄만 남았죠? 이제 충돌이 풀렸는지 상태를 물어봐요.

git status
# 출력 예시:
# On branch main
# You have unmerged paths.
#   (fix conflicts and run "git commit")
# Unmerged paths:
#   both modified:   title.txt

both modified — "양쪽이 다 고친 파일" 이라는 표시예요. 이제 해결한 파일을 add 로 담아 "이거 다 풀었어" 라고 Git 에게 알려주고, 커밋으로 마무리해요.

git add title.txt
git commit -m "제목 충돌 해결: '코딩 성장 일기'로 통합"

끝났어요! 방금 그 커밋이 바로 병합 커밋이에요. 충돌을 직접 풀어 합류 지점을 만든 거죠. git log --oneline --graph 로 보면 갈래가 다시 하나로 모인 게 보여요. 어때요, 막상 해보니 "별거 아니네" 싶죠?

⚠️ 참고: 커밋 메시지에 -m 을 안 붙이고 그냥 git commit 만 쳐도 돼요. 그러면 Git 이 Merge branch 'edit-title' 같은 기본 메시지를 미리 채운 편집기를 띄워줘요. 그대로 저장해도 되고요.

도망칠 구멍도 있어요 — git merge --abort

충돌을 보자마자 "아, 지금 이거 풀 상황이 아닌데" 싶을 때도 있어요. 그럴 땐 병합을 시작하기 전으로 통째로 되돌릴 수 있어요.

git merge --abort
# (병합을 취소하고, merge 치기 직전의 깨끗한 상태로 되돌아감)

이 한 줄이면 충돌 표시고 뭐고 싹 사라지고, merge 를 누르기 전 상태로 돌아가요. 그러니 충돌이 나도 절대 갇히는 게 아니에요. 언제든 빠져나와 마음을 가다듬고 다시 시도하면 돼요. 이렇게 "잘못돼도 되돌릴 수 있다" 는 안전망이 있다는 게 중요해요 — 사실 다음 시간 전체가 이 "되돌리기" 이야기예요. 실수한 변경, 잘못 찍은 커밋, 심지어 지워버린 것까지 되살리는 구조대를 배울 거예요.

GUI 로는 — VS Code 는 충돌 난 파일을 열면 Accept Current(내 쪽) · Accept Incoming(상대 쪽) · Accept Both(둘 다) 버튼을 충돌 위에 직접 띄워줘요. 클릭 한 번으로 고르고, 저장한 뒤 커밋하면 끝이에요. 명령으로 원리를 알아두면 이 버튼들이 무슨 일을 하는지 바로 읽혀요.

💡 한 줄 정리

충돌은 <<<<<<< ======= >>>>>>> 표시를 지우고 원하는 내용만 남긴 뒤 git add → git commit 으로 풀고, 풀기 싫으면 git merge --abort 로 병합 직전 상태로 안전하게 되돌릴 수 있다.

Step 8: "하던 일을 잠깐 접어두기 — git stash"

마지막은 현업에서 정말 자주 쓰는 편리한 도구예요. 이런 상황을 상상해봐요. 일기 새 기능을 한창 만드는 중인데, 아직 커밋하긴 일러요(반쯤 했거든요). 그런데 갑자기 "급한 거 하나만 봐줘" 하고 다른 일이 끼어들어요. 다른 브랜치로 옮겨가야 하는데, 하던 작업은 어쩌죠? 커밋하자니 반쪽짜리고, 버리자니 아깝고.

이럴 때 쓰는 게 git stash 예요. "하던 일을 잠깐 서랍에 넣어두기" 라고 생각하면 돼요. 고치던 중인 변경을 일단 보관함에 치워서 작업 폴더를 깨끗하게 만드는 거죠.

# diary.txt 를 한창 고치는 중... 아직 커밋하긴 이른 상태
git stash
# 출력 예시:
# Saved working directory and index state WIP on main: 8a9b0c1 ...

이제 git status 를 보면 작업 폴더가 깨끗해요. 고치던 변경이 보관함으로 들어가 잠시 사라진 거예요. 이 상태로 자유롭게 다른 브랜치로 옮겨 급한 일을 처리하면 돼요. 보관함에 뭐가 들었는지는 이렇게 봐요.

git stash list
# 출력 예시:
# stash@{0}: WIP on main: 8a9b0c1 ...

급한 일을 다 끝냈으면, 접어뒀던 작업을 다시 꺼내요.

git stash pop
# (보관함에 넣어둔 변경이 작업 폴더로 되살아나고, 보관함에선 빠짐)

pop 하면 아까 고치던 그 모습 그대로 돌아와요. 하던 일을 이어서 하면 되죠. 흐름을 그림으로 보면 이래요.

   git stash       : 고치던 것을 보관함에 잠깐 치워두기 (작업 폴더 깨끗해짐)
   git stash pop   : 보관함에서 다시 꺼내 작업 폴더로

   [ 작업 폴더 ] ---- stash ----> [ 보관함 ]
   [ 작업 폴더 ] <---- pop ------ [ 보관함 ]

한 가지 알아둘 점. git stash pop 으로 꺼낼 때 그새 그 파일이 바뀌어 있으면 충돌이 날 수 있어요. 이땐 앞에서 배운 병합 충돌과 똑같이 <<<<<<< 표시를 정리하면 돼요. 그리고 보관함은 여러 개를 쌓을 수 있어서, git stash list 로 목록을 보고 특정 항목만 꺼낼 땐 git stash apply stash@{1} 처럼 번호로 골라요.

GUI 로는 — GitHub Desktop 은 "Branch > Stash changes" 로 접어두고, "Stashed changes" 에서 다시 꺼낼 수 있어요. VS Code 도 Source Control 메뉴에 Stash 항목이 있고요.

💡 한 줄 정리

git stash 는 아직 커밋하기 이른 변경을 잠깐 보관함에 치워 작업 폴더를 깨끗이 비우고, git stash pop 으로 다시 꺼내 이어서 작업하게 해주는 "임시 서랍" 이다.

마무리

오늘 정말 큰 산을 넘었어요. 한 줄기였던 역사에 가지를 치고, 평행 우주에서 실험하고, 다시 본체에 합치고, 그리고 신입들이 가장 무서워한다는 충돌까지 직접 만들어 풀어봤어요. 어때요, 막상 해보니 충돌도 "별거 아니네" 싶죠? 그 감각이 오늘의 가장 큰 수확이에요.

오늘 배운 핵심 세 가지

• 💡 하나 — 브랜치는 평행 우주다. git switch -c 로 가지를 따면 본체(main)를 안전하게 둔 채 실험할 수 있고, 가지를 옮길 때마다 작업 폴더가 그 가지의 모습으로 바뀐다.
• 💡 둘 — 합치기엔 두 모양이 있다. 본체가 안 움직였으면 이름표만 옮기는 fast-forward, 양쪽이 갈라졌으면 합류점(병합 커밋)을 만드는 3-way 병합이 일어난다.
• 💡 셋 — 충돌은 에러가 아니라 안내다. 같은 줄을 다르게 고치면 충돌이 나고, <<<<<<< ======= >>>>>>> 표시를 지워 원하는 내용만 남긴 뒤 add·commit 으로 풀면 된다. git merge --abort 라는 도망칠 구멍도 늘 있다.

다음 시간 예고

오늘 git merge --abort 로 "병합을 통째로 되돌리는" 안전망을 살짝 맛봤죠? 사실 그건 시작일 뿐이에요. 다음 시간엔 "되돌리기" 를 통째로 배웁니다. 방금 고친 걸 커밋 전으로 돌리는 git restore, 잘못 찍은 커밋을 되감는 git reset, 이미 공유한 커밋을 안전하게 취소하는 git revert — 상황에 맞는 되돌리기를 골라 쓰는 법을 익혀요.

그리고 git 의 진짜 안전망을 만나요. 실수로 가지를 지웠거나 커밋을 날린 것 같아도, git reflog 라는 구조대가 잃어버린 커밋을 되살려줘요. "되돌릴 수 있다" 는 이 믿음이 있어야 과감하게 실험할 수 있거든요. 거기에 비밀번호 같은 건 아예 추적에서 빼버리는 .gitignore 까지 — 다음 시간은 "실수해도 괜찮은 개발자" 가 되는 시간이에요.

과제

오늘 배운 건 눈으로만 보면 절대 안 익어요. 꼭 여러분 컴퓨터에서 직접 가지를 따고, 합치고, 충돌을 내보세요. 충돌은 일부러 만들어 풀어봐야 무서움이 사라져요.

[기초] 가지를 따서 작업하고 fast-forward 로 합치기

연습 저장소에서 git switch -c practice-1 로 가지를 만들고, 거기서 파일을 고쳐 커밋 두 개를 쌓으세요. (이 동안 main 은 건드리지 않습니다.) 그다음 git switch main 으로 본체에 돌아가 git merge practice-1 로 합치세요.

출력에 Fast-forward 가 떴는지 확인하고, 왜 이번엔 병합 커밋이 안 생겼는지 한 문장으로 설명해보세요. 마지막으로 git branch -d practice-1 로 가지를 정리하세요.

[응용] 일부러 충돌을 내고 손으로 풀기

같은 파일(note.txt)의 같은 줄을, main 과 새 가지 practice-2 에서 서로 다르게 고쳐 커밋하세요. 그리고 main 에서 git merge practice-2 를 해서 충돌을 일부러 일으키세요. 충돌 표시(<<<<<<< 등)를 읽고, 표시를 모두 지워 최종 내용을 정한 뒤 git add → git commit 으로 해결하세요.

해결을 마쳤다면, 한 번 더 충돌을 만든 다음 이번엔 git merge --abort 로 병합을 취소해보세요. 작업 폴더가 충돌 전 깨끗한 상태로 돌아오는 걸 눈으로 확인하고, "충돌이 나도 갇히지 않는다" 는 게 어떤 안심을 주는지 한두 문장으로 적어보세요.

[심화] 팀 상황을 상상하며 stash 써보기

이런 팀 상황을 떠올려보세요. "기능을 한창 만드는 중인데, 갑자기 '급한 버그 하나만 먼저 고쳐달라' 는 요청이 왔다. 지금 작업은 반쯤 됐다." 이 상황을 git stash 로 처리해보세요 — 하던 작업을 stash 로 접어두고, main 에서 급한 수정을 한 커밋으로 처리한 뒤, git stash pop 으로 원래 작업을 되살려 이어가세요.

그리고 한 가지 생각해보세요. 여럿이 같은 main 을 공유하며 일하는 팀이라면, 합칠 때 fast-forward 와 3-way 병합 중 어느 쪽이 더 자주 생길까요? 왜 그럴지 한두 문장으로 적어보세요. (힌트: 내가 가지에서 일하는 동안 동료들도 main 에 무언가를 합치고 있어요.)

생각해볼 주제

1. 왜 main 에서 바로 안 고치고 굳이 가지를 따나

혼자 연습할 땐 main 에서 바로 고쳐도 당장은 불편하지 않아요. 그런데 거의 모든 개발팀이 "새 작업은 반드시 가지를 따서 한다" 는 규칙을 둬요. 만약 팀원 다섯 명이 모두 같은 main 에서 동시에 코드를 고친다면 어떤 일이 벌어질까요? 본체를 "항상 동작하는 상태" 로 지키는 게 왜 협업에서 그렇게 중요한지, 가지를 따로 두는 것이 그걸 어떻게 가능하게 하는지 생각해보세요.

2. 충돌은 왜 "에러" 가 아니라 "정상" 일까

많은 입문자가 충돌을 보면 "내가 뭘 잘못했나" 하고 겁부터 먹어요. 그런데 충돌은 사실 Git 이 일부러 멈춰서 사람에게 결정을 넘기는 거예요. 지난 시간 배운 클라우드 자동 동기화(둘이 같은 파일을 고치면 한쪽을 조용히 덮어쓰는 것)와 비교해보세요. Git 이 충돌을 "숨기지 않고 드러내는" 선택을 한 덕분에 우리가 얻는 게 무엇인지, 왜 그게 팀 작업에서 더 안전한 길인지 풀어보세요.

3. "되돌릴 수 있다" 는 믿음이 주는 힘

오늘 우리는 git merge --abort 로 병합을 취소하고, 합친 가지를 git branch -d 로 지워도 내용은 본체에 남는 걸 봤어요. 이렇게 "잘못해도 되돌릴 수 있다" 는 안전망이 있을 때와 없을 때, 사람이 실험에 임하는 태도는 어떻게 달라질까요? 안전망이 오히려 더 과감하고 자유로운 시도를 가능하게 한다는 점을, 여러분이 코드를 짤 때(혹은 다른 어떤 일을 할 때)의 경험과 엮어 생각해보세요.