깃의 핵심 개념: 리포지토리, 커밋, 브랜치, 푸시, 풀, 머지

새벽 두 시, 웹사이트의 히어로 섹션을 수정하던 중 무언가 잘못됐습니다. 버튼의 글로우 효과를 바꾸려다가 전체 레이아웃이 무너져 버렸습니다. 세 시간 전의 상태로 돌아가고 싶지만, 그때의 코드가 어디에도 남아 있지 않습니다. Ctrl+Z를 수십 번 눌러도 이미 저장해 버린 파일은 되돌릴 수 없습니다.

깃(Git)은 이 문제를 해결하기 위해 만들어진 버전 관리 시스템(version control system)입니다. 프로젝트에 일어나는 모든 변경 사항을 추적하고, 원하는 시점으로 되돌릴 수 있게 해 줍니다. 비디오 게임의 체크포인트 저장과 비슷합니다. 의미 있는 변경을 할 때마다 스냅샷을 찍어 두면, 언제든 그 지점으로 되감을 수 있습니다.

깃의 세계를 구성하는 핵심 개념을 하나씩 살펴보겠습니다.

리포지토리(repository)는 깃이 감시하고 있는 폴더입니다. 프로젝트의 모든 파일과 그 파일들에 일어난 변경의 전체 역사가 이 안에 담겨 있습니다. 은행 계좌에 비유할 수 있습니다. 잔액뿐 아니라 모든 입출금 내역이 기록되어 있는 것처럼, 리포지토리에는 현재 코드뿐 아니라 과거의 모든 변경 기록이 보존됩니다.

커밋(commit)은 프로젝트의 특정 시점 스냅샷입니다. 각 커밋에는 무엇이 바뀌었는지와 왜 바꿨는지가 함께 기록됩니다. 워드 문서에서 "저장"을 누르는 것과 비슷하지만, 차이가 있습니다. 워드의 저장은 이전 상태를 덮어쓰지만, 깃의 커밋은 이전 상태를 그대로 남겨둔 채 새로운 스냅샷을 추가합니다.

"히어로 버튼에 글로우 효과 추가"라는 메시지와 함께 커밋하면, 나중에 이 커밋만 정확히 되돌릴 수 있습니다.

브랜치(branch)는 프로젝트의 별도 사본으로, 메인 버전에 영향을 주지 않고 실험할 수 있는 공간입니다. 기본 브랜치는 보통 메인(main)이라고 부릅니다. "feature-login"이라는 브랜치를 만들면, 로그인 기능을 실험하되 안정 버전은 건드리지 않겠다는 선언입니다.

푸시(push)는 내 컴퓨터 컴퓨터의 변경 사항을 원격 저장소로 보내는 행위입니다. 내 컴퓨터에서만 존재하던 커밋이 클라우드에 올라갑니다.

풀(pull)은 그 반대입니다. 원격 저장소의 최신 변경 사항을 내 컴퓨터로 가져옵니다.

머지(merge)는 두 브랜치의 변경 사항을 하나로 합치는 작업입니다. 실험이 성공적이었다면, 실험 브랜치를 메인 브랜치에 머지해서 안정 버전에 반영합니다.

[그림 14-1] 깃의 핵심 개념 관계도: 리포지토리 안에서 브랜치, 커밋, 머지가 어떻게 연결되는지

열차 궤도의 비유: 안정 버전을 보호하며 실험하는 방법

기차역을 떠올려 보겠습니다. 본선 궤도 위를 열차가 달리고 있습니다. 이 열차가 현재 운행 중인 안정 버전, 즉 메인 브랜치입니다. 승객을 태우고 있으므로, 궤도 위에서 레일을 뜯어내고 새로운 레일을 깔 수는 없습니다.

새로운 노선을 시험하고 싶다면 어떻게 해야 합니까? 본선에서 갈라져 나오는 시험 궤도를 만듭니다. 이 시험 궤도가 바로 브랜치입니다. 시험 궤도 위에서는 자유롭게 실험할 수 있습니다. 레일의 각도를 바꿔 보기도 하고, 새로운 정차역을 추가해 보기도 합니다. 본선의 열차 운행에는 아무런 영향이 없습니다.

시험이 끝나고 결과가 만족스러우면, 시험 궤도를 본선에 합류시킵니다. 이것이 머지입니다. 합류 지점에서 두 궤도가 자연스럽게 만나야 하므로, 충돌(conflict)이 없는지 확인하는 절차가 필요합니다. 만약 본선에서도 같은 구간을 수정했고 시험 궤도에서도 같은 구간을 수정했다면, 어떤 쪽의 변경을 채택할지 사람이 결정해야 합니다.

[그림 14-2] 열차 궤도 비유: 메인 브랜치(본선)에서 기능 브랜치(시험 궤도)가 분기되고 다시 합류하는 모습

이 비유가 실제 웹사이트 개발에서 어떻게 적용되는지 살펴보겠습니다.

앞 장에서 만든 웹사이트가 이미 배포되어 실제 사용자가 방문하고 있다고 가정합니다. 히어로 섹션의 버튼을 더 역동적으로 바꾸고 싶습니다. 메인 브랜치의 코드를 직접 수정하면, 변경 중에 사이트가 깨질 위험이 있습니다. 그 대신 feature-dynamic-button이라는 브랜치를 만들고, 그 안에서 버튼 코드를 수정합니다. 내 컴퓨터호스트에서 검증하고, 결과가 좋으면 메인 브랜치에 머지합니다.

클로드 코드에게 "이 변경 사항이 마음에 드니까 깃허브에 푸시해 줘"라고 말하기 전까지, 변경은 내 컴퓨터 브랜치 안에만 머뭅니다. 라이브 사이트에는 아무런 영향이 없습니다. 이것이 브랜치를 사용하는 근본적인 이유입니다. 안정된 것을 보호하면서 새로운 것을 시도할 수 있는 것입니다.

워크트리(worktree)라는 개념은 이 원리를 한 단계 더 확장합니다. 일반적으로 깃에서는 한 폴더에서 하나의 브랜치만 활성화할 수 있습니다. 다른 브랜치로 전환하려면 현재 작업을 저장하거나 커밋해야 합니다. 워크트리를 사용하면 같은 리포지토리에서 여러 브랜치를 동시에 다른 폴더에 체크아웃(checkout)할 수 있습니다.

클로드 코드에는 워크트리를 위한 내장 명령이 있어서, --worktree 옵션으로 격리된 작업 공간을 빠르게 만들 수 있습니다.

여러 클로드 코드 세션을 동시에 실행하면서, 각 세션이 서로 다른 기능을 개발하게 할 수 있습니다. 한 세션은 결제 페이지를 만들고, 다른 세션은 회원 가입 폼을 만들고, 또 다른 세션은 대시보드를 수정합니다. 각 세션이 독립된 브랜치와 워크트리에서 작업하므로, 서로의 코드를 덮어쓸 염려가 없습니다. 작업이 끝나면 각 브랜치를 메인에 머지하면 됩니다.

[그림 14-3] 워크트리를 활용한 병렬 개발: 세 개의 클로드 코드 세션이 각각 다른 브랜치에서 동시에 작업하는 구조

깃허브가 제공하는 클라우드 백업과 협업 기능

깃은 내 컴퓨터 컴퓨터에서 작동하는 도구입니다. 내 노트북의 하드 디스크에 변경 이력이 저장됩니다. 노트북이 고장 나면, 커밋 이력도 함께 사라집니다. 그리고 혼자 작업할 때는 내 컴퓨터 깃만으로 충분하지만, 다른 사람과 함께 프로젝트를 진행하려면 코드를 공유할 수 있는 공간이 필요합니다.

깃허브(GitHub)는 깃 리포지토리를 클라우드에 호스팅하는 서비스입니다. 깃이 버전 관리 "도구"라면, 깃허브는 그 도구로 관리되는 프로젝트를 저장하고 공유하는 "장소"입니다. 내 컴퓨터 컴퓨터의 워드 문서를 구글 문서도구에 올리는 것과 비슷합니다.

깃허브가 제공하는 핵심 기능은 다음과 같습니다.

클라우드 백업: 내 컴퓨터 리포지토리를 깃허브에 푸시하면, 코드의 전체 이력이 클라우드에 복제됩니다. 노트북이 고장 나더라도 깃허브에서 전체 프로젝트를 다시 가져올(클론할) 수 있습니다.

버전 이력 관리: 깃허브의 웹 인터페이스에서 모든 커밋을 시간순으로 확인할 수 있습니다. 각 커밋에서 어떤 파일의 어떤 줄이 바뀌었는지, 누가 바꿨는지, 왜 바꿨는지를 한눈에 볼 수 있습니다. 앞 장에서 "히어로 버튼에 글로우 펄스 효과 추가"라는 커밋을 만들었을 때, 깃허브에서 이 커밋을 클릭하면 정확히 어떤 코드가 변경되었는지 녹색(추가)과 빨간색(삭제)으로 표시됩니다.

풀 리퀘스트(Pull Request): 브랜치에서 작업한 변경 사항을 메인 브랜치에 합치기 전에, 다른 사람에게 검토를 요청할 수 있는 기능입니다. "이 코드를 메인에 합쳐도 될까요?"라는 공식적인 제안입니다. 여러 사람이 같은 프로젝트에서 작업할 때, 각자의 변경 사항이 충돌 없이 합쳐질 수 있는지 확인하는 관문 역할을 합니다.

공개와 비공개 설정: 리포지토리를 공개(public)로 설정하면 누구나 코드를 볼 수 있고, 비공개(private)로 설정하면 초대받은 사람만 접근할 수 있습니다. 웹사이트 코드에 API 키나 비밀번호가 포함되어 있지 않다면 공개로 두어도 되지만, 민감한 정보가 조금이라도 포함된 프로젝트는 반드시 비공개로 설정해야 합니다.

[그림 14-4] 깃허브 리포지토리 화면 구성: 커밋 이력, 브랜치 목록, 풀 리퀘스트 탭의 위치

한 가지 중요한 주의 사항이 있습니다. 깃허브에 코드를 푸시할 때, .env 파일이나 API 키가 포함된 파일이 함께 올라가지 않도록 주의해야 합니다. .gitignore라는 파일을 만들어서, 깃이 추적하지 말아야 할 파일 목록을 지정할 수 있습니다.

클로드 코드에게 "깃허브에 푸시할 준비를 해 줘"라고 요청하면, 보통 .gitignore 파일을 자동으로 생성해 줍니다. 그래도 푸시 전에 한 번 확인하는 습관이 필요합니다.

기본 워크플로우: 리포지토리 생성→클론→브랜치→커밋→PR→머지

실제로 깃과 깃허브를 사용하는 전체 흐름을 처음부터 끝까지 따라가 보겠습니다.

1단계: 깃허브에서 리포지토리 생성

깃허브에 로그인하고, "New Repository" 버튼을 클릭합니다. 이름을 "my-website"로 지정합니다. 설명은 선택 사항입니다. 공개 또는 비공개를 선택한 뒤 "Create Repository"를 클릭합니다. 텅 빈 리포지토리가 만들어집니다.

이 작업을 클로드 코드에게 맡길 수도 있습니다. "my-website라는 이름으로 깃허브 리포지토리를 만들고, 현재 프로젝트의 코드를 푸시해 줘"라고 요청하면, 리포지토리 생성부터 초기 커밋, 푸시까지 한 번에 처리합니다. 다만 깃허브 인증(authentication)이 필요합니다. 처음 한 번만 명령줄 방식를 통해 깃허브에 로그인하면, 이후에는 자동으로 인증이 유지됩니다.

2단계: 클론(clone)

이미 내 컴퓨터에서 개발 중인 프로젝트라면 클론 단계가 필요 없습니다. 반대로 다른 컴퓨터에서 작업을 이어가야 한다면, 깃허브의 리포지토리를 클론해서 내 컴퓨터에 복제합니다. 클론은 리포지토리의 모든 파일과 전체 변경 이력을 한꺼번에 가져오는 작업입니다.

3단계: 브랜치 생성과 작업

새로운 기능을 추가하거나 디자인을 변경할 때, 메인 브랜치에서 직접 작업하지 않습니다. 새 브랜치를 만들고 그 안에서 작업합니다. 클로드 코드는 이 관례를 알고 있으며, 브랜치 관리를 자연어로 요청할 수 있습니다.

4단계: 커밋

의미 있는 변경이 이루어질 때마다 커밋합니다. 커밋 메시지에는 변경의 목적을 간결하게 적습니다. "fix layout bug"보다 "히어로 섹션 카드 정렬 깨지는 문제 수정"이 나중에 이력을 추적할 때 유용합니다.

5단계: 푸시와 풀 리퀘스트

내 컴퓨터에서 만든 커밋을 깃허브에 푸시합니다. 깃허브에서 풀 리퀘스트를 열어, 메인 브랜치에 합칠 것을 제안합니다. 혼자 작업하는 경우에도 풀 리퀘스트를 활용하면, 변경 사항을 한 번 더 검토하는 기회가 됩니다.

6단계: 머지

풀 리퀘스트가 승인되면 메인 브랜치에 머지합니다. 머지가 완료된 기능 브랜치는 삭제해도 됩니다. 이력은 메인 브랜치의 커밋 기록에 남아 있습니다.

[그림 14-5] 깃/깃허브 기본 워크플로우 순서도

클로드 코드를 사용하면 이 여섯 단계의 대부분을 자연어로 처리할 수 있습니다. "히어로 버튼 변경이 마음에 든다. 깃허브에 푸시해 줘"라고 말하면, 클로드 코드가 변경된 파일을 스테이징(staging)하고, 적절한 커밋 메시지를 작성하고, 원격 리포지토리에 푸시합니다. 하지만 내부에서 일어나는 일의 원리를 이해하고 있어야, 문제가 생겼을 때 원인을 파악하고 해결할 수 있습니다.

코드가 깃허브에 안전하게 올라갔습니다. 변경 이력도 깔끔하게 기록되어 있습니다. 그러나 깃허브에 코드가 있다고 해서 누군가가 웹 브라우저로 접속해서 사이트를 볼 수 있는 것은 아닙니다. 코드 저장소와 라이브 웹사이트 사이에는 하나의 다리가 더 필요합니다.