소개
이야기를 쓰고 있다고 상상해 보세요. 줄거리가 두 가지 방향으로 나뉠 수 있는 지점에 도달했습니다. 영웅이 용과 싸울 수도 있고, 용과 친구가 될 수도 있습니다. 어느 쪽이 더 나은지 확인하기 위해 두 버전을 모두 작성하고 싶지만, 주 원고를 망치고 싶지는 않습니다.
Git 에서는 **브랜치 (branching)**를 사용해 바로 이 작업을 할 수 있습니다. 브랜치는 안전하게 실험할 수 있는 병렬 개발 흐름을 만듭니다. 브랜치는 격리된 작업을 저렴하고 쉽게 만들어 주므로 Git 에서 가장 중요한 개념 중 하나입니다.
Git 에서 브랜치는 프로젝트의 전체 복사본이 아닙니다. 주로 커밋 흐름을 가리키는 이동 가능한 포인터입니다. 따라서 브랜치를 빠르고 가볍게 만들 수 있습니다.
- 기능 개발: 별도의 공간에서 새로운 로그인 시스템을 만듭니다.
- 실험: 현재 웹사이트를 망가뜨리지 않고 새로운 디자인 아이디어를 시도합니다.
- 버그 수정: 중요한 오류를 격리된 환경에서 수정합니다.
이 실습에서는 병렬 타임라인 (브랜치) 을 만들고, 그 안에서 변경한 다음, 기본 타임라인으로 돌아가 실험 내용이 원래 프로젝트에 영향을 주지 않았는지 확인합니다.
기능 브랜치 만들기
기본적으로 모든 Git 저장소에는 하나의 기본 브랜치가 있으며, 일반적으로 master 또는 main이라고 합니다. 이를 프로젝트의 공식적이고 안정적인 버전인 "기본 타임라인"이라고 생각하면 됩니다.
로그인 페이지와 같은 새 기능을 기본 프로젝트의 안정성을 해치지 않고 작업하려면 새 브랜치를 만듭니다.
현재 위치를 확인합니다.
git branch
출력:
* master
*는 현재 master 타임라인에 있다는 뜻입니다.
이 표시는 현재 브랜치 컨텍스트를 보여 줍니다. Git 의 여러 명령은 HEAD가 현재 가리키는 브랜치를 기준으로 동작하므로, 현재 위치를 아는 것이 중요합니다.
feature_login이라는 새 브랜치를 만듭니다.
git branch feature_login
이제 새 타임라인을 만들었습니다. 하지만 아직 그 타임라인으로 이동한 것은 아닙니다.
여기서 Git 의 중요한 차이점을 확인할 수 있습니다. 브랜치를 만드는 작업과 브랜치로 전환하는 작업은 별개입니다. 브랜치가 존재하더라도 현재 작업 컨텍스트가 아닐 수 있습니다.
브랜치가 생성되었는지 확인합니다.
git branch
출력:
feature_login
* master
feature_login 브랜치는 존재하지만, *가 표시된 위치를 보면 여전히 master에 있습니다.
새 브랜치로 전환하기
타임라인을 만드는 것만으로는 충분하지 않습니다. 해당 타임라인으로 이동해야 합니다. 브랜치를 전환할 때 사용하는 명령은 git checkout입니다.
새 브랜치로 전환합니다.
git checkout feature_login
출력:
Switched to branch 'feature_login'
이동했는지 확인합니다.
git branch
출력:
* feature_login
master
별표 (*) 가 이동했습니다. 이제 feature_login 타임라인에서 작업하고 있습니다. 지금부터 변경하는 내용은 이 타임라인에만 적용됩니다.
더 정확히 말하면, 이제 만드는 새 커밋은 master가 아니라 feature_login을 앞으로 진행시킵니다. 두 브랜치는 서로 갈라진 시점까지의 이전 기록을 계속 공유합니다.
기능 브랜치에서 작업하기
이제 안전하게 실험할 수 있는 공간에 들어왔으므로 코드를 작성합니다. "로그인 기능"을 위한 스크립트를 만듭니다.
login.sh라는 파일을 만듭니다.
echo "echo 'Logging in...'" > login.sh
현재 디렉터리에 파일이 있는지 확인합니다.
ls
master에서 상속된 README.md와 새로 만든 login.sh가 모두 표시되어야 합니다.
이 시점에서 login.sh는 디스크에 있는 파일일 뿐입니다. 이 파일을 이 브랜치의 기록에 정식으로 저장하려면 커밋해야 합니다.
이 과정은 브랜치의 개념을 다시 보여 줍니다. 파일은 작업 트리에 나타나지만, 해당 브랜치의 기록은 그 브랜치에서 커밋을 만들어야만 변경됩니다.
브랜치에 변경 사항 커밋하기
이제 작업 내용을 저장합니다. 표준 Git 작업 흐름을 기억하세요. 초기화 -> 스테이징 -> 커밋입니다.
상태를 확인합니다.
git status
login.sh가 추적되지 않는 파일 (Untracked) 로 표시됩니다.
파일을 스테이징합니다.
git add login.sh
feature_login 기록에 파일을 커밋합니다.
git commit -m "Add login feature script"
출력:
[feature_login 8a2b3c] Add login feature script
이제 이 변경 사항을 영구적으로 기록했지만, feature_login 타임라인에만 기록했습니다.
브랜치가 유용한 이유는 바로 이러한 격리 기능에 있습니다. 준비가 될 때까지 기본 브랜치를 앞으로 진행시키지 않고 기능을 개발하거나 테스트하거나 실험할 수 있습니다.
브랜치 격리 확인하기
이제 중요한 순간입니다. feature_login이 master와 분리된 별도의 세계라고 했습니다. master로 돌아가 이를 확인합니다.
master 브랜치로 다시 전환합니다.
git checkout master
출력:
Switched to branch 'master'
파일을 확인합니다.
ls
login.sh는 어디에 있나요? 사라졌습니다!
이것이 바로 우리가 확인하려던 결과입니다. master 타임라인에는 login.sh 파일이 존재하지 않습니다. 실험 내용이 안전하게 격리되어 있습니다.
파일이 영원히 사라진 것이 아닌지 확인하려면 기능 브랜치로 다시 전환합니다.
git checkout feature_login
ls
파일이 다시 나타납니다! 타임라인 사이를 전환하면 Git 이 디렉터리의 파일을 즉시 바꿉니다.
요약
이 실습에서는 브랜치의 강력한 기능을 배웠습니다.
- 안전성: 기본 코드 (
master) 에 영향을 줄 위험 없이 별도의 브랜치 (feature_login) 에서 새 기능을 개발할 수 있습니다. - 컨텍스트 전환:
git checkout을 사용하여 병렬 타임라인 사이를 전환했습니다. - 격리: 한 브랜치에서 커밋한 변경 사항이 다른 브랜치에는 나타나지 않는다는 것을 확인했습니다.
전문 개발팀은 이러한 방식으로 작업합니다. 새로운 기능이나 버그 수정마다 브랜치를 만들어 기본 코드베이스를 깨끗하고 안정적으로 유지합니다.
