Git 입문: 커밋·브랜치·머지를 '세이브 포인트'로 이해하고 첫 협업까지 해보기

서준2026년 11월 1일 12:49

Git을 처음 배우면 명령어보다 개념에서 먼저 막히는 경우가 많습니다. 스테이징은 왜 따로 있는지, 브랜치를 만들면 파일은 어디로 가는지, 충돌 메시지는 어떻게 읽는지 같은 것들입니다. 이 글은 버전 관리가 왜 필요한지에서 출발해 작업 디렉터리 → 스테이징 → 커밋의 흐름과 브랜치·머지를 게임의 '세이브 포인트'에 빗대어 설명합니다. 그다음 자주 쓰는 명령어 10개, 머지 충돌 해결법, Git과 GitHub의 차이까지 초보자가 실제로 걸려 넘어지는 지점을 중심으로 정리합니다.

버전 관리가 필요한 이유: 세이브 없는 게임을 떠올려 보기

세이브 기능이 없는 게임을 상상해 보세요. 보스 직전에서 실수하면 처음부터 다시 해야 합니다. 그래서 우리는 중요한 구간마다 저장해 두고, 일이 꼬이면 그 지점으로 돌아갑니다.

코드도 똑같습니다. 잘 돌아가던 프로그램이 어떤 수정 이후 갑자기 망가졌는데 무엇을 바꿨는지 기억나지 않는 상황, 누구나 한 번은 겪습니다. 그래서 흔히 최종.zip, 최종_진짜.zip, 최종_수정본2.zip 같은 파일을 만들게 되지만 이 방식은 곧 한계가 옵니다.

어떤 파일의 어느 줄이 바뀌었는지 비교하기 어렵습니다.
왜 바꿨는지 이유가 남지 않습니다.
여러 사람이 동시에 고치면 누구 것을 기준으로 합칠지 알 수 없습니다.

버전 관리 시스템은 이 문제를 해결합니다. 변경 내역을 시점별로 기록하고, 원하는 시점으로 되돌리고, 여러 갈래의 작업을 하나로 합칠 수 있게 해 줍니다. Git은 그중 가장 널리 쓰이는 도구입니다.

세이브 포인트가 만들어지는 3단계: 작업 디렉터리, 스테이징, 커밋

Git에서 '저장'은 한 번에 일어나지 않고 세 단계를 거칩니다. 초보자가 가장 헷갈리는 부분이니 비유로 정리해 보겠습니다.

작업 디렉터리(Working Directory): 지금 실제로 플레이 중인 화면입니다. 파일을 열어 고치는 모든 일이 여기서 일어나며, 아직 아무것도 기록되지 않았습니다.
스테이징 영역(Staging Area): 세이브 화면에서 '이번에 저장할 항목'을 고르는 단계입니다. git add로 원하는 변경만 골라 담습니다.
커밋(Commit): 실제로 세이브 버튼을 누르는 순간입니다. git commit을 하면 스테이징에 담긴 내용이 하나의 세이브 포인트로 기록되고, 메시지도 함께 남습니다.

왜 굳이 중간 단계가 있을까요? 파일 다섯 개를 고쳤는데 그중 로그인 기능 관련 두 개만 먼저 저장하고 싶을 때가 있기 때문입니다. 스테이징 덕분에 의미 단위로 깔끔한 세이브 포인트를 만들 수 있습니다. 나중에 기록을 되짚을 때 "로그인 버튼 추가", "오타 수정"처럼 하나의 커밋이 하나의 목적을 갖고 있으면 문제를 찾기 훨씬 쉽습니다.

커밋 메시지는 미래의 나에게 남기는 메모입니다. '수정함'보다 '회원가입 폼의 이메일 검증 추가'처럼 무엇을 왜 바꿨는지 적는 습관을 들이세요.

브랜치와 머지: 평행 세계에서 따로 플레이하고 합치기

게임에서 세이브 파일을 복사해 '다른 선택지'를 시험해 본 적이 있다면 브랜치를 이미 이해한 셈입니다. 브랜치는 현재 세이브 포인트에서 갈라져 나온 독립된 작업 줄기입니다.

보통 안정적인 코드는 main 브랜치에 두고, 새 기능은 별도 브랜치에서 개발합니다. 예를 들어 feature-login 브랜치를 만들어 마음껏 실험해도 main은 그대로 안전합니다. 실험이 실패하면 그 브랜치만 버리면 됩니다.

여기서 초보자가 자주 놀라는 점이 있습니다. 브랜치를 전환하면 작업 폴더 안의 파일 내용이 그 브랜치 상태로 바뀝니다. 파일이 사라진 것처럼 보여도 다른 브랜치에 그대로 저장되어 있으니 걱정하지 않아도 됩니다. 다만 커밋하지 않은 변경이 있는 상태로 전환하면 Git이 막거나 변경이 따라오는 일이 생기므로, 전환 전에는 커밋하거나 정리해 두는 편이 안전합니다.

기능이 완성되면 갈라졌던 세계를 다시 합칩니다. 이것이 머지(Merge)입니다. main으로 돌아와 feature-login을 병합하면, 그동안 쌓인 세이브 포인트가 main의 기록에 합쳐집니다. 두 브랜치가 서로 다른 부분을 고쳤다면 Git이 알아서 합쳐 주지만, 같은 곳을 다르게 고쳤다면 사람에게 판단을 맡기는데 이것이 뒤에서 다룰 머지 충돌입니다.

자주 쓰는 명령어 10개

처음부터 모든 명령어를 외울 필요는 없습니다. 아래 10개면 혼자 작업하고 간단한 협업을 시작하기에 충분합니다.

git init: 현재 폴더를 Git 저장소로 만듭니다. 세이브 기능을 켜는 단계입니다.
git status: 지금 어떤 파일이 바뀌었고 무엇이 스테이징되었는지 보여 줍니다. 막히면 가장 먼저 쳐 보세요.
git add 파일명: 변경을 스테이징에 담습니다. git add .은 현재 폴더의 변경을 모두 담습니다.
git commit -m "메시지": 스테이징된 내용을 세이브 포인트로 기록합니다.
git log: 지금까지의 커밋 기록을 봅니다. --oneline 옵션을 붙이면 한 줄씩 간결하게 보입니다.
git diff: 아직 스테이징하지 않은 변경 내용을 줄 단위로 비교합니다.
git branch 이름: 새 브랜치를 만듭니다. 이름 없이 쓰면 브랜치 목록을 보여 줍니다.
git switch 이름: 브랜치를 전환합니다. 예전 자료에서는 git checkout 이름으로 소개되는 경우가 많은데 같은 목적으로 쓸 수 있습니다. git switch -c 이름은 만들면서 바로 전환합니다.
git merge 이름: 지정한 브랜치를 현재 브랜치에 합칩니다.
git pull / git push: 원격 저장소에서 최신 내용을 가져오거나, 내 커밋을 올립니다. 협업의 핵심 명령어입니다.

명령어를 칠 때마다 git status로 상태를 확인하는 습관이 실수를 크게 줄여 줍니다.

머지 충돌이 났을 때 당황하지 않는 법

머지 도중 CONFLICT라는 메시지가 뜨면 많은 초보자가 뭔가 망가졌다고 생각합니다. 하지만 충돌은 오류가 아니라 "같은 줄을 두 사람이 다르게 고쳤는데 어느 쪽을 택할까요?"라는 질문입니다. 해결 순서는 다음과 같습니다.

git status로 충돌이 난 파일 목록을 확인합니다.
해당 파일을 열면 <<<<<<<, =======, >>>>>>> 표시가 보입니다. 위쪽은 현재 브랜치의 내용, 아래쪽은 합치려는 브랜치의 내용입니다.
둘 중 하나를 택하거나 두 내용을 적절히 섞어 원하는 최종 코드로 고칩니다.
표시 기호 세 종류를 모두 지웁니다. 이걸 남겨 두면 코드가 실행되지 않습니다.
git add 파일명으로 해결했음을 알리고 git commit으로 머지를 마무리합니다.

상황이 너무 꼬였다면 git merge --abort로 머지 시도 이전 상태로 돌아갈 수 있습니다. 세이브 포인트 비유로 말하면 '합치기 직전으로 되돌리기'입니다. VS Code 같은 편집기는 충돌 부분을 색으로 구분하고 '현재 변경 수락', '수신 변경 수락' 같은 버튼을 제공하므로 처음에는 이런 도구의 도움을 받는 것도 좋습니다.

충돌을 줄이는 습관도 함께 기억해 두세요.

작업을 시작하기 전에 git pull로 최신 상태를 받습니다.
브랜치를 너무 오래 끌지 말고 작은 단위로 자주 합칩니다.
같은 파일을 여러 사람이 동시에 크게 고치지 않도록 역할을 미리 나눕니다.

Git과 GitHub의 차이, 그리고 첫 협업 흐름

이름이 비슷해서 헷갈리지만 둘은 다른 것입니다. Git은 내 컴퓨터에서 돌아가는 버전 관리 프로그램이고, GitHub는 Git 저장소를 인터넷에 올려 두고 공유·협업할 수 있게 해 주는 서비스입니다. 게임으로 치면 Git은 세이브 기능 자체이고, GitHub는 세이브 파일을 올려 두는 클라우드이자 친구들과 함께 보는 공간입니다. GitHub 없이도 Git은 쓸 수 있고, 비슷한 서비스로 GitLab이나 Bitbucket 등도 있습니다.

개념과 명령어를 화면으로 따라가 보고 싶다면 드림코딩 채널의 "깃, 깃허브 제대로 배우기 (기본 마스터편, 실무에서 꿀리지 말자)" 영상을 함께 보는 것을 권합니다. 제목처럼 Git과 GitHub의 기본기를 다루는 영상이니, 이 글의 비유로 큰 그림을 잡은 뒤 실제 사용 장면을 확인하는 용도로 활용해 보세요.

처음 협업을 해 본다면 다음 흐름을 그대로 따라가 보세요.

GitHub에 저장소를 만들고 팀원에게 접근 권한을 줍니다.
각자 git clone으로 저장소를 내 컴퓨터에 복제합니다.
작업 전 git pull로 최신 상태를 받고, git switch -c feature-이름으로 내 브랜치를 만듭니다.
작업하면서 add와 commit으로 세이브 포인트를 쌓습니다.
git push로 내 브랜치를 GitHub에 올립니다. 처음 올리는 브랜치라면 Git이 안내하는 업스트림 설정 명령을 함께 쓰면 됩니다.
GitHub에서 Pull Request를 열어 "이 브랜치를 main에 합쳐 주세요"라고 요청하고, 팀원이 코드를 검토한 뒤 머지합니다.
머지가 끝나면 로컬의 main으로 돌아와 다시 git pull을 해서 최신 상태를 맞춥니다.

이 사이클을 몇 번만 반복해도 커밋, 브랜치, 머지가 왜 이렇게 설계되었는지 몸으로 이해하게 됩니다. 처음에는 연습용 저장소를 하나 만들어 일부러 같은 줄을 다르게 고친 뒤 충돌을 내 보고 해결해 보세요. 실제 프로젝트에서 충돌을 만났을 때 훨씬 침착하게 대응할 수 있습니다.

이 글은 AI(Claude)로 작성되었습니다. 중요한 정보는 다른 자료로 한 번 더 확인해 주세요.