깃허브 브랜치 전략 —
여러 갈래로 나눠 짓고,
안전하게 합치는 법

솔직히 고백하자면, 저는 코딩을 늦게 시작한 사람입니다. 마흔이 넘어서 처음 Git이라는 걸 만졌어요. 그때 제일 무서웠던 단어가 두 개 있었는데, 하나는 "merge(머지)"였고 다른 하나는 "브랜치(branch)"였습니다. 어디서 주워듣기로는 "브랜치를 잘못 만지면 그동안 짠 코드가 다 날아간다"는 소문이 있었거든요. 그래서 한동안 저는 브랜치라는 걸 아예 쓰지 않고, 그냥 하나의 파일 뭉치에 계속 덮어쓰기만 했습니다.

결과가 어땠는지 아세요? 어느 날 새 기능을 만들다가 잘 돌아가던 부분까지 망가뜨렸는데, 되돌릴 방법이 없었습니다. "그저께 저녁까지는 분명히 잘 됐는데…" 하면서 밤을 꼬박 새웠죠. 그때 누가 옆에서 딱 한마디만 해줬어도 좋았을 겁니다. "부장님, 그거 브랜치 하나 파고 거기서 하시면 되는데요." 이 글은 그 한마디를, 예전의 저 같은 분께 드리는 글입니다.

Git과 GitHub의 정체를 한 문장으로 요약하면 이렇습니다. 무한 되돌리기 기능이 붙은 협업 도구. 그리고 이 "무한 되돌리기 + 여럿이 안 부딪히고 일하기"의 핵심에 바로 브랜치가 있습니다. 브랜치를 이해하면 Git의 절반은 이해한 겁니다. 오늘은 이 브랜치라는 녀석을, 코드 한 줄 모르는 분도 편하게 알아들으실 수 있게 풀어보겠습니다. 이 글은 DevOps 입문 시리즈의 한 편이기도 합니다.

브랜치는 원고의 '사본 원고지'입니다. 정식으로 손님에게 내놓을 원고(main)는 그대로 두고, 옆에 똑같이 베낀 원고지 한 장을 새로 꺼내 거기서 마음껏 고쳐 씁니다. 마음에 들면 그 내용을 정식 원고에 옮겨 적고, 마음에 안 들면 그냥 사본을 구겨 버리면 됩니다. 정식 원고는 손끝 하나 다치지 않죠.

브랜치가 뭔가요 — 코드의 '평행세계'

브랜치를 한마디로 하면 코드의 평행세계입니다. 영화에서 주인공이 다른 선택을 한 또 하나의 세계가 갈라져 나오는 장면, 보신 적 있으시죠? 브랜치가 딱 그겁니다. 지금 있는 세계(코드)에서 가지를 하나 쳐서, 그 안에서는 무슨 짓을 해도 원래 세계에 영향을 주지 않아요. 실험을 실컷 하다가, 결과가 좋으면 원래 세계로 가져와 합치고, 나쁘면 그 평행세계를 통째로 버리면 그만입니다.

이름이 왜 "브랜치(가지)"일까요? 나무를 떠올려 보세요. 굵은 원줄기(main)가 있고, 거기서 가지들이 뻗어 나옵니다. 각 가지에서 잎도 나고 열매도 맺히죠. 코드도 똑같습니다. 굵은 줄기 하나에서 여러 갈래로 가지를 쳐서 각자 다른 작업을 하고, 잘 여문 가지는 다시 줄기에 붙이는(합치는) 겁니다.

조금 더 실감 나는 예를 들어볼게요. 여러분이 잘 돌아가는 앱을 하나 운영하고 있다고 칩시다. 손님들이 지금 이 순간에도 그 앱을 쓰고 있어요. 그런데 새 기능을 하나 넣고 싶습니다. 만약 지금 이 앱의 코드(main)에 곧장 손을 대기 시작하면 어떻게 될까요? 새 기능이 반쯤 만들어진 어정쩡한 상태에서 손님이 앱을 열면, 그 미완성 코드를 그대로 만나게 됩니다. 최악의 경우 앱이 멈추죠. 하지만 브랜치를 하나 파서 거기서 만들면, 손님이 쓰는 정식 코드는 멀쩡히 돌아가는 채로 두고, 나는 옆 평행세계에서 느긋하게 새 기능을 완성할 수 있습니다. 다 되고 검증까지 마친 뒤에야 정식 코드에 합치는 거죠. 이게 브랜치의 힘입니다.

여기서 딱 세 단어만 기억하시면 됩니다. 커밋(commit), 브랜치(branch), 머지(merge). 이 셋의 관계를 원고지 비유로 풀어볼게요.

정리하면 이렇습니다. main이라는 정식 원고가 있고, 여기서 사본 원고지(브랜치)를 한 장 꺼냅니다. 그 사본에 뭔가 쓰고 "여기까지 완성" 도장(커밋)을 몇 번 찍습니다. 다 됐으면 그 내용을 정식 원고에 옮겨 적습니다(머지). 이게 전부예요. 정말 이게 전부입니다.

왜 브랜치가 필요한가 — 다 같이 정식 원고에 낙서하면 생기는 일

브랜치가 없다고 상상해 봅시다. 팀원 세 명이 하나의 main에 각자 바로바로 코드를 씁니다. A는 로그인 기능을 고치고, B는 결제 화면을 손보고, C는 디자인을 바꿉니다. 그런데 이 셋이 하필 같은 파일의 비슷한 부분을 건드리면? 서로의 작업을 덮어써 버립니다. A가 저장한 걸 B가 모르고 지워버리고, C가 또 그 위에 덮어쓰죠. 그러다 어디선가 버그가 터지면, 누가 무엇을 왜 바꿨는지 아무도 모릅니다. 아수라장이에요.

브랜치는 이 문제를 아주 우아하게 풉니다. A는 A대로 사본 원고지 하나를 꺼내 거기서만 로그인을 고칩니다. B도, C도 각자 자기 사본에서만 작업하죠. 서로의 작업 공간이 완전히 분리되어 있으니 부딪힐 일이 없습니다. 각자 다 끝낸 뒤에, 하나씩 순서대로 정식 원고(main)에 합치면 됩니다. 이때 겹치는 부분이 있으면 "충돌"이 나는데, 이건 뒤에서 다시 다루겠습니다. 겁먹지 마세요. 생각보다 별거 아닙니다.

그리고 브랜치의 진짜 매력은 '실험의 자유'에 있습니다. 개발을 하다 보면 "이렇게 하면 더 빨라질까?", "이 방식으로 갈아엎어 볼까?" 싶은 무모한 아이디어가 떠오를 때가 있어요. main에 바로 손대면 이런 실험은 도박입니다. 실패하면 잘 돌던 코드까지 망치니까요. 하지만 브랜치를 하나 파서 거기서 실험하면, 성공하면 합치고 실패하면 통째로 버리면 그만입니다. 잃을 게 없으니 마음껏 시도할 수 있죠. 저는 이 '안전한 실험실'을 얻고 나서야 비로소 코딩이 조금 즐거워졌습니다. 겁내지 않고 이것저것 해볼 수 있게 됐거든요.

여기서 많은 분이 이렇게 물어보십니다. "저는 혼자 개발하는데요? 부딪힐 사람도 없는데 브랜치가 필요한가요?" 네, 필요합니다. 아니, 저는 혼자일수록 더 권합니다. 이유는 이렇습니다.

세 사람의 하루 — 브랜치가 있을 때와 없을 때

추상적인 설명보다 짧은 이야기 하나가 기억에 남죠. 작은 스타트업의 개발자 A, B, C의 어느 하루를 두 가지 버전으로 그려보겠습니다.

브랜치가 없는 세계. 셋은 하나의 코드 뭉치(main)를 공유합니다. 아침에 A가 로그인 화면을 고치고 저장합니다. 비슷한 시간 B는 결제 로직을 손봅니다. 그런데 둘이 같은 설정 파일을 건드렸어요. B가 저장하는 순간 A의 아침 작업이 소리 없이 사라집니다. 오후에 C가 디자인을 바꾸다 앱이 멈추는데, 원인을 찾으려 해도 "누가 언제 뭘 바꿨는지" 기록이 뒤엉켜 있어 도무지 알 수가 없습니다. 결국 셋이 야근하며 서로 "네가 뭐 건드린 거 아냐?" 하고 눈치를 봅니다. 제가 옛날에 혼자서 겪던 아수라장을, 이번엔 셋이 함께 겪는 셈이죠.

브랜치가 있는 세계. 아침에 셋은 각자 자기 사본 원고지부터 꺼냅니다. A는 feature/login, B는 feature/payment, C는 feature/redesign. 각자 자기 가지에서만 일하니 서로의 작업이 절대 섞이지 않습니다. 점심 무렵 A가 먼저 끝내 PR을 열고, 동료 리뷰와 자동 검사를 거쳐 main에 합칩니다. B는 합쳐진 최신 main을 자기 가지로 당겨와 반영한 뒤 마저 작업합니다. C도 마찬가지. 혹시 겹치는 부분이 있으면 그때 "충돌"로 조용히 표시되고, 해당 부분을 만든 사람끼리 상의해 정리합니다. 저녁이 되면 셋 다 정시 퇴근합니다. 무엇이 언제 왜 바뀌었는지가 커밋과 PR에 또박또박 남아 있으니까요.

같은 세 사람, 같은 작업량인데 하루의 질이 이렇게 다릅니다. 브랜치는 실력이 아니라 습관의 문제라는 걸 이 이야기가 잘 보여줍니다. 어렵지 않아요. 그저 "일 시작할 땐 가지부터 판다"는 한 가지 습관이면 됩니다.

전체 흐름 한눈에 — 가지를 치고 합치기까지

실제로 브랜치를 쓰는 하루의 흐름은 이렇게 흘러갑니다. 복잡해 보여도 하나씩 보면 전부 상식선입니다.

이 흐름을 말로 풀면 이렇습니다. 정식 원고(main)에서 사본(feature/login 같은 브랜치)을 하나 꺼내고, 거기서 작업하며 중간중간 도장을 찍습니다(커밋). 다 됐으면 "이 사본을 정식 원고에 합쳐도 될까요?" 하고 정식으로 요청을 겁니다. 이 요청이 바로 PR(Pull Request)입니다. 동료가 그 내용을 살펴보고(리뷰) 괜찮다고 하면, 정식 원고에 합칩니다(merge). 다 쓴 사본 원고지는 깔끔하게 버립니다(브랜치 삭제).

이 그림에서 PR과 리뷰 단계는 그 자체로 하나의 큰 주제라, 따로 PR·코드리뷰 이야기에서 자세히 다룹니다. 오늘 글에서는 "브랜치를 어떻게 나누고 합칠 것인가", 즉 브랜치 전략에 집중하겠습니다.

한 가지 오해를 미리 풀고 갈게요. 이 흐름이 일곱 단계나 되니 "매번 이걸 다 해야 해?" 싶으시죠. 실제로 해보면 대부분 클릭 몇 번, 명령어 두세 줄이면 끝납니다. 브랜치를 만드는 데 3초, 커밋에 5초, PR 여는 데 30초예요. 처음 몇 번만 낯설지, 자전거 타기처럼 곧 몸이 먼저 움직입니다. 저도 지금은 이 흐름을 의식조차 안 하고 자동으로 밟습니다. 그러니 "절차가 많다"는 인상 때문에 지레 물러서지 마세요.

처음으로 브랜치 하나 만들어보기 — 실전 따라하기

백 번 읽는 것보다 한 번 해보는 게 낫습니다. 아주 사소한 수정(예: 오타 하나 고치기)을 GitHub Flow 방식으로 처리하는 과정을 순서대로 밟아볼게요. 지금 당장 안 따라 하셔도 됩니다. "아, 이런 리듬이구나"만 눈에 담아두세요.

보셨죠? 무섭게 들리던 push, PR, merge가 사실은 "올리고 → 요청하고 → 합치고 → 치운다"는 네 마디로 끝납니다. 이 리듬을 서너 번만 반복하면, 어느새 몸에 배어 있을 겁니다.

대표 브랜치 전략 세 가지 — 우리 팀엔 뭐가 맞을까

"브랜치 전략"이라는 말이 거창하게 들리지만, 사실은 "가지를 언제, 어떻게 치고 언제 합칠지에 대한 팀의 약속"일 뿐입니다. 정답은 없습니다. 다만 오랜 시간 여러 팀이 다듬어온 대표적인 세 가지 방식이 있습니다. 먼저 표로 한눈에 비교해 보시죠.

1) Git Flow — 무겁지만 체계적인 정통파

Git Flow는 가지 종류를 역할별로 아주 촘촘하게 나눕니다. 마치 큰 출판사에서 원고 하나를 두고도 '집필용', '편집용', '교정용', '인쇄 직전용', '긴급 수정용' 원고지를 따로 관리하는 것과 비슷해요. 구체적으로는 이렇습니다.

• main — 실제로 손님에게 나가는(배포되는) 정식 원고.
• develop — 다음 버전을 준비하는 '개발 통합' 원고. 완성된 기능들이 여기 모입니다.
• feature — 기능 하나하나를 만드는 사본. develop에서 갈라져 나와 develop으로 돌아갑니다.
• release — 이번에 내보낼 버전을 마지막으로 다듬는 원고. 여기서 마무리해 main으로.
• hotfix — 이미 나간 버전에 급한 불이 났을 때, main에서 바로 갈라져 급히 고치는 사본.

장점은 명확합니다. 역할이 딱딱 나뉘어 있어 큰 규모의, 버전이 뚜렷한 제품을 관리하기에 아주 체계적입니다. 단점도 명확합니다. 규칙이 많아서 무겁습니다. "이건 어느 브랜치에서 갈라야 하지?"를 매번 고민해야 하고, 초보자에게는 진입 장벽이 꽤 높습니다. 웹 서비스처럼 하루에도 여러 번 배포하는 요즘 흐름과는 잘 안 맞는 면도 있어요.

2) GitHub Flow — 단순함이 무기

GitHub Flow는 이름 그대로 GitHub이 권하는 단순한 방식입니다. 브랜치 종류가 사실상 두 개뿐이에요. 항상 배포 가능한 main 하나, 그리고 거기서 갈라져 나온 짧은 수명의 feature 브랜치들. 규칙을 요약하면 이렇습니다.

핵심은 "main은 언제나 배포 가능한 상태로 지킨다"는 원칙과, 브랜치의 수명을 짧게 가져간다는 점입니다. 하나의 기능이 며칠 안에 만들어져 합쳐지고 사라집니다. 규칙이 적으니 배우기 쉽고, CI/CD(자동 검사·자동 배포)와 궁합이 아주 좋습니다. 그래서 초보자와 소규모 팀에게는 이 GitHub Flow를 저는 권해드립니다. 물론 정답이라는 뜻은 아니고, 처음 발을 들이기에 부담이 가장 적다는 뜻이에요.

3) Trunk-Based — 아주 짧게, 아주 자주

Trunk-Based는 "가지를 최대한 짧게 가져가고, 하루에도 여러 번 자주 합치자"는 방식입니다. trunk는 '나무 원줄기'라는 뜻이니, 곧 main을 중심에 두고 모두가 그 근처에서 아주 짧은 가지만 잠깐씩 쓰는 그림이죠. 심지어 몇 시간 만에 브랜치를 합쳐버리기도 합니다.

왜 이렇게 할까요? 가지를 오래 방치할수록 원줄기와 멀어져서 나중에 합칠 때 충돌이 커지기 때문입니다. 자주 합치면 매번 작은 조각만 합치니 충돌이 작습니다. 대신 이게 가능하려면 자동 테스트와 CI/CD가 아주 탄탄해야 합니다. 짧은 주기로 계속 합치면서도 main이 안 깨지려면, 기계가 매번 자동으로 검사해줘야 하니까요. 그래서 이 전략은 자동화가 고도로 갖춰진 숙련된 팀에게 어울립니다.

세 전략을 원고지 비유로 한 번 더 묶어볼게요. Git Flow는 '집필용·편집용·교정용 원고지를 철저히 나눠 쓰는 대형 출판사', GitHub Flow는 '정식 원고 하나 두고 그때그때 사본 한 장 꺼내 고쳐 붙이는 작가', Trunk-Based는 '정식 원고 옆에서 한두 줄씩 아주 자주 옮겨 적는, 손발 척척 맞는 편집팀'입니다. 규모와 속도, 그리고 자동화 수준에 따라 어울리는 옷이 다른 셈이죠.

브랜치 이름 짓기 — 서랍에 라벨을 붙이자

브랜치가 열 개, 스무 개로 늘어나면 이름이 곧 생명입니다. test, test2, new, final, final-real 이렇게 짓기 시작하면(제 흑역사입니다) 일주일 뒤엔 자기가 만든 브랜치가 뭐였는지도 모릅니다. 그래서 팀마다 이름 규칙을 정해둡니다. 가장 널리 쓰이는 관습은 "종류/설명" 형태예요.

이름 지을 때 지키면 좋은 소소한 습관 몇 가지를 정리해 드릴게요.

충돌(merge conflict)이 뭔가요 — 겁먹지 않아도 됩니다

브랜치 이야기를 하면 꼭 나오는 무서운 단어, 바로 "충돌(merge conflict)"입니다. 이름만 들으면 뭔가 코드가 폭발할 것 같지만, 실체는 아주 단순합니다. 두 사람이 같은 파일의 같은 부분을 서로 다르게 고쳤을 때, Git이 "둘 중 뭘 남길지 나는 못 정하겠어요. 사람이 골라주세요" 하고 손을 드는 것뿐입니다.

원고지 비유로 볼까요. A와 B가 각자 사본 원고지에서 작업했는데, 하필 둘 다 3페이지 둘째 줄을 고쳤습니다. A는 "안녕하세요"로, B는 "반갑습니다"로 바꿨어요. 이 둘을 정식 원고에 합치려니, 그 줄에 뭘 적어야 할지 기계는 판단할 수 없습니다. 그래서 그 부분을 이렇게 표시해두고 사람에게 물어봅니다.

<<<<<<< 내 작업
안녕하세요
=======
반갑습니다
>>>>>>> 상대 작업

이 표시가 뜨면, 우리가 할 일은 딱 하나입니다. 둘 중 무엇을 남길지(혹은 둘을 합쳐 새로 쓸지) 정하고, 저 이상한 기호 줄들(<<<, ===, >>>)을 지운 뒤 저장하면 끝입니다. 정말 이게 전부예요. 처음엔 저 기호가 무섭지만, 몇 번 해보면 "아, 그냥 골라주면 되는구나" 하게 됩니다.

충돌을 애초에 작게 만드는 요령도 있습니다. 첫째, 브랜치를 짧게 가져가세요. 사본을 오래 붙잡고 있을수록 그동안 정식 원고가 많이 바뀌어, 나중에 합칠 때 겹치는 부분이 늘어납니다. 둘째, 작업을 시작하기 전과 합치기 직전에 main의 최신 내용을 내 브랜치로 가져오세요. 최신 상태를 자주 반영할수록 어긋남이 작아집니다. 셋째, 한 파일을 여러 사람이 동시에 크게 뜯어고치지 않도록 작업을 나눠 맡으면, 애초에 충돌할 일 자체가 줄어듭니다.

내 브랜치를 최신으로 유지하기 — 사본이 낡지 않게

브랜치를 만들어 며칠 작업하는 동안, 정식 원고(main)는 가만히 있지 않습니다. 다른 동료들이 자기 작업을 계속 합치니 main은 자꾸 앞으로 나아가죠. 그러면 내가 쥔 사본 원고지는 점점 '옛날 판본'을 베낀 것이 되어갑니다. 이 상태로 나중에 합치려 하면, 그동안 벌어진 차이만큼 충돌이 커집니다.

그래서 좋은 습관이 하나 있습니다. 작업 중간중간 main의 최신 내용을 내 브랜치로 가져오는 것입니다. 사본을 최신 정식 원고에 맞춰 계속 갱신해주는 셈이죠. 이렇게 하면 나중에 합칠 때 놀랄 일이 확 줄어듭니다. 큰 충돌을 한 번에 만나 당황하는 대신, 작은 차이를 그때그때 소화하는 겁니다.

이 '가져오기'를 하는 방식에는 크게 두 가지가 있습니다. 개념만 짚고 갈게요. 지금 자세히 몰라도 전혀 문제없습니다.

입문 단계라면 굳이 rebase까지 손댈 필요 없습니다. "main을 내 브랜치로 종종 merge해서 최신으로 유지한다" 정도만 몸에 익혀도 충분합니다. rebase는 나중에 히스토리를 더 깔끔하게 관리하고 싶어질 때 천천히 배우면 됩니다. 급하지 않아요.

main 보호(branch protection) — 정식 원고에 함부로 못 쓰게

협업이 시작되면 꼭 챙겨야 할 게 있습니다. 바로 main 보호(branch protection)입니다. 정식 원고인 main에 누가 실수로, 혹은 검토 없이 바로 낙서하는 걸 막는 잠금장치예요. GitHub 저장소 설정에서 규칙 몇 개만 켜면 됩니다. 대표적으로 이런 것들이 있어요.

• main에 직접 push 금지 — 반드시 브랜치를 만들고 PR을 통해서만 합칠 수 있게 합니다.
• PR 리뷰 승인 필수 — 최소 한 명 이상의 동료가 "좋아요" 해야 합칠 수 있습니다.
• 자동 검사(CI) 통과 필수 — 테스트가 다 통과해야만 합치기 버튼이 켜집니다.
• 최신 상태 유지 요구 — main의 최신 내용을 반영한 뒤에만 합치도록.

이렇게 해두면, 아무리 급해도 누구도 검증 안 된 코드를 정식 원고에 밀어 넣을 수 없습니다. 사람이 늘 조심하는 것보다, 시스템이 자동으로 막아주는 게 훨씬 안전하죠. 이 규칙들은 PR·코드리뷰, 그리고 CI/CD 파이프라인과 톱니바퀴처럼 맞물려 돌아갑니다. 브랜치 전략은 이 셋을 함께 볼 때 비로소 완성됩니다.

여기서 한 가지 관점을 드리고 싶습니다. 많은 입문자가 규칙을 '나를 귀찮게 하는 방해물'로 느낍니다. 저도 처음엔 "그냥 push 한 번 하면 될 걸 왜 PR을 만들고 검사를 기다려야 해?" 하고 투덜댔어요. 그런데 몇 번 사고를 치고 나니 생각이 바뀌더군요. 이 규칙들은 나를 막는 게 아니라 나를 지켜주는 난간이었습니다. 야간 운전할 때 갓길의 가드레일이 답답해 보여도, 결정적인 순간에 목숨을 구하는 것과 같아요. main 보호는 '실수할 수 있는 사람'을 위한 배려입니다. 그리고 우리 모두는 실수할 수 있는 사람이죠.

실제로 규칙을 켜는 건 어렵지 않습니다. GitHub 저장소의 Settings에서 Branches 항목을 찾아 보호 규칙을 추가하고, 위에서 본 항목들(직접 push 금지, 리뷰 승인 필수, 검사 통과 필수 등)을 체크하면 됩니다. 화면 구성은 시기에 따라 조금씩 바뀌니 세세한 위치는 공식 문서를 함께 보시는 걸 권합니다. 중요한 건 위치가 아니라 "정식 원고는 검증을 거쳐야만 바뀐다"는 원칙 자체예요.

초보가 흔히 하는 실수 & 해결

제가 직접 겪었거나, 옆에서 숱하게 본 실수들을 모았습니다. 미리 알아두면 밤샘을 몇 번은 아끼실 겁니다.

자주 묻는 질문(FAQ)

Q. 브랜치를 삭제하면 그동안 짠 코드가 사라지나요?
A. 아니요. main에 이미 merge(합치기)했다면, 그 내용은 main에 안전하게 들어가 있습니다. 브랜치 삭제는 다 옮겨 적은 사본 원고지를 버리는 것일 뿐, 정식 원고의 내용은 그대로예요. 합치기 전에 지우는 것만 조심하시면 됩니다.

Q. 혼자 개발하는데 굳이 전략까지 정해야 하나요?
A. 거창한 전략 문서는 필요 없습니다. 다만 "작업할 땐 브랜치를 판다, main은 항상 잘 돌아가는 상태로 둔다" 이 두 가지 습관만 지켜도 사실상 GitHub Flow를 쓰고 있는 겁니다. 그거면 충분합니다.

Q. 충돌이 났는데 뭘 골라야 할지 모르겠어요. 어떡하죠?
A. 충돌 표시 부분에서 '내 작업'과 '상대 작업'이 각각 무엇인지 천천히 읽어보세요. 둘 다 필요하면 둘을 합쳐 쓰면 되고, 판단이 안 서면 그 부분을 작성한 동료에게 물어보는 게 가장 빠르고 안전합니다. 확신 없이 아무거나 지우지 마세요.

Q. Git Flow, GitHub Flow, Trunk-Based 중 뭘 배워야 하나요?
A. 입문 단계라면 GitHub Flow 하나만 제대로 익히세요. 가장 단순하고, 나머지 둘도 결국 이 기본 위에 규칙을 더하거나 빼는 것이라, 이걸 알면 나머지는 금방 이해됩니다.

Q. PR과 merge는 뭐가 다른가요?
A. PR은 "이 브랜치를 합쳐도 될까요?"라고 정식으로 요청하고 검토받는 '절차'이고, merge는 실제로 합치는 '행위'입니다. 보통 PR로 검토를 거친 뒤 merge 버튼을 눌러 합칩니다. 자세한 건 PR·코드리뷰 글에서 이어집니다.

마무리 체크리스트

오늘 내용을 딱 한 문장으로 줄이면 이렇습니다. "정식 원고(main)는 지키고, 사본 원고지(브랜치)에서 일하고, 검토를 거쳐 합치자." 이 습관 하나가 여러분의 코드를, 그리고 밤잠을 지켜줄 겁니다. 아래 항목을 하나씩 챙겨보세요.

• ✅ 새 작업은 항상 브랜치부터 만들고 시작한다.
• ✅ main은 언제나 잘 돌아가는 상태로 지킨다.
• ✅ 브랜치 이름은 접두어 규칙(feature/, fix/ 등)을 따른다.
• ✅ 브랜치는 작게, 짧게 가져가고 자주 합친다.
• ✅ 합치기 전엔 PR로 검토를 거친다.
• ✅ merge한 브랜치는 바로 삭제한다.
• ✅ 협업한다면 main 보호를 켜둔다.
• ✅ 충돌이 나도 당황하지 않는다. 골라주면 끝이다.

처음엔 브랜치라는 단어만 봐도 손이 굳었던 저도, 지금은 브랜치 없이는 코드를 못 짭니다. 그만큼 한번 몸에 익으면 이만큼 든든한 게 없어요. 겁먹지 마세요. 오늘 브랜치 하나 만들어 사소한 걸 고쳐보는 것, 딱 그 한 걸음이면 충분합니다. 저도 그렇게 시작했습니다.

다음 글에서는 오늘 계속 등장했던 PR(Pull Request)과 코드리뷰 이야기를 다룹니다. "합쳐도 될까요?"를 어떻게 정중하고 안전하게 주고받는지, 리뷰는 어떻게 남기고 받는지를 역시 비유로 풀어드릴게요. PR·코드리뷰 편에서 뵙겠습니다. 더불어 브랜치와 함께 돌아가는 자동화가 궁금하시면 GitHub Actions 편과 CI/CD 편도 좋은 다음 걸음이 될 겁니다.

(2026년 8월 기준 작성 — 화면·정책은 바뀔 수 있으니 공식 문서를 함께 확인하세요.)

← 기술 블로그 목록으로