지난 글
[바이브코딩을 위한 개발 용어] (1) Git, Commit, Push, Pull
이런 경험, 있으신가요?기획서나 제안서를 여러 번 고치다 보면, 어느 순간 파일이 이렇게 쌓여 있죠. 제안서_최종제안서_최종_v2제안서_진짜진짜최종분명 전부 내가 만든 파일인데, 막상 열어
devshelly.com
지난 글을 통해서 Git 덕분에 누가 언제 뭘 바꿨는지 차곡차곡 Commit을 쌓아두니까, 컴퓨터가 고장나도, 다른 사람이 내 작업물을 삭제해 버려도 게임 세이브 포인트 불러오듯 되돌릴 수 있다는 것을 배웠습니다.
그런데 생각해 보면, 되돌리는 건 이미 사고가 난 다음의 대응방인이죠. 더 좋은 건 애초에 서로 안 부딪히게, 각자 자기 자리에서 따로 작업하는 것입니다. 오늘은 그걸 가능하게 해주는 브랜치(branch)에 대해서 알아보려고 합니다!
브랜치(Branch)가 뭔가요?
브랜치(branch)는 말 그대로 나무의 '가지'를 의미하는데요, Git의 브랜치도 똑같아요!
잘 만들어둔 본체(줄기) 는 그대로 둔 채, 본체에서 가지 하나를 틔우듯 갈라져 나와 따로 작업하는 거예요. 여기서 중심이 되는 가장 굵은 줄기, 그러니까 우리 프로젝트의 '원본'에 해당하는 줄기를 main branch(메인 브랜치) 라고 불러요. 모든 가지가 여기서 뻗어 나오기 시작합니다.
중요한 문서를 고칠 때, 원본은 건드리기 무서우니까 '사본'을 하나 떠서 거기서 마음껏 고쳐보잖아요? 브랜치가 딱 그 역할을 해줍니다. 사본을 고친다고 원본이 바뀌지 않는 것처럼, 내가 가지에서 아무리 작업하고 저장해도 본체(main)는 그대로 있어요.
왜 브랜치(Branch)가 필요한가요?
첫 번째 이유. 본체(main)에서 바로 작업하면 멀쩡하던 부분도 망가질 수 있어요.
본체에는 항상 오류없이 잘 돌아가는 코드가 저장되어 있어야 해요. 그런데 아직 완성도 안 된 새 기능을 여기에 곧장 추가해 버리면? 멀쩡히 동작하던 부분도 무너질 수 있겠죠. 😱 그러면 최악의 상황에는 지금까지 작업했던 내용을 모두 지우고, 과거에 멀쩡했던 Commit으로 돌아가야하는 상황도 생깁니다.
두 번째 이유. 다 같이 한 곳에서 수정하면 서로 부딪혀요.
이건 1편에서 보았던 바로 그 문제입니다. 같은 파일을 다같이 수정하면 수정 내용이 부딪히고 사라지기도 해요. 그런데 각자 자기 가지로 갈라져서 작업을 하기 때문에 서로의 작업을 건드릴 일이 없어요. 내 작업이 남의 작업 때문에 날아갈 걱정도 당연히 없죠!
정리해 보자면, 브랜치를 쓰는 주요 이유는 딱 하나예요.
"별도의 가지(branch)에서는 마음껏 수정해도 본체가 안전하다."
새 기능을 실험하다 코드가 꼬여버려도 본체는 끄떡없으니까요. 그러니 코드를 처음 손댈 때 "괜히 건드렸다가 다 망가뜨리면 어쩌지…" 하고 망설여진다면, 방법은 간단해요. 브랜치를 새로 하나 따서, 거기서 작업하면 됩니다. 잘되면 본체에 합치고, 영 아니다 싶으면 그 가지만 버리면 그만이거든요. 브랜치는 원래 그렇게 겁 없이 갈라져 나가 마음껏 시도해보라고 있는 거예요. 😎
🗣️ "피처 브랜치 따서 작업하고 있어요"
'피처(feature)'는 '기능'이라는 뜻이에요. 새 기능 하나를 만들 때 그 기능을 개발하는 전용으로 branch를 하나 새로 만들어서, 거기서 따로 작업하라는 말이에요. 이렇게 기능 하나를 위해 따로 뻗은 갈래를 피처 브랜치(feature branch) 라고 불러요.
갈라진 가지를 다시 병합(Merge)하기
브랜치를 새로 따서 작업을 완료했다고 가정해봅시다. 내 브랜치에서 한 작업은, 그대로 두면 '나만 가진 사본' 안에 머물러 있는 거나 마찬가지입니다. 메인 브랜치가 정식 버전이고 이 기준으로 서비스가 제공되고 있어요. 그래서 동료들도 메인 브랜치에서 새 가지를 떠서 이어 작업하죠. 그렇기 때문에 내가 가지에서 아무리 멋진 기능을 만들어도, 본체(main)에 합치기 전까지는 그 기능은 정식 서비스로 제공지 않은 셈이에요. 😅
그래서 열심히 작업한 기능을 실제로 서비스하기 위해선 별도의 브랜치에서 진행한 작업은 결국 메인 브랜치로 합쳐야해요. 그 "다시 합치는" 일이 바로 병합(merge, 머지)한다고 합니다. 합치는 건 대부분 Git이 알아서 척척 해줘요!👍🏻 이때 Git은 양쪽 파일을 통째로 덮어쓰는 게 아니라, 나의 브랜치에서 바뀐 부분만 찾아서 메인 브랜치에 적절하게 넣어줍니다!
🗣️ "그 기능 main에 머지했어요"
내가 따로 가지에서 만들던 작업이 다 끝나서, 작업 내용을 메인 브랜치에 합쳐 넣었다는 뜻이에요. 이제 그 기능이 본체의 일부가 된 거죠.
동일한 부분을 수정하면 충돌(Conflict)이 발생해요
앞에서 병합을 이야기할 때, "합치는 건 대부분 Git이 알아서 해준다"고 했죠. 그런데 '대부분'이라는 건, 가끔은 Git이 알아서 합칠 수 없는 상황이 있다는 뜻이기도 해요. 😅 가끔 Git이 알아서 합칠 수 없는 상황은 바로 두 사람이 같은 곳(같은 줄)을 서로 다르게 고쳐 놨을 때예요. 실제로 어떻게 벌어지는지, 한 장면을 같이 따라가 볼게요.
1. 두 명의 개발자가 같은 줄을 서로 다르게 고친다.
영희가 feat-a 브랜치에서 "안녕하세요."를 "안녕하세요?" 로 바꿔놨어요. 그런데 철수가 feat-b 브랜치에서 똑같은 그 "안녕하세요."를 "안녕하세요!" 로 바꿨다고 가정합시다. 각자 자기 가지에서 따로 작업했으니, 서로 동일한 라인을 수정했는지 몰랐겠죠. 먼저 작업을 끝낸 영희가 자신의 feat-a 브랜치를 main에 병합해요. Git은 영희의 "안녕하세요."를 "안녕하세요?"로 변경하는 작업을 문제없이 합치게됩니다. 이때는 아무 문제 없어요.
2. 합치려고 할 때 충돌이 발생한다.
문제는 그 다음이에요. 뒤이어 작업을 끝낸 철수가 feat-b 브랜치를 main에 합치려는 순간, Git은 어리둥절해져요. main의 그 줄은 이미 영희가 "안녕하세요?"로 바꿔놨는데, 철수는 똑같은 줄을 "안녕하세요!"로 바꿨거든요. Git은 "같은 자리인데… 둘 중에 뭘 살려야 하지…?"하고 답을 못 내요. 이 상태를 충돌(conflict)이 발생했다고 합니다.
3. 사람이 직접 충돌을 해결한다.
Git이 정하지 못하니까 충돌을 마주한 철수가 직접 골라줘야 합니다. "영희가 쓴 '안녕하세요?'로 가자", "아니 내가 쓴 '안녕하세요!'로 가자", 아니면 "둘을 적절히 섞어서 새로 쓰자" 하고요. 꼭 둘 중 하나만 버리는 게 아니에요. 오히려 양쪽을 적절히 합쳐서 새로 쓰는 경우가 제일 흔해요. 이렇게 부딪힌 부분을 사람이 정리하는 걸 충돌 해결(resolve) 이라고 해요.
4. 최종본으로 커밋하여 병합을 완료한다.
충돌을 해결하여 최종본으로 커밋을 한번 더 해요. 그러면 비로소 병합이 마무리됩니다!
충돌은 에러도 아니고, 누가 잘못한 것도 아니에요. Git이 "이건 제가 함부로 못 정하겠어요, 사람이 판단해 주세요" 하고 물어보는 것이죠. 그러니 충돌이 발생하면 침착하게 어떤 코드가 의도된 것인지 선택하면 됩니다! 혼자서 결정하기 어렵다면, 동일한 부분을 수정한 개발자와 함께 논의하여 충돌을 해결하기도 합니다.
오늘 나온 용어, 한눈에 복습 📒
- 브랜치(branch) — 본체(main)에서 갈라져 나와, 본체를 건드리지 않고 따로 작업하는 별도의 '갈래'.
- main(메인) / master(마스터) — 중심이 되는 본체 줄기. 모든 갈래가 여기서 뻗어 나와요.
(예전엔 master branch라고 불렀는데, 요즘은 보통 main branch이라고 불러요.) - 병합(merge, 머지) — 갈라졌던 가지를 본체(main)에 다시 합치는 일. 대부분 Git이 알아서 해줘요.
- 충돌(conflict, 컨플릭) — 두 사람이 같은 곳을 다르게 고쳐서, Git이 못 합치고 멈춘 상태. 사람이 직접 골라서 해결(resolve)하고, 다시 저장하면 풀려요.
다음 글에서는...
코드를 main 브랜치에 병합하기 전에 동료 개발자들에게 변경 사항을 공유하고 리뷰를 받을 수 있는 PR(Pull Request) 에 대해 알아봅시다! 그리고 지금까지 개념으로 익힌 내용을 직접 실행해보며 내 것으로 만들어볼 거예요.
GitHub에 있는 코드를 내 컴퓨터로 내려받고 → 브랜치를 만들고 → 코드를 수정하고 → 커밋하고 → 다시 GitHub에 올리고 → PR을 생성한 뒤 → main 브랜치에 병합하는 전체 과정을 실제 화면을 보며 차근차근 따라 해봅시다! 🚀