Git 커밋과 브랜치를 게임 저장 지점처럼 이해하기

AI에게 "디자인을 전부 바꿔 줘"라고 부탁했는데 이전 화면이 더 나았던 경험은 금방 생깁니다. 파일을 복사해 최종, 진짜최종, 최종2 폴더를 만드는 방법도 잠깐은 통하지만 변경이 많아지면 무엇이 다른지 알기 어렵습니다.

Git은 파일의 변화를 기록하고 과거 상태를 찾아갈 수 있게 하는 버전 관리 도구입니다. 게임의 저장 지점과 비슷하지만, 어떤 파일을 왜 바꿨는지 묶어서 기록하고 여러 작업 줄기를 나눌 수 있다는 점이 더 강력합니다.

저장과 커밋은 같은 말이 아니다

에디터에서 저장 버튼을 누르면 현재 파일 내용이 디스크에 기록됩니다. Git 커밋은 여러 파일의 의미 있는 상태를 하나의 기록으로 남깁니다. 파일을 저장했다고 자동으로 커밋되는 것은 아닙니다.

Git은 프로젝트의 현재 파일을 작업 폴더에서 봅니다. 그중 다음 기록에 넣을 변경을 스테이징 영역에 고르고, 선택한 변경으로 커밋을 만듭니다.

작업 폴더의 변경 → git add로 선택 → git commit으로 기록

처음에는 이 중간 단계가 번거롭게 느껴질 수 있습니다. 하지만 디자인 파일은 빼고 로그인 오류 수정만 기록하는 것처럼 관련된 변경만 한 묶음으로 만들 수 있어 나중에 이유를 찾기 쉬워집니다.

저장소는 프로젝트 기록을 담는 공간이다

기존 폴더에서 git init을 실행하면 .git이라는 숨김 폴더가 생기고 Git 저장소가 시작됩니다. 다른 곳의 저장소를 통째로 받아올 때는 git clone을 사용합니다.

커밋에는 그 시점의 파일 상태를 다시 만들 수 있는 정보와 작성자, 시각, 설명, 이전 커밋을 가리키는 연결이 들어갑니다. Git 공식 문서는 파일 차이 목록만 쌓는 이미지보다 각 시점의 스냅샷으로 이해하는 방식을 강조합니다.

좋은 커밋은 너무 크지도 작지도 않습니다. 메뉴 추가, 로그인 오류 수정, 문구 정정처럼 한 문장으로 설명할 수 있는 작업 단위가 좋습니다.

브랜치는 안전한 별도 작업 줄기다

브랜치는 현재 커밋을 가리키는 가벼운 이름표에 가깝습니다. 새 브랜치를 만들면 안정적인 기본 줄기를 그대로 둔 채 다른 방향의 작업을 이어갈 수 있습니다.

예를 들어 main 브랜치가 공개 중인 안정 버전이라면 add-study-menu 브랜치에서 공부 메뉴를 개발합니다. 테스트가 끝난 뒤 기본 브랜치에 합칩니다. 실패하면 기본 브랜치는 건드리지 않고 실험 브랜치만 고칠 수 있습니다.

브랜치가 프로젝트 전체를 한 번 더 복사하는 것은 아닙니다. Git은 커밋 연결을 이용해 작업 줄기를 관리하므로 새 브랜치를 빠르게 만들 수 있습니다.

초보자가 먼저 익힐 다섯 명령

1. git status는 바뀐 파일과 현재 브랜치를 보여 줍니다.
2. git diff는 아직 커밋하지 않은 실제 차이를 보여 줍니다.
3. git add 파일명은 다음 커밋에 넣을 변경을 고릅니다.
4. git commit -m "메시지"는 선택한 변경을 기록합니다.
5. git log --oneline은 커밋 기록을 짧게 보여 줍니다.

git status
git diff
git add src/pages/Study.tsx
git commit -m "Add beginner study menu"
git log --oneline -5

처음부터 되돌리기 명령을 외우기보다 상태와 차이를 읽는 습관을 들이는 편이 안전합니다. git status와 git diff는 내용을 바꾸지 않는 조회 명령이므로 작업 전후에 자주 실행해도 됩니다.

AI에게 맡기기 전과 후에 확인할 것

AI 코딩 도구는 여러 파일을 빠르게 바꿉니다. 작업 전에 이미 수정된 파일이 있다면 새 변경과 섞일 수 있습니다. 먼저 현재 상태를 확인하고, 무엇을 보존해야 하는지 알려 줘야 합니다.

• 시작 전에 git status로 기존 변경을 확인합니다.
• 작업 목표 하나마다 별도 브랜치를 고려합니다.
• AI에게 기존 변경을 지우거나 덮어쓰지 말라고 명확히 말합니다.
• 작업 뒤 git diff로 예상하지 않은 파일이 바뀌지 않았는지 봅니다.
• 테스트가 통과한 뒤 의미가 분명한 커밋 메시지를 남깁니다.
• 비밀번호와 API 키가 차이에 보이면 커밋하지 않습니다.

특히 reset --hard나 파일을 강제로 되돌리는 명령은 커밋하지 않은 작업을 잃게 할 수 있습니다. 뜻을 모르는 상태에서는 실행하지 말고, 현재 상태와 되돌리고 싶은 범위를 먼저 확인해야 합니다.

오늘 바로 해볼 작은 실습

연습용 폴더에 텍스트 파일 하나를 만들고 첫 커밋을 남겨 보세요. 한 줄을 고친 뒤 git diff로 차이를 확인하고 두 번째 커밋을 만듭니다. 마지막으로 git log --oneline에서 두 저장 지점이 보이는지 확인합니다.

처음 실습에서는 원격 저장소에 올리는 push까지 할 필요가 없습니다. 내 컴퓨터 안에서 두 커밋을 만들고 차이를 읽는 데 집중합니다. 각 커밋 메시지는 "수정"보다 "소개 문장 추가", "가격 표 오탈자 수정"처럼 나중에 봐도 작업을 알 수 있게 씁니다.

새 브랜치도 한 번 만들어 봅니다. 브랜치를 만든 뒤 텍스트 한 줄을 바꾸고 git status에서 현재 브랜치 이름을 확인합니다. 기본 브랜치로 돌아왔을 때 연습 변경이 보이지 않는다면 두 작업 줄기가 나뉜 것을 눈으로 확인한 셈입니다. 명령이 익숙하지 않다면 사용하는 편집기의 Git 화면에서 같은 흐름을 따라가도 괜찮습니다.

커밋은 실수를 없애 주는 마법이 아닙니다. 다만 작은 단위로 기록하면 언제 무엇이 달라졌는지 설명할 수 있고, 문제가 생겼을 때 돌아갈 기준점이 생깁니다. 바이브코딩에서 코드를 직접 다 이해하지 못하더라도 이 기준점은 스스로 지킬 수 있습니다.