새 기능을 만들어 보고 싶은데, 막상 시작하려니 손이 멈칫한 적 없으신가요? "지금 잘 돌아가는 코드를 건드렸다가 망가뜨리면 어쩌지", "이거 실험만 해보고 싶은데 원본은 그대로 두고 싶은데…" 하는 마음 말이에요.
바로 이럴 때 쓰라고 있는 게 브랜치(branch)입니다. 한마디로 '평행 우주'예요. 원본 세계(main)는 그대로 둔 채, 똑같은 복사본 우주를 하나 만들어 거기서 마음껏 실험하는 거죠. 실험이 성공하면 원본 세계에 그 결과만 합치고(merge), 망하면 그 우주째 버리면 됩니다. 원본은 아무 일도 없던 것처럼 안전하고요.
이번 글에서는 평행 우주를 만들고(branch), 오가고(switch), 원본에 합치고(merge), 합칠 때 생기는 충돌(conflict)을 푸는 것까지 해봅니다. 충돌이라는 단어에 겁먹지 마세요 — 에러가 아니라 지극히 정상적인 과정이고, 푸는 법도 생각보다 단순합니다.
브랜치란? — 원본을 지키는 '평행 우주'
지금까지 우리는 main이라는 하나의 타임라인 위에 사진(커밋)을 쭉 쌓아왔습니다. 브랜치는 그 타임라인에서 갈래길을 하나 트는 것입니다. 갈래길에서 무슨 짓을 해도 원래 길(main)은 멀쩡해요.
놀라운 사실 하나. 브랜치는 거창한 '복사'가 아닙니다. Git에서 브랜치는 그저 어떤 커밋 하나를 가리키는 가벼운 이름표(포인터)일 뿐이에요. 그래서 만들고 지우는 데 비용이 거의 없습니다. 부담 없이 만들고, 아니다 싶으면 지우면 됩니다. (main도 사실 특별한 게 아니라 그런 이름표 중 하나일 뿐이에요.)
| 개념 | 평행 우주에 비유하면 |
|---|---|
| main 브랜치 | 원본 세계 (안전하게 지킬 본편) |
| 새 브랜치 | 실험용 평행 우주 (망쳐도 OK) |
| merge(병합) | 실험 성공 → 원본 세계에 합치기 |
평행 우주 만들고 오가기 — branch와 switch
로그인 기능을 새로 만든다고 해봅시다. login이라는 평행 우주를 만들고 그리로 건너가는 가장 간단한 방법은 이거예요.
git switch -c loginswitch -c는 "브랜치를 새로 만들고(create) 동시에 그리로 이동"하는 명령입니다. 이제 여러분은 login 우주에 있고, 여기서 무엇을 커밋하든 main은 그대로예요. 한 줄씩 나눠 쓰거나 이미 있는 브랜치로 옮길 때는 이렇게 합니다.
git branch login # 만들기만 (이동은 안 함)
git switch login # login 우주로 이동
git switch main # 원본(main)으로 돌아오기
git branch # 브랜치 목록 보기 (* 표시가 지금 있는 곳)switch는 비교적 최근에 생겼어요 — 예전엔git checkout하나가 '브랜치 이동'과 '파일 되돌리기'를 다 맡아 헷갈렸습니다(4편에서 본 그 이야기죠). 그래서 Git 2.23(2019년)부터 브랜치 이동은git switch로 분리됐어요. 옛 자료의git checkout -b login은git switch -c login과 같은 뜻입니다.
실험을 원본에 합치기 — merge
login 우주에서 기능을 다 만들고 커밋까지 했다면, 이제 원본 main에 합칠 차례입니다. 순서가 중요해요. "합쳐서 받을 곳(main)으로 먼저 이동한 뒤, 가져올 브랜치를 merge" 합니다.
git switch main # 원본으로 이동
git merge login # login의 작업을 main으로 합치기합치는 모습은 상황에 따라 둘 중 하나입니다. 알아두면 로그가 안 무섭습니다.
- 빨리 감기(fast-forward) — 내가
main을 건드리지 않은 사이login만 앞서 나갔다면, Git은 그냥main이름표를login자리로 쓱 옮겨 끝냅니다. 깔끔하죠. - 3-way 병합 —
main과login둘 다 각자 커밋이 쌓여 길이 갈라졌다면, Git이 양쪽을 합친 '병합 커밋'을 새로 하나 만들어 두 갈래를 묶습니다. (이때 양쪽이 같은 곳을 다르게 고쳤으면 다음에 나올 '충돌'이 생깁니다.)
충돌(conflict) — 겁먹지 마세요, 정상입니다
두 평행 우주에서 같은 파일의 같은 부분을 서로 다르게 고친 뒤 합치면, Git은 멈춰 서서 이렇게 말합니다.
Automatic merge failed; fix conflicts and then commit the result.이건 에러가 아닙니다. Git이 "두 사람이 같은 칸을 다르게 적었네? 둘 중 뭐가 맞는지는 내가 함부로 못 정하니, 네가 골라줘"라고 정중히 멈춘 거예요. 양쪽 내용을 임의로 덮어쓰지 않고 그대로 보여주며 기다립니다. 충돌 난 파일을 열면 이런 표시가 들어가 있어요.
<<<<<<< HEAD
지금 내가 있던 브랜치(main)의 내용
=======
합쳐 오는 브랜치(login)의 내용
>>>>>>> login읽는 법은 간단합니다. ======= 윗부분(<<<<<<< HEAD 쪽)은 지금 내 브랜치, 아랫부분(>>>>>>> login 쪽)은 합쳐 오는 브랜치의 내용이에요. 해결은 이렇게 합니다.
- 파일을 열어 원하는 최종 모습으로 직접 편집합니다 (한쪽을 고르든, 둘을 섞든 자유).
<<<<<<<,=======,>>>>>>>마커 세 줄을 반드시 지웁니다. (이게 남으면 코드가 깨져요.)git add <파일>로 "해결했어요" 표시를 하고,git commit으로 병합을 마무리합니다.
git add README.md # 충돌 해결한 파일을 스테이징(= 해결됨 표시)
git commit # 병합 완료그냥 없던 일로 하고 싶다면 — 합치다가 충돌이 너무 복잡해 보이면,git merge --abort로 병합을 통째로 취소하고 합치기 전 상태로 깔끔히 되돌릴 수 있습니다. 마음 편히 다시 시도하세요.
다 쓴 평행 우주 정리하기 — 브랜치 삭제
login을 main에 잘 합쳤다면, 그 평행 우주는 이제 역할을 다했습니다. 지워서 깔끔하게 정리해요.
git branch -d login-d는 "이미 main에 합쳐진(merge된) 브랜치만 안전하게 삭제"합니다. 만약 아직 안 합친 브랜치를 -d로 지우려 하면 Git이 "이거 아직 안 합쳐졌는데 정말?" 하고 막아줘요.
대문자-D는 강제 삭제 — 조심하세요 —git branch -D login은 합치지 않은 브랜치도 경고 없이 지웁니다. 그 브랜치에서만 했던 커밋이 길을 잃을 수 있어요. (그래도 당황 마세요 — 4편에서 배운git reflog로 한동안은 되찾을 수 있습니다.) 정말 버릴 브랜치가 확실할 때만 쓰세요.
실무에선 이렇게 씁니다
정리하면 현업의 기본 흐름은 늘 이 모양입니다. 기능 하나당 브랜치 하나예요.
- 브랜치 만들기 —
git switch -c 기능이름으로 평행 우주를 연다. - 작업 & 커밋 — 그 안에서 마음껏 만들고 커밋한다. main은 늘 안전.
- 합치고 정리 —
main으로 돌아와merge하고, 다 쓴 브랜치는-d로 삭제.
이렇게 하면 언제든 동작하는 main을 지키면서, 여러 기능을 겁 없이 동시에 실험할 수 있습니다.
정리 — 이제 마음껏 실험하세요
브랜치의 진짜 가치는 '안심하고 망칠 수 있는 자유'입니다. 원본 main은 그대로 둔 채 평행 우주에서 무엇이든 시도하고, 좋으면 합치고(merge) 아니면 버리면 되니까요. 충돌이 나도 이제 알죠 — 에러가 아니라 "골라달라"는 정중한 멈춤이고, 마커를 정리해 add → commit이면 끝입니다.
여기까지 왔다면 여러분은 혼자 Git을 쓰는 데 필요한 건 거의 다 갖춘 셈이에요. 다음 6편에서는 이 브랜치를 여러 사람과 함께 쓰는 무대 — GitHub에서 남의 프로젝트를 가져오고(clone/fork), 내 변경을 제안하는 Pull Request(PR)로 넘어갑니다. 오픈소스에 첫 기여를 해보는 거죠.
참고 자료
'Hello Dev' 카테고리의 다른 글
| 프로 개발자의 마지막 퍼즐 — 실무에서 빛나는 Git 고급 스킬 (stash·rebase·tag·alias) (0) | 2026.06.23 |
|---|---|
| 오픈소스와 팀 협업의 꽃 — Fork·Clone과 Pull Request로 첫 기여하기 (0) | 2026.06.23 |
| 실수해도 괜찮아 — Git으로 되돌리기 (restore·amend·reset·revert, 그리고 생명줄 reflog) (0) | 2026.06.22 |
| 내 코드를 클라우드에 백업하기 — GitHub에 처음 git push 하기 (인스타에 사진 올리듯) (0) | 2026.06.22 |
| 내 코드의 첫 저장점 만들기 — git add와 commit, 사진 찍듯 이해하기 (0) | 2026.06.19 |