지금까지는 main이라는 하나의 갈래에서만 작업했습니다. 그런데 실제 개발에서는 '지금 잘 돌아가는 버전은 그대로 두고, 새 기능은 따로 실험하고 싶은' 순간이 많습니다. 이때 쓰는 것이 브랜치(branch)입니다.
브랜치 = 평행세계, 실험용 사본
브랜치는 지금 상태를 그대로 복사한 '평행세계'입니다. 게임에서 세이브를 하나 복사해 두고, 그 복사본에서 위험한 도전을 해 보는 것과 같습니다. 복사본(브랜치)에서 무슨 짓을 해도 원본(main)은 멀쩡합니다. 실험이 성공하면 그 결과만 원본에 합치고, 망하면 복사본을 버리면 됩니다.
왜 main에서 바로 작업하지 않나요?
- main은 '항상 정상 작동하는 안정 버전'으로 지켜야 합니다. 여기서 바로 실험하면 작업 도중 코드가 깨진 채로 남습니다.
- 여러 기능을 동시에 개발할 때, 각 기능을 브랜치로 나누면 서로 방해하지 않습니다.
- 실험이 잘못돼도 브랜치만 버리면 되니, 되돌리기가 깔끔합니다.
브랜치가 갈라졌다가 다시 합쳐지는 모습
- main에서 분기 feature 브랜치가 main에서 갈라져 나옴
- feature에서 작업 새 기능을 안전하게 개발하며 커밋(세이브포인트)을 쌓음
- main으로 병합(merge) 완성된 기능을 main에 다시 합쳐 기능이 합쳐짐
main에서 feature 브랜치가 갈라져 작업하다가, 완성되면 다시 main으로 병합됩니다.
새 브랜치 만들고 이동하기
브랜치를 만들면서 그 브랜치로 이동하는 명령은 git switch -c 입니다. -c는 create(생성)의 c입니다. 예전에는 git checkout -b 를 썼는데, 지금도 동작하지만 checkout은 기능이 너무 많아 헷갈리기 쉬워서, 요즘은 브랜치 전환 전용인 git switch 사용을 권장합니다.
브랜치 만들고 작업하기
# 새 브랜치를 만들면서 그리로 이동 (-c = 생성)
git switch -c feature/login
# 예전 방식(동일 동작): git checkout -b feature/login
# 지금 어떤 브랜치들이 있고 어디에 있는지 확인 (* 가 현재 위치)
git branch
# ... 이 브랜치에서 파일 수정 후 평소처럼 커밋 ...
git add .
git commit -m "로그인 기능 추가"
# 원래의 main 브랜치로 돌아가기
git switch main병합(merge): 작업 결과를 main에 합치기
브랜치에서 기능을 완성했다면, 이제 그 결과를 main에 합칠 차례입니다. 이것을 병합(merge)이라고 합니다. 중요한 순서가 있습니다. 먼저 '합쳐서 받을 쪽'인 main으로 이동한 뒤, '합쳐올 브랜치'를 지정해 merge합니다. '평행세계의 성과를 원본 세계로 가져온다'고 생각하면 방향이 헷갈리지 않습니다.
브랜치를 main에 병합하기
# 1. 받는 쪽인 main으로 이동
git switch main
# 2. feature/login 브랜치의 작업을 main으로 합치기
git merge feature/login
# 3. 다 합쳤으면 필요 없어진 브랜치 삭제 (선택)
git branch -d feature/login브랜치 이름은 무슨 작업인지 알 수 있게 짓는 것이 좋습니다. feature/login(기능), fix/typo(버그 수정), docs/readme(문서)처럼 '종류/내용' 형태로 지으면, 브랜치 목록만 봐도 각자 무슨 작업 중인지 한눈에 보입니다.
브랜치를 옮기기(switch) 전에는 지금 브랜치의 변경 사항을 커밋해 두는 것이 안전합니다. 커밋하지 않은 수정이 남은 채 이동하려 하면 Git이 경고를 하거나 이동을 막습니다. '작업 마무리(커밋) → 이동'을 습관으로 삼으세요.
브랜치와 병합은 협업의 심장입니다. 하지만 혼자만의 병합으로는 부족합니다. 팀에서는 '내 브랜치를 main에 합쳐도 될까요?'라고 물어보고 검토받는 과정이 있습니다. 그것이 바로 다음 레슨의 풀 리퀘스트입니다.