Git 브랜치 커밋 add 개념, 최대한 쉽게 폴더 파일 예시로 설명합니다

 

Git 브랜치, 커밋, add 개념을 처음 접하면 까만 터미널 화면 때문에 무척 헷갈리고 두렵기 마련입니다. 하지만 우리가 윈도우나 맥에서 매일 쓰는 '폴더'와 '파일'이라는 개념에 대입해 보면 아주 쉽고 명확하게 이해할 수 있습니다.

"브랜치는 도대체 뭔가요? 나뭇가지?" "add랑 commit은 뭐가 다른 거죠? 그냥 바로 저장하면 안 되나요?" "검은 화면에 명령어 칠 때마다 코드가 날아갈까 봐 무서워요."

제가 처음 웹 개발을 시작했던 2012년 무렵만 해도, 프로젝트 백업을 한답시고 '기획전_최종.zip', '기획전_진짜최종_수정.zip' 같은 폴더와 압축 파일을 수십 개씩 바탕화면에 쌓아두곤 했습니다. 그러다 어떤 파일이 최신인지 몰라서 며칠 밤을 새운 적도 있죠.

오늘은 복잡한 구조도, 어려운 원리 설명도 다 빼겠습니다. 오직 우리가 아주 잘 아는 **탐색기 폴더와 파일**이라는 키워드로 Git의 핵심을 아주 쉽게 풀어보겠습니다. 이제 막 코딩을 시작해서 버전 관리가 낯선 분들에게 가장 직관적인 가이드가 되길 바랍니다.

목차

1. Git, 까만 화면부터 켜면 포기하게 됩니다
2. 개발자의 탐색기: 브랜치는 폴더, 커밋은 파일
3. git branch: 안전한 '복사본 폴더' 만들기
4. git add: 파일은 생성했지만 아직 '저장 전' 상태
5. git commit: 최종 '파일'로 확정 짓고 도장 찍기
6. 실전 압축: 폴더 파고, 대기하고, 파일 만들기 흐름도
7. 초보자가 가장 많이 하는 Git 실수 3가지
8. 그냥 폴더 복사붙여넣기를 쓰면 안 되는 진짜 이유
9. 자주 묻는 질문 (FAQ)

1. Git, 까만 화면부터 켜면 포기하게 됩니다

처음 Git을 배울 때 가장 큰 진입 장벽은 눈에 잘 보이지 않는다는 점입니다. 마우스로 폴더를 드래그해서 옮기던 습관에서 벗어나, 키보드로 영문 명령어를 쳐야 하니 내가 지금 무슨 짓을 하고 있는지 파악하기 어렵죠.

특히 '분산 버전 관리 시스템'이라는 거창한 기술 용어가 우리를 주눅 들게 합니다. 하지만 껍데기를 벗겨내고 본질을 파고들면, Git은 그저 아주 꼼꼼하고 똑똑한 윈도우 탐색기(혹은 맥의 파인더)와 다를 바 없습니다.

이제 터미널 창의 깜빡이는 커서는 잊어버리세요. 바탕화면에 있는 노란색 폴더 아이콘 하나와 그 안에 들어있는 텍스트 파일 하나만 떠올리면 Git을 정복할 준비는 끝납니다.

2. 개발자의 탐색기: 브랜치는 폴더, 커밋은 파일

복잡한 기술 용어는 잠시 치워두고, Git의 3대장(Branch, Add, Commit)을 우리가 매일 쓰는 컴퓨터 탐색기 작업에 1:1로 매칭해 보겠습니다. 이 표 하나만 머릿속에 넣어두셔도 오늘 글의 절반은 이해하신 겁니다.

Git 필수 개념	윈도우 탐색기 비유
git branch	새로운 '폴더' 만들기 (원본을 건드리지 않는 복사본 폴더)
git add	'파일'은 생성(수정)했지만 아직 '저장 전'인 대기 상태
git commit	최종 '파일'로 버전을 확정 지어 하드디스크에 저장하기

표를 보시면 감이 오시죠? 브랜치(Branch)는 새 폴더를 파는 것이고, 커밋(Commit)은 그 폴더 안에 내용물을 파일 형태로 꽉 묶어서 저장하는 겁니다. 그리고 가장 헷갈려하시는 애드(Add)는 파일을 만들거나 글자는 썼지만, 아직 Ctrl+S를 눌러서 완전히 저장하기 직전의 붕 떠 있는 상태라고 보시면 됩니다.

반응형

3. git branch: 안전한 '복사본 폴더' 만들기

개인적으로 초보자들이 처음에 가장 두려워하면서도, 원리를 알고 나면 무릎을 탁 치는 기능이 바로 git branch입니다.

우리가 보통 정말 중요한 발표 자료(파일)를 대대적으로 뜯어고치기 전에 어떻게 하나요? 바탕화면의 '발표원본_폴더'를 마우스 우클릭해서 복사한 다음, '발표원본_수정테스트_폴더'를 만들어서 그 안에서 이것저것 안전하게 고쳐보곤 합니다. 망치면? 쿨하게 테스트 폴더를 휴지통에 버리면 그만이니까요.

💡 브랜치는 똑똑한 폴더 복사기입니다 Git에서 브랜치를 새로 만든다는 건, 현재 작업 중인 메인 폴더의 '복사본 폴더'를 가상으로 하나 똑같이 떠놓는 것과 완벽하게 동일한 개념입니다.

예를 들어 팀의 뼈대가 되는 main 브랜치가 있을 때, 여기서 새로운 브랜치를 만들면 main 폴더를 통째로 복사해서 새 폴더를 만든 것과 같습니다. 이제 새 폴더 안에서 코드를 다 지우고 화면을 부숴놔도, main 폴더의 원본 코드는 안전하게 보호됩니다.

# 'login-test'라는 이름의 새로운 복사본 폴더(브랜치) 생성하기
git branch login-test

# 내가 작업할 공간을 방금 만든 'login-test' 폴더 안으로 이동하기
git checkout login-test

4. git add: 파일은 생성했지만 아직 '저장 전' 상태

새로운 폴더(브랜치)에 들어왔으니 이제 코드를 짜야겠죠? 문서를 하나 새로 만들고(파일 생성), 그 안에 코드를 몇 줄 끄적였습니다(파일 수정). 일반적인 문서 작업이라면 그냥 여기서 저장 버튼을 누르면 끝이겠지만, Git은 한 단계를 더 거칩니다. 바로 git add입니다.

이 개념은 "파일은 생성(수정)했지만 아직 확정 저장하기 전" 상태라고 이해하시면 가장 정확합니다. 온라인 쇼핑몰의 '장바구니'와도 똑같습니다.

📌 그냥 바로 저장하면 안 되나요? (Add가 필요한 이유) 파일 3개를 동시에 수정했다고 칩시다. A파일은 로그인 기능, B파일은 글꼴 변경, C파일은 회원가입 기능입니다. 이걸 한 번에 다 묶어서 저장해 버리면 나중에 관리하기 힘듭니다. 그래서 A파일만 먼저 Add(대기열에 올림)해서 하나의 파일로 확정(Commit) 짓고, 그다음 B와 C를 따로 처리할 수 있게 선택권을 주는 겁니다.

우리가 엑셀이나 워드를 켜놓고 막 글씨를 치고 있을 때, 컴퓨터 전원이 나가면 내용이 날아가죠? 아직 디스크에 '확정 저장'이 안 되었기 때문입니다. Git에서 add 명령어는 바로 그 중간 단계에 파일들을 예쁘게 모아두는 작업입니다.

# 내가 수정한 특정 파일 하나만 '저장 대기' 상태로 올리기
git add index.html

# 현재 폴더에서 수정한 모든 파일을 한 번에 싹 다 '저장 대기' 상태로 올리기
git add .

5. git commit: 최종 '파일'로 확정 짓고 도장 찍기

앞서 add를 통해 수정된 내용들을 대기열(장바구니)에 잘 올려두었다면, 이제 진짜 결제를 확정 짓고 도장을 쾅 찍을 차례입니다. 이게 바로 git commit입니다.

폴더 안에서 며칠간 쪼물딱거리며 작업하던 내용들이 하나의 찰칵! 하는 스냅샷 사진처럼 굳어져서 영구적인 '파일' 상태로 기록되는 순간입니다. 커밋을 할 때는 반드시 포스트잇에 메모를 남겨서 이 파일 겉면에 붙여줘야 합니다. "나 이거 왜 고쳤어"라고 이유를 적어두는 것이죠.

# 대기 상태(add)에 있는 것들을 최종 파일로 확정(commit)하며 메모 남기기
git commit -m "로그인 버튼 색상을 파란색으로 변경 완료"

이렇게 정성스럽게 남겨둔 커밋 메시지들이 나중에 히스토리로 주르륵 남게 됩니다. 나중에 "아, 그때 로그인 버튼 언제 파란색으로 바꿨더라?" 하고 과거로 돌아가고 싶을 때, 이 파일(커밋)들을 열어보며 길을 찾는 이정표 역할을 합니다.

6. 실전 압축: 폴더 파고, 대기하고, 파일 만들기 흐름도

지금까지 배운 브랜치(폴더), 애드(저장 전 대기), 커밋(확정 파일) 세 가지 개념이 터미널에서 어떻게 맞물려 돌아가는지 표로 쭉 정리해 보았습니다. 바탕화면에서 겪는 일들과 비교하며 읽어보세요.

순서	Git 명령어	우리의 머릿속 탐색기 상황
1. 준비	git checkout -b new-work	안전하게 작업할 '복사본 폴더'를 새로 파고 들어감
2. 작업	(코드 수정 및 파일 만들기)	새 폴더 안에서 텍스트 문서를 열심히 고치고 타이핑함
3. 대기	git add .	수정한 내용들을 '저장 전' 대기 상태로 모아둠
4. 확정	git commit -m "작업완료"	대기 중인 내용을 영구적인 '파일' 상태로 박제하고 도장 찍음

실제 2026년 현재 현업에서도 수많은 개발자들이 하루에도 수십 번씩 이 1단계부터 4단계까지의 사이클을 쳇바퀴처럼 반복하며 거대한 프로그램을 만들어가고 있습니다. 전혀 특별하거나 무서운 과정이 아닙니다.

7. 초보자가 가장 많이 하는 Git 실수 3가지

비유를 통해 개념을 머리로는 이해해도, 키보드를 치는 손가락이 익숙해지기 전까지는 누구나 실수를 연발합니다. 제가 신입 시절에 했거나, 주변 주니어분들 자리에서 자주 목격하는 흔한 실수 패턴들을 미리 체크해 두세요.

7.1 대기(add) 없이 바로 확정(commit) 때리기

제일 흔하게 나오는 당황스러운 패턴입니다. 코드를 잔뜩 고쳐놓고 뿌듯한 마음에 git commit -m "코드 고침" 명령어만 덩그러니 치는 경우죠. 대기열(add)에 올라간 파일이 단 하나도 없으니 당연히 저장(commit)할 것도 없습니다. Git은 무심하게 "저장할 내용이 없다"라고 튕겨냅니다. 반드시 add를 먼저 해서 "이 파일들을 저장할 거야"라고 알려줘야 합니다.

7.2 커밋 포스트잇 메모 성의 없이 적기

귀찮다고 commit -m "수정", commit -m "진짜수정" 이렇게 대충 남기면 나중에 과거 코드를 뒤져야 할 때 엄청난 재앙이 찾아옵니다. 서류철 겉면에 '서류1', '서류2'라고만 적어둔 것과 똑같습니다. "장바구니 결제 버튼 오타 수정"처럼 미래의 나와 동료들을 위해 명확하게 적는 습관이 생명입니다.

7.3 메인 폴더(main 브랜치)에서 그냥 작업해버리기

안전한 '복사본 폴더(새 브랜치)'를 딴 줄 알았는데, 깜빡 잊고 원본 폴더(main 혹은 master 브랜치)에서 코드를 마구 고쳐버리는 아찔한 실수입니다. 치명적인 오류가 발생하면 모두가 공유하는 원본이 망가질 수 있으므로, 키보드에 손을 올리기 전에 git branch 명령어로 현재 내가 서 있는 폴더 위치가 어디인지 확인하는 버릇을 들여야 합니다.

8. 그냥 폴더 복사붙여넣기를 쓰면 안 되는 진짜 이유

여기까지 읽으셨다면 한 가지 근본적인 의문이 들 수 있습니다. "어차피 폴더 복사하고 파일 저장하는 거랑 똑같은 원리면, 그냥 윈도우 탐색기 열고 마우스 우클릭해서 복사붙여넣기 하면 되는 거 아닌가요? 굳이 왜 이렇게 명령어를 치나요?"

혼자서 하루 이틀 깔짝거리는 소규모 개인 과제라면 사실 그래도 됩니다. 하지만 현업에서는 적게는 서너 명, 많게는 수백 명의 개발자가 같은 프로젝트 덩어리를 동시에 이리저리 수정합니다.

만약 각자 폴더를 통째로 압축해서 슬랙 같은 메신저로 주고받는다고 상상해 보세요. 누구의 파일이 제일 최신인지, 어제 퇴근 전에 누가 A줄을 지우고 B줄을 넣었는지 병합하고 추적하는 것은 인간의 영역이 아닙니다. Git은 이 모든 '폴더와 파일 내부의 아주 미세한 글자 단위 변화'를 기가 막히게 추적해서 기록하고, 여러 사람이 제각각 만든 복사본(브랜치)을 서로 마찰이나 충돌 없이 하나로 예쁘게 엮어주는 아주 강력한 심장을 가지고 있습니다.

9. 자주 묻는 질문 (FAQ)

명령어 치다가 실수로 쓴 코드가 다 날아가면 어떡하나요?

Git은 여러분이 생각하는 것보다 코드를 날려먹지 못하도록 훨씬 방어적이고 끈질기게 설계되어 있습니다. 습관처럼 커밋(commit)만 틈틈이 해두었다면, 거의 모든 과거의 찰나로 타임머신을 타고 복구할 수 있습니다. 윈도우 탐색기에서 파일을 영구 삭제하는 것보다 Git에서 코드를 영구 삭제하는 게 훨씬 어렵습니다. 안심하고 연습하세요.

마우스로 클릭하는 GUI 프로그램(소스트리, 깃허브 데스크탑)을 쓰면 안 되나요?

물론 쓰셔도 됩니다. 시각적으로 코드의 변화 흐름을 폴더 트리처럼 쫙 보여주기 때문에 초보자에게 아주 친절합니다. 다만, 본문에서 설명해 드린 add, commit, branch의 보이지 않는 내부 흐름을 머릿속에 이해한 상태에서 마우스를 클릭하는 것과, 무지성으로 화면에 뜬 초록색 버튼만 누르는 것은 나중에 실무에서 코드가 꼬였을 때 복구 능력이 천지차이로 벌어집니다.

터미널의 시커먼 배경색에 지레 압도당하지 마세요. 실체를 알고 나면 거창한 해킹 시스템이 아니라, 그저 여러분의 소중한 코드를 안전하게 보관해 주는 똑똑한 탐색기 폴더일 뿐입니다. 오늘 당장 테스트용 빈 폴더를 하나 만들고, 그 안에 파일을 끄적여서 저장(add, commit)해 보는 가벼운 실습부터 무작정 시작해 보시길 응원합니다.

📚 함께 보면 좋은 글

git 머지와 리베이스 쉬운 설명, 팀과 상황에 따라서 선택해서 써야 합니다.

Git 역사, 리누스가 열흘 만에 만든 버전관리 도구

젯브레인 IDE가 유독 똑똑한 이유, 첫 제품은 IDE가 아니었습니다