logo
게시일

Git 쉽게 이해하기 - 커밋부터 브랜치까지

다른 언어로 읽기: English
작성자

Git이 뭔가요?

"저장"만으로는 부족합니다

컴퓨터로 문서를 작성하면 파일로 저장합니다. 그런데 파일을 저장하다 보면 이런 상황이 생깁니다:

보고서.docx, 보고서_수정.docx, 보고서_최종.docx, 보고서_최종_수정.docx, 보고서_진짜최종.docx, 보고서_진짜최종_이게마지막.docx...

이런 경험 있으시죠? 파일을 수정할 때마다 "혹시 이전 버전이 필요하면 어쩌지?" 라는 생각에 새 이름으로 저장하게 됩니다.

결과적으로 폴더 안이 파일로 가득 차고, 어떤 파일이 진짜 최종인지 모르게 됩니다.

파일 버전 폭발

Ctrl+Z로 충분하지 않나요?

"되돌리기(Ctrl+Z)가 있잖아요?"라고 생각할 수 있습니다.

하지만 Ctrl+Z에는 한계가 있습니다:

  • 파일을 닫으면 되돌리기 기록이 사라집니다
  • 며칠 전 상태로는 돌아갈 수 없습니다
  • 어떤 것을 왜 바꿨는지 기록이 남지 않습니다
  • 여러 파일을 동시에 되돌릴 수 없습니다

Git = 파일의 타임머신

Git은 파일의 변경 기록을 체계적으로 관리하는 도구입니다.

타임머신을 생각해 봅시다:

  • 현재 상태를 저장(기록)할 수 있습니다
  • 언제든 과거로 돌아갈 수 있습니다
  • 언제, 무엇을, 왜 바꿨는지 기록이 남습니다
  • 파일 이름을 바꿀 필요가 없습니다 — 보고서.docx 하나만 있으면 됩니다

Git이 있으면 보고서.docx 하나만 있으면 됩니다. Git이 내부에 "초안 작성(1/10) → 그래프 추가(1/12) → 결론 수정(1/14) → 최종 검토(1/15)" 이런 식으로 변경 기록을 차곡차곡 쌓아둡니다.

Git = 타임머신

Git은 프로그래머들이 코드를 관리하기 위해 만들었지만, 원리는 단순합니다: "변경사항을 기록해두고, 필요하면 되돌린다."

왜 지금 Git을 알아야 할까요?

최근에는 AI가 직접 코드를 수정하는 시대가 되었습니다.

Claude Code, Codex 같은 AI 코딩 도구들은 채팅처럼 대화하면서 여러분의 컴퓨터에 있는 파일을 직접 수정합니다. "로그인 기능을 만들어줘"라고 말하면, AI가 알아서 여러 파일을 만들고 수정합니다.

이것은 매우 편리하지만, 한 가지 문제가 있습니다:

AI가 수정한 결과가 항상 마음에 드는 것은 아닙니다.

예를 들어:

  • "버튼 색상을 바꿔줘"라고 했는데, AI가 레이아웃까지 바꿔버릴 수 있습니다
  • "버그를 고쳐줘"라고 했는데, 다른 곳이 새로 망가질 수 있습니다
  • AI가 파일 10개를 한꺼번에 수정했는데, 어디를 어떻게 바꿨는지 파악이 어렵습니다

이때 Git이 있으면:

  • AI가 수정하기 전 상태로 한 번에 되돌릴 수 있습니다
  • AI가 어떤 파일의 어느 줄을 바꿨는지 정확히 확인할 수 있습니다
  • 마음에 드는 것만 골라서 저장할 수 있습니다

Git 없이 AI 도구를 쓰는 것은, 세이브 없이 게임을 하는 것과 같습니다. 잘 되면 다행이지만, 문제가 생기면 처음부터 다시 해야 합니다.

AI + Git 안전망

핵심 포인트

Git은 파일의 변경 기록을 관리하는 도구입니다. 파일 이름을 바꿔가며 여러 버전을 만들 필요 없이, 하나의 파일에서 모든 변경 기록을 추적합니다. AI 도구가 파일을 직접 수정하는 시대에, Git은 안전망 역할을 합니다.


저장소(Repository)

저장소 = Git이 관리하는 폴더

Git을 사용하려면 먼저 "이 폴더를 Git으로 관리하겠다" 고 선언해야 합니다.

이렇게 Git이 관리하는 폴더를 저장소(Repository), 줄여서 레포(Repo)라고 부릅니다.

보통 하나의 프로젝트가 하나의 저장소입니다:

  • 웹사이트를 만드는 프로젝트 → 하나의 저장소
  • 앱을 만드는 프로젝트 → 하나의 저장소
  • 보고서를 쓰는 프로젝트 → 하나의 저장소

일반 폴더에서 Git 저장소로

처음에는 그냥 평범한 폴더입니다. 여기에 "Git으로 관리 시작!" 이라고 선언하면, 그 순간부터 Git 저장소가 됩니다.

겉으로 보기엔 달라진 것이 없습니다. 원래 있던 파일은 그대로이고, 보이지 않는 곳에 .git이라는 숨겨진 폴더가 하나 생길 뿐입니다.

.git 폴더는 Git의 기록 창고입니다. 파일을 수정하고 기록을 남길 때마다, Git이 이 창고 안에 차곡차곡 보관해 둡니다. 우리가 직접 창고 안을 뒤지거나 정리할 필요 없이, Git이 알아서 관리합니다.

중요한 것이 하나 있습니다: 이 창고를 직접 열어보거나 건드리면 안 됩니다. 이 폴더를 삭제하면 모든 변경 기록이 사라집니다.

일반 폴더 → Git 저장소

핵심 포인트

  • 저장소(Repository) = Git이 관리하는 폴더
  • .git 폴더 = 모든 변경 기록이 저장되는 창고. 직접 건드리지 마세요
  • 하나의 프로젝트 = 하나의 저장소

커밋(Commit)

커밋 = 세이브 포인트

게임을 할 때 어려운 보스 앞에서 세이브를 하죠? 만약 지면 세이브한 시점으로 돌아가면 됩니다.

Git에서 커밋(Commit)이 바로 이 세이브 포인트입니다.

  • 게임 세이브: "이 시점의 게임 상태를 저장한다"
  • Git 커밋: "이 시점의 파일 상태를 저장한다"

커밋을 하면 그 순간의 모든 파일 상태가 기록됩니다. 나중에 이 커밋 시점으로 언제든 돌아올 수 있습니다.

만약 네 번째 세이브에서 문제가 생기면? 세 번째 세이브로 돌아가면 됩니다.

커밋 = 세이브 포인트

커밋 메시지 — "이때 뭘 했는지" 메모

커밋을 만들 때는 반드시 메시지를 남깁니다.

커밋 메시지는 "이 세이브에서 뭘 했는지" 설명하는 메모입니다. 나중에 기록을 볼 때 이 메시지를 보고 각 시점에서 무슨 일이 있었는지 파악합니다.

게임 세이브에 메모를 남기는 것과 같습니다. "보스전 직전, 체력 풀 상태"라고 쓰면 나중에 바로 알 수 있지만, "ㅇㅇ"이라고 쓰면 일주일 후에 어떤 세이브인지 전혀 알 수 없겠죠?

Git 커밋 메시지도 마찬가지입니다. "로그인 페이지 디자인 완성", "이메일 검증 버그 수정" 처럼 구체적으로 써야 합니다. "수정", "asdf" 같은 메시지는 나중에 아무 도움이 되지 않습니다.

미래의 자신을 위해 명확하게 쓰는 것이 좋습니다.

커밋 메시지 좋은 vs 나쁜

핵심 포인트

  • 커밋 = 파일 상태를 저장하는 세이브 포인트
  • 커밋 메시지 = "이 시점에서 뭘 했는지" 설명하는 메모. 명확하게 써야 합니다
  • 파일을 수정하고 → 커밋하면 → 세이브 완료!

변경 기록 살펴보기

커밋 이력 = 세이브 목록

세이브를 여러 번 했으면, 지금까지 어떤 세이브를 만들었는지 목록을 볼 수 있습니다.

Git에서는 이것을 커밋 이력(Commit History)이라고 합니다. 게임의 세이브 목록과 같습니다.

커밋 이력에는 각 세이브의 정보가 시간순으로 쌓여 있습니다. 각 세이브(커밋)에는 다음 정보가 들어있습니다:

  • 고유 ID: 각 커밋을 구분하는 이름표 (사람의 주민번호처럼, 같은 것이 없습니다)
  • 작성자: 누가 이 세이브를 만들었는지
  • 날짜: 언제 세이브했는지
  • 메시지: 무엇을 했는지
커밋 이력 타임라인

변경 내용 비교

Git은 각 세이브마다 "이전과 무엇이 달라졌는지"도 정확히 보여줍니다.

예를 들어, 어떤 파일에서 "오늘의 메뉴: 비빔밥"을 "오늘의 메뉴: 김치찌개"로 바꿨다면, 빨간색(-)으로 이전 내용이, 초록색(+)으로 새 내용이 표시됩니다.

AI가 파일 10개를 수정했을 때도, 이 비교 기능으로 정확히 어디가 어떻게 바뀌었는지 하나하나 확인할 수 있습니다.

변경 비교

이전 상태로 돌아가기

Git의 진짜 힘은 여기에 있습니다. 커밋을 해두면 언제든 그 시점으로 돌아갈 수 있습니다.

"로그인 기능을 추가했는데, 다 망가졌다" → 이전 세이브로 돌아가면 됩니다.

이것이 앞에서 말한 타임머신입니다. 커밋을 자주 하면 할수록, 더 촘촘한 세이브 포인트가 생기고, 더 정확한 시점으로 돌아갈 수 있습니다.

핵심 포인트

  • 커밋 이력 = 지금까지 만든 세이브 목록. 누가, 언제, 무엇을 했는지 기록됩니다
  • 변경 비교 = 이전과 무엇이 달라졌는지 빨간색(삭제)/초록색(추가)으로 보여줍니다
  • 커밋 해둔 시점으로 언제든 돌아갈 수 있습니다 — 이것이 Git의 핵심 가치

리모트와 푸시

지금까지는 내 컴퓨터 안에서만

여기까지 배운 것을 정리하면:

  1. 저장소를 만들고
  2. 파일을 수정하고
  3. 커밋(세이브 포인트)을 만듭니다

하지만 이 모든 기록은 내 컴퓨터 안에만 있습니다.

만약 컴퓨터가 고장 나면? 모든 기록이 사라집니다. 다른 사람과 같이 작업하고 싶으면? 파일을 일일이 보내야 합니다.

리모트(Remote) = 다른 컴퓨터의 저장소

리모트내 컴퓨터가 아닌 다른 컴퓨터에 있는 저장소입니다.

보통 인터넷 서버(클라우드)에 만들어놓고, 내 컴퓨터의 저장소와 연결합니다.

리모트가 있으면:

  • 백업: 내 컴퓨터가 고장 나도 리모트에 기록이 남아있습니다
  • 공유: 다른 사람도 리모트에 접근해서 같은 코드를 받을 수 있습니다
  • 어디서든: 집 컴퓨터에서 작업하고 리모트에 올려두면, 회사 컴퓨터에서 이어서 할 수 있습니다

쉽게 말하면, 클라우드 드라이브(구글 드라이브, iCloud)와 비슷한 개념입니다. 하지만 단순히 파일을 올리는 것이 아니라, 커밋 기록 전체를 올리고 받는다는 차이가 있습니다.

리모트 = 클라우드 저장소

클론(Clone) = 처음 받아오기

리모트에 이미 저장소가 있다면, 그것을 통째로 내 컴퓨터에 복사할 수 있습니다. 이것을 클론(Clone)이라고 합니다.

"복제하다"라는 뜻 그대로, 리모트에 있는 저장소의 파일과 커밋 기록 모두 내 컴퓨터에 가져옵니다.

실제로 많은 프로젝트가 이렇게 시작됩니다:

  • 회사에 입사해서 기존 프로젝트를 받아올 때
  • 다른 사람이 만든 프로젝트를 받아올 때
  • 집에서 작업하던 것을 회사 컴퓨터에서 이어서 할 때

클론을 하면 리모트와 자동으로 연결되기 때문에, 이후에는 Push와 Pull로 기록을 주고받으면 됩니다.

푸시(Push)와 풀(Pull)

클론으로 저장소를 받아온 뒤, 내 컴퓨터와 리모트 사이에서 기록을 주고받는 방법은 두 가지입니다.

푸시(Push) = 보내기

"밀어 넣다"라는 뜻입니다. 내 컴퓨터에 있는 커밋 기록을 리모트에 올리는 것입니다. 내 세이브 기록이 그대로 리모트에 복사됩니다.

풀(Pull) = 받기

"당겨오다"라는 뜻입니다. 리모트에 있는 새로운 커밋 기록을 내 컴퓨터로 받는 것입니다. 다른 사람이 올린 새 기록을 내 컴퓨터에 가져옵니다.

쉽게 정리하면:

동작방향의미비유
Clone (클론)리모트 → 내 컴퓨터저장소를 처음 받아오기저장소 복제
Push (푸시)내 컴퓨터 → 리모트내 기록을 올리기클라우드에 업로드
Pull (풀)리모트 → 내 컴퓨터새 기록을 받기클라우드에서 다운로드
Push와 Pull

핵심 포인트

  • 리모트 = 다른 컴퓨터(서버)에 있는 저장소. 백업과 공유를 위해 사용합니다
  • Clone(클론) = 리모트의 저장소를 통째로 복제
  • Push(푸시) = 내 커밋을 리모트에 올리기 (업로드)
  • Pull(풀) = 리모트의 커밋을 가져오기 (다운로드)
  • 리모트 덕분에 컴퓨터가 고장 나도 안전하고, 다른 사람과 함께 작업할 수 있습니다

브랜치와 머지

브랜치(Branch) = 평행 세계

여기까지 배운 것은 하나의 길 위에서 세이브를 쌓아가는 것이었습니다. 그런데 실제로 작업을 하다 보면, 동시에 여러 작업을 하고 싶을 때가 있습니다.

예를 들어:

  • 웹사이트의 메인 페이지가 잘 돌아가고 있는데
  • 로그인 기능을 새로 만들고 싶습니다
  • 그런데 로그인을 만드는 동안 메인 페이지가 망가지면 안 됩니다

이럴 때 사용하는 것이 브랜치(Branch)입니다.

브랜치는 "갈림길" 입니다. 현재 상태에서 새로운 길을 하나 만들어서, 그 길 위에서 마음껏 작업하는 것입니다. 원래 길(메인)은 그대로 안전하게 남아 있습니다.

평행 세계를 떠올려 봅시다:

  • 하나의 세계에서는 로그인 기능을 실험하고 있고
  • 다른 세계에서는 메인 페이지가 원래대로 잘 돌아가고 있습니다
  • 두 세계는 서로 영향을 주지 않습니다

브랜치의 장점:

  • 안전합니다: 새 기능을 만들다 실패해도, 원래 상태가 안전합니다
  • 동시 작업이 가능합니다: 여러 사람이 각자 브랜치에서 다른 기능을 만들 수 있습니다
  • 실험이 자유롭습니다: "이렇게 해볼까?"를 부담 없이 시도할 수 있습니다
브랜치 = 평행 세계

머지(Merge) = 합치기

브랜치에서 작업을 다 끝냈으면 어떻게 할까요?

원래 길(메인)에 합칩니다. 이것을 머지(Merge)라고 합니다.

로그인 기능이 완성되었다면, 이것을 메인에 합쳐서 "로그인이 포함된 완전한 웹사이트"를 만듭니다. 합쳐진 결과에는 메인의 내용 + 로그인 기능의 내용이 모두 들어있습니다.

두 줄기의 강이 합쳐져서 큰 강이 되는 것과 같습니다.

머지 = 합치기

핵심 포인트

  • 브랜치 = 갈림길. 메인을 안전하게 두고, 새로운 길에서 작업합니다
  • 머지 = 브랜치에서 만든 작업을 메인에 합치는 것
  • 갈라졌다가 → 다시 합쳐지는 것. 이것이 브랜치와 머지입니다

핵심 정리

Git의 전체 흐름

파일 수정 → 세이브(커밋) → 보내기(Push)

이 흐름을 반복하면서 작업을 진행합니다. 다른 사람의 작업을 받을 때는 Pull(받기)을 합니다.

필요하면 브랜치로 갈림길을 만들어 안전하게 작업하고, 머지로 다시 합칩니다.

전체 흐름 요약

개념 한눈에 보기

개념한 줄 설명
Git파일의 변경 기록을 관리하는 도구 (타임머신)
저장소(Repository)Git이 관리하는 폴더
커밋(Commit)파일 상태를 저장하는 세이브 포인트
커밋 메시지"이 시점에서 뭘 했는지" 설명하는 메모
리모트(Remote)다른 컴퓨터(서버)에 있는 저장소
Clone(클론)리모트의 저장소를 통째로 복제
Push(푸시)내 커밋을 리모트에 올리기
Pull(풀)리모트의 커밋을 가져오기
브랜치(Branch)메인을 안전하게 두고 새 길에서 작업하는 갈림길
머지(Merge)브랜치에서 만든 작업을 합치는 것

Git 한 장으로 이해하기

아래 그림 한 장에 Git의 모든 핵심 개념이 담겨 있습니다. 이 그림이 Git의 전부입니다:

  • 클론으로 리모트 저장소를 처음 받아오고
  • 내 컴퓨터에서 파일을 수정하고
  • 커밋으로 세이브하고
  • 푸시로 리모트에 보내고, 로 받아옵니다
  • 브랜치로 갈림길을 만들고, 머지로 다시 합칩니다
Git 전체 개념 한 장 정리

Git은 처음에는 낯설게 느껴질 수 있습니다. 하지만 핵심은 간단합니다: 파일을 수정하고, 세이브하고, 보낸다. 이것만 기억하면, Git을 사용할 수 있습니다.