가족이 같이 쓰는 달력이 냉장고에 붙어 있다고 해봅니다. 15일 칸에 누가 "병원" 이라고 적어놨는데, 다른 사람이 같은 칸에 "이사" 라고 적었습니다. 칸은 하나고 글씨는 둘입니다.

이럴 때 달력이 알아서 정해주지 않습니다. 사람이 정해야 합니다. 둘 중 하나를 지우든, 둘 다 남기든, 둘을 합쳐 "병원 갔다가 이사" 라고 쓰든. 어느 쪽이 맞는지는 달력이 알 수 없는 정보입니다.

깃도 똑같습니다. 22강에서 합치기가 너무 쉽게 끝났던 건 한쪽만 움직였기 때문입니다. 양쪽이 같은 줄을 건드리면 깃은 그 자리에서 멈추고 사람을 부릅니다. 그게 충돌입니다.

이번 시간에는 충돌을 일부러 냅니다. 나중에 팀에서 처음 만나면 당황하니까, 안전할 때 미리 겪어봅니다.

알아서 합칩니다

• 서로 다른 파일을 고쳤다
• 같은 파일이라도 서로 다른 줄을 고쳤다
• 한쪽만 고치고 다른 쪽은 가만있었다
• 이 경우가 실제로 훨씬 많습니다

손을 듭니다

• 같은 파일의 같은 줄을 양쪽이 다르게 고쳤다
• 한쪽은 고치고 한쪽은 그 줄을 지웠다
• 깃은 어느 쪽이 맞는지 판단할 수 없습니다
• 그래서 멈추고 물어봅니다

이 구분이 오늘의 절반입니다. 충돌은 자주 나지 않습니다. 같은 파일을 둘이 만져도 줄이 겹치지 않으면 조용히 합쳐집니다.

일부러 충돌을 냅니다

README.md 의 첫 줄, 그러니까 제목 줄을 두 곳에서 다르게 고칩니다.

1. 01

   master 에 서 있는지 확인합니다

   22강 끝에서 master 하나만 남아 있어야 합니다

   git branch

2. 02

   가지를 하나 만듭니다

   git switch -c fix-title

3. 03

   README.md 첫 줄을 고칩니다

   # 내 첫 저장소 를 # 깃 공부 기록 으로 바꾸고 저장합니다

4. 04

   담고 커밋합니다

   git add README.md
   git commit -m "제목을 깃 공부 기록으로 변경"

5. 05

   master 로 돌아갑니다

   첫 줄이 다시 # 내 첫 저장소 로 돌아와 있습니다. 21강에서 본 그 현상입니다

   git switch master

6. 06

   여기서도 첫 줄을 고칩니다

   이번엔 # 내 첫 저장소 — 2026 으로 바꾸고 저장합니다. 아까와 같은 줄입니다

7. 07

   담고 커밋합니다

   git add README.md
   git commit -m "제목에 연도 추가"

이제 양쪽이 다 움직였습니다. 22강처럼 이름표만 옮겨서는 끝나지 않는 상태입니다. 합쳐봅니다.

• $ git merge fix-title
• Auto-merging README.md
• CONFLICT (content): Merge conflict in README.md
• Automatic merge failed; fix conflicts and then commit the result.

빨간 글씨가 떴습니다. 여기서 대부분 얼어붙습니다.

아무것도 안 망가졌습니다. 저 세 줄은 순서대로 이렇게 말하고 있습니다. "README.md 를 자동으로 합쳐보려 했다 → 내용이 겹쳐서 못 했다 → 네가 고친 다음에 커밋해라." 16강에서 말한 대로, 영어 여러 줄이 나와도 한 줄씩 뜯어보면 별말이 아닙니다.

지금 상태를 봅니다

막혔을 때 칠 명령은 늘 같습니다.

• $ git status
• On branch master
• You have unmerged paths.
• (fix conflicts and run "git commit")
• (use "git merge --abort" to abort the merge)
• Unmerged paths:
• (use "git add <file>..." to mark resolution)
• both modified: README.md

both modified — 양쪽이 다 고쳤다는 뜻입니다. 어떤 파일이 문제인지 이 한 줄로 알 수 있습니다. 파일이 열 개여도 여기 나오는 것만 보면 됩니다.

괄호 안 두 줄이 앞으로 갈 길을 알려줍니다. 고치고 커밋하든지, 아니면 그만두든지. 그만두는 쪽은 뒤에서 봅니다.

파일을 열어봅니다

README.md 를 열면 없던 글자가 들어가 있습니다.

<<<<<<< HEAD
# 내 첫 저장소 — 2026
=======
# 깃 공부 기록
>>>>>>> fix-title

안녕하세요. 깃을 공부하고 있습니다.

처음 보면 파일이 깨진 것 같습니다. 아닙니다. 깃이 일부러 넣어둔 표시입니다. 냉장고 달력으로 치면 "여기 두 사람이 다르게 적었음" 하고 형광펜을 그어둔 것과 같습니다.

고릅니다

이제 사람이 할 일이 나옵니다. 셋 중 하나를 정합니다.

선택	남길 것	언제 이걸 고르나
내 것을 쓴다	# 내 첫 저장소 — 2026	내 쪽이 더 최신이거나 맞을 때
저쪽 것을 쓴다	# 깃 공부 기록	상대가 더 잘 아는 부분일 때
둘을 섞는다	# 깃 공부 기록 — 2026	양쪽 다 일리가 있을 때. 실무에서 제일 많습니다

여기서는 세 번째, 둘을 섞는 쪽으로 갑니다.

1. 01

   원하는 최종 모습으로 고칩니다

   제목 줄을 # 깃 공부 기록 — 2026 한 줄로 만듭니다

2. 02

   부등호 세 줄을 전부 지웁니다

   <<<<<<< HEAD, =======, >>>>>>> fix-title 이 세 줄이 파일에 남아 있으면 안 됩니다

3. 03

   저장하고 파일을 다시 훑어봅니다

   부등호가 하나도 안 보이면 된 겁니다

4. 04

   해결했다고 깃에게 알립니다

   6강의 그 add 입니다. 여기서는 "이 파일은 내가 정리했다" 는 신고 역할을 합니다

   git add README.md

5. 05

   커밋해서 합치기를 끝냅니다

   git commit -m "제목 충돌 해결"

• $ git add README.md
• $ git commit -m "제목 충돌 해결"
• [master 3f21c8e] 제목 충돌 해결
• $ git status
• On branch master
• nothing to commit, working tree clean

nothing to commit 이 다시 나왔습니다. 끝났습니다.

git log --oneline 을 쳐보면 커밋이 하나 더 생겨 있습니다. 22강에서는 Fast-forward 라 새 커밋이 안 생겼는데, 이번엔 양쪽을 섞은 커밋이 하나 만들어진 겁니다. 그 커밋의 역할은 "여기서 두 갈래가 하나로 합쳐졌다" 는 기록입니다.

다 썼으니 git branch -d fix-title 로 가지를 지웁니다. 22강 그대로입니다. 충돌을 겪었다고 뒷정리가 달라지지는 않습니다.

충돌은 사고가 아닙니다

이번 시간에 꼭 남겨야 할 감각이 하나 있습니다.

충돌이 났다는 건 두 사람이 같은 자리를 신경 썼다는 뜻입니다. 깃이 그걸 놓치지 않고 잡아서 사람에게 넘긴 겁니다. 만약 깃이 조용히 한쪽을 골라버렸다면, 누군가의 작업이 아무도 모르게 사라졌을 겁니다.

명령	하는 일
git status	충돌 난 파일을 both modified 로 알려준다
git add 파일	"이 파일은 정리했다" 고 표시한다
git commit -m "..."	합치기를 마무리한다
git merge --abort	합치기를 통째로 취소하고 되돌린다

정리하면

• 충돌은 같은 파일의 같은 줄을 양쪽에서 다르게 고쳤을 때만 납니다. 다른 줄이면 깃이 알아서 합칩니다
• CONFLICT 가 떠도 아무것도 안 망가졌습니다. 깃이 결정을 미루고 사람을 부른 것뿐입니다
• git status 의 both modified 가 어느 파일이 문제인지 알려줍니다
• 파일 안 부등호는 깃이 넣은 표시입니다. HEAD 위쪽이 내 것, 아래쪽이 가져오려던 가지 것입니다
• 고르는 방법은 셋입니다. 내 것 · 저쪽 것 · 둘을 섞기. 실무에서는 섞는 경우가 제일 많습니다
• 해결은 특별한 명령이 아닙니다. 파일 고치고 add 하고 commit 하면 끝입니다
• 부등호 세 줄을 반드시 지웁니다. 안 지워도 깃은 막지 않고 그대로 올라갑니다
• 막막하면 git merge --abort 로 합치기 전으로 되돌릴 수 있습니다
• 충돌이 났다는 건 두 사람이 같은 자리를 건드렸다는 신호입니다. 깃이 놓치지 않고 잡아준 겁니다

여기까지가 혼자서 두 역할을 흉내 낸 연습이었습니다. 가지를 만들고, 합치고, 충돌을 풀었습니다. 그런데 실무에서는 이 과정에 한 단계가 더 붙습니다. 합치기 전에 물어봅니다.

다음 24강에서는 Pull Request 를 봅니다. 21강에서 "왜 master 에서 바로 안 짜는가" 라고 했던 질문의 답입니다. 내 가지를 master 에 넣기 전에 "이거 넣어도 될까요" 하고 올려두면, 다른 사람이 보고 답을 답니다. 결재를 올리는 것과 같습니다. 오늘까지는 내 컴퓨터 안에서 끝나는 일이었는데, 24강부터는 깃허브 화면으로 나갑니다.