Git · 0to1

버전관리개발 입문5분

한눈에

Git = 게임 세이브 시스템 (순간순간 스냅샷으로 박고, 되돌리고, 갈래를 나눔)
커밋 = 세이브 포인트 (그 순간 코드 전체 스냅샷, 계속 쌓여 어느 시점으로도 복구)
브랜치 = 평행세계 갈래 (본편 main은 놔두고 옆 갈래에서 마음껏 실험)
머지 = 두 갈래를 있는 그대로 봉합 (머지 커밋 표식을 남겨 역사 보존)
리베이스 = 내 커밋을 상대의 최신 위로 옮겨 붙이기 (한 줄로 정리, 역사 재배열)
충돌 = 같은 줄을 둘이 다르게 고쳤을 때 Git이 던지는 질문 (에러가 아니라 사람이 결정)

게임하다 어려운 보스 앞에서 세이브를 떠본 적 있을 거다. 잘못되면 그 지점으로 되돌리려고. Git이 딱 그 세이브 시스템이다. 코드를 짜다가 순간순간 "여기까지는 됨"을 스냅샷으로 박아두고, 망가지면 되돌리고, 갈래를 나눠 다른 시도를 해본다. 혼자 쓰면 무한 되돌리기 버튼이고, 여럿이 쓰면 서로의 작업을 겹치지 않게 합쳐주는 도구다.

커밋, 코드의 세이브 포인트

커밋(commit)은 그 순간 코드 전체의 스냅샷이다. 게임의 세이브 슬롯. "로그인 기능 됨"까지 짜고 커밋을 찍으면, 그 상태가 통째로 저장된다. 나중에 뭘 잔뜩 고쳐서 다 망가뜨려도, 그 커밋으로 돌아가면 딱 그때로 복구된다.

세이브는 덮어쓰기가 아니라 계속 쌓인다. 커밋 하나하나가 슬롯이라, 어제 오후 3시의 나로도, 그저께의 나로도 돌아갈 수 있다. 그래서 커밋마다 "무엇을 왜 했는지" 쪽지(커밋 메시지)를 붙인다. 나중에 세이브 목록을 훑을 때, 이게 어떤 지점인지 알아보려고.

브랜치, 평행세계로 갈라지기

브랜치(branch)는 본편은 그대로 놔두고, 다른 갈래로 게임을 새로 진행해보는 거다. "이번엔 마법사로 키워볼까" 하고 세이브를 하나 복사해 딴 길을 타는 것.

코드로 치면 이렇다. 잘 돌아가는 본편(보통 main)은 건드리지 않고, 옆에 login-feature라는 갈래를 하나 튼다. 거기서 마음껏 실험하고 커밋을 쌓아도 본편은 멀쩡하다. 실험이 잘 되면 나중에 본편에 합치고, 망하면 그 갈래를 통째로 버리면 그만이다. 여럿이 일할 때 특히 강하다. 각자 자기 평행세계에서 작업하니 남의 코드를 실시간으로 밟을 일이 없다.

합치는 두 방식, 머지와 리베이스

갈라졌으면 언젠가는 다시 하나로 합쳐야 한다. 두 세이브를 하나로 합치는 두 가지 방식이 있다.

머지(merge) — 두 갈래를 있는 그대로 봉합하고, "여기서 합쳤음" 하는 표식(머지 커밋)을 새로 남긴다. 역사를 보존하는 방식

리베이스(rebase) — 내 갈래의 커밋들을 상대의 최신 지점 위로 옮겨 붙여, 마치 처음부터 한 줄로 짠 것처럼 정리한다. 역사를 재배열하는 방식

머지는 "두 갈래가 여기서 만났다"는 흔적이 그대로 남아 사실에 충실하지만, 갈래가 많아지면 히스토리가 얽혀 보인다. 리베이스는 한 줄로 쫙 펴줘서 읽기 깔끔하지만, 이미 남과 공유한 커밋을 리베이스하면 역사가 어긋나 사고가 난다. 그래서 보통 "혼자만 가진 갈래는 리베이스로 정리, 남과 공유한 지점은 머지로 합친다"를 기준으로 잡는다.

충돌, 게임이 "어느 걸?" 하고 묻는 순간

충돌(conflict)은 같은 칸을 둘이 다르게 써놨을 때 게임이 멈춰 서서 "어느 걸 남길래?" 하고 되묻는 것이다.

Git은 웬만하면 알아서 합친다. 나는 3층을 고치고 너는 7층을 고쳤으면, 서로 안 겹치니 그냥 둘 다 반영한다. 그런데 너와 내가 같은 줄을 서로 다르게 고쳤으면 Git은 자동 판단을 포기한다. 함부로 하나를 고르면 남의 작업이 조용히 사라지니까. 대신 그 자리에 <<<<<<< ======= >>>>>>> 표식으로 양쪽 버전을 나란히 붙여놓고, 사람에게 결정을 넘긴다.

같은 줄을 둘이 다르게 고침

내 버전과 상대 버전이 정면 충돌

Git이 자동 봉합을 포기

함부로 고르면 한쪽 작업이 사라지니까

양쪽 버전을 나란히 표시

표식으로 내 것과 상대 것을 다 보여줌

사람이 남길 것을 결정

고르거나 둘을 섞어 마무리하고 커밋

그래서 충돌은 에러가 아니라 질문이다. 무섭게 볼 게 아니라 "둘이 같은 데를 건드렸으니 네가 정리해라" 하는 안내다. 막히면 하나씩 골라 표식을 지우고 커밋하면 끝난다.

우리 프로젝트에선

지금 이 글이 담긴 모노레포 전체가 git 위에서 굴러간다. 0to1 블로그, noon(워치 앱), 여러 실험이 한 저장소 안에 갈래를 치며 산다.

최근엔 로컬과 원격이 중복 커밋으로 갈라진 적이 있었다. 같은 작업이 양쪽에 서로 다른 모양으로 쌓여, 그냥 밀어넣으면 한쪽이 날아갈 상황. 이때 git reset --hard 같은 파괴적 명령으로 한쪽을 지우는 대신, **머지로 두 역사를 합치되 겹치는 부분은 로컬을 우선(-X ours)**으로 두게 했다. 덕분에 다른 세션에서 돌던 noon 작업을 하나도 잃지 않고 갈래를 봉합했다. 이런 판단 흐름은 AI 하네스플레이북AI 하네스Claude Code를 무인으로 부리려고 짠 협업 하네스.에 정리돼 있다.

즉 나한테 git은 "코드 저장 도구"를 넘어, 여러 작업이 동시에 굴러가는 판을 안 깨뜨리고 합쳐내는 안전망으로 온다. 되돌릴 수 있다는 감각이 있어야 과감하게 실험할 수 있다.

더 읽기

예제와 그림으로 더 풀어놓은 글들. 개념이 헷갈릴 때 하나씩.

Git 브랜치 — 브랜치와 Merge의 기초 (Git 공식 한국어 문서) — 브랜치·머지의 원본 설명, 그림으로 천천히
Git에서 머지 충돌을 해결하는 방법과 실용 예시 (freeCodeCamp 한국어) — 충돌 표식을 실제로 어떻게 지우는지 단계별로
효율적인 Git 리베이스와 충돌 해결 방법 (F-Lab) — 머지 대신 리베이스를 쓸 때의 관점