A-6: 브랜치 전략과 오픈소스 기여

또 만났네요, 홍순구 튜터입니다. 지난 시간 우리는 기능 브랜치를 따서 Pull Request 를 올리고, 동료의 리뷰를 받아 main 에 합치고, 다 쓴 브랜치를 깔끔히 지우는 협업 한 바퀴를 통째로 돌려봤어요. 브랜치 → 커밋 → push → PR → 리뷰 → 병합 → 정리. 이 리듬이 이제 좀 익숙해졌죠?

그런데 제가 그 끝에서 슬쩍 흘린 말이 있어요. "우리가 돌린 이 한 바퀴엔 사실 이름이 있다" 고요. 오늘 그 이름을 드디어 알려드릴게요. 우리가 한 그 방식의 이름은 GitHub Flow 예요. 그리고 팀이 git 으로 협업하는 약속엔 GitHub Flow 말고도 몇 가지가 더 있어요. 어떤 팀은 더 빠르게, 어떤 팀은 더 엄격하게 일하거든요.

오늘은 그 협업의 약속들 — 브랜치 전략 — 을 정리하고, 거기서 한 걸음 더 나아가요. 지금까지는 전부 내 저장소에서만 PR 을 올렸는데, 세상엔 내가 권한 없는 남의 공개 저장소(오픈소스) 가 가득해요. 거기에 내 코드를 보태려면 어떻게 할까요? 그때 등장하는 게 fork(포크)와 upstream(업스트림) 이에요. A-4 에서 잠깐 예고했던 그 두 번째 원격을 오늘 드디어 만나요.

처음 듣는 단어가 우르르 나올 거예요. GitHub Flow, 트렁크 기반, Git Flow, fork, 태그, SemVer... 괜찮아요. 현업 신입도 입사 첫 주에 "우리 팀 브랜치 전략이 뭐예요?" 라는 질문에 다들 한 번씩 멍해져요. 오늘 끝나면 그 질문에 또박또박 답할 수 있게 될 거예요. 천천히 하나씩 가봅시다.

   오늘의 여정 — 팀의 협업 약속과 오픈소스 기여

   ① 우리가 한 그 흐름의 이름 — GitHub Flow
   ② 한 발 더 빠르게 — 트렁크 기반 개발
   ③ 버전을 끊어 파는 소프트웨어 — Git Flow
   ④ 우리 팀은 뭘 골라야 할까 — 세 전략 비교
   ⑤ 남의 공개 저장소에 기여하기 — fork와 upstream
   ⑥ 오픈소스 첫 PR 한 바퀴 — fork 흐름 실전
   ⑦ 버전에 이름표 달기 — 태그·릴리스와 SemVer

①②③에서 팀이 협업하는 세 가지 약속을 하나씩 보고, ④에서 셋을 나란히 견줘 "우리 팀은 뭘 쓸까" 를 정리해요. ⑤⑥에서는 내 저장소를 넘어 남의 오픈소스에 기여하는 fork 흐름을 익히고, 마지막 ⑦에서 완성된 버전에 이름표(태그)를 달아 릴리스하는 법까지 배웁니다.

💡 오늘 수업의 핵심 — "팀이 git 으로 협업하는 약속을 브랜치 전략이라 한다. 가장 단순한 GitHub Flow(main + 기능 브랜치 + PR)가 기본이고, 트렁크 기반은 다음 단계, Git Flow 는 특수·레거시다. 남의 오픈소스엔 fork 와 upstream 두 원격으로 기여하고, 완성된 버전엔 SemVer 규칙으로 태그를 달아 릴리스한다."

🎯 학습 목표

• 팀의 협업 약속인 브랜치 전략 세 가지(GitHub Flow·트렁크 기반·Git Flow)를 구분하고, 우리 팀에 맞는 것을 고르는 기준을 세웁니다.
• fork 와 upstream 두 원격을 이해하고, 권한 없는 공개 저장소(오픈소스)에 PR 로 기여하는 한 바퀴를 익힙니다.
• 태그·릴리스로 버전에 이름표를 달고, SemVer 와 Conventional Commits 규칙으로 버전과 커밋을 일관되게 관리합니다.

Step 1: "우리가 한 그 흐름엔 이름이 있다 — GitHub Flow"

먼저 "브랜치 전략" 이라는 말부터 풀어요. 거창해 보이지만 뜻은 단순해요. 팀이 브랜치를 어떻게 따고, 언제 합치고, 무엇을 main 으로 삼을지 미리 정해둔 약속이에요. 축구팀에 포지션 약속이 있는 것처럼, 개발팀엔 브랜치 약속이 있어요.

이 약속이 없으면 어떻게 될까요? 누구는 main 에 바로 밀어 넣고, 누구는 거대한 브랜치를 한 달씩 묵히다가, 합칠 때 서로 엉켜서 사고가 나요. 그래서 팀은 "우리는 이렇게 일하자" 를 미리 정해두는 거예요.

그런데 사실 여러분은 이미 그 약속 하나를 몸으로 해봤어요. 지난 시간에 돌린 그 한 바퀴 — main 은 건드리지 않고, 짧은 기능 브랜치를 따서, PR 로 검토받고 합친 뒤, 브랜치를 지운 그 흐름 — 그게 바로 가장 널리 쓰이는 브랜치 전략, GitHub Flow 예요.

   GitHub Flow — 가장 단순한 협업 약속

   main   ●─────────────●─────────────▶   ← 항상 배포 가능한 상태
           \           /
            ●──●──●───┘
            └ 짧은 기능 브랜치 → PR → 리뷰 → 병합 → 삭제

GitHub Flow 가 지키는 약속은 딱 다섯 가지예요. 하나하나 보면 전부 우리가 지난 시간에 이미 해본 것들이에요.

1. main 은 항상 배포 가능한 상태로 둔다. main 에 있는 코드는 언제 꺼내도 돌아가야 해요. 그래서 검증 안 된 코드를 main 에 바로 넣지 않죠.
2. 새 작업은 main 에서 짧은 기능 브랜치를 따서 한다. 브랜치 이름은 feature/login 처럼 무슨 작업인지 알 수 있게 짓고요.
3. 변경은 PR 로만 합친다. main 에 직접 push 하지 않고, 반드시 PR 을 거쳐요(지난 시간의 보호된 브랜치).
4. PR 에서 리뷰와 대화를 거친다. 동료가 봐주고 승인하면 합쳐요.
5. 합치면 기능 브랜치를 지운다. 역할을 다한 브랜치는 깔끔히 정리해요.

보세요, 전부 지난 시간에 직접 해본 것들이죠? 그래서 GitHub Flow 는 따로 외울 게 없어요. 여러분은 이미 GitHub Flow 를 쓸 줄 알아요. 오늘은 거기에 "이게 GitHub Flow 라는 이름의 전략이었구나" 하는 라벨만 붙이는 거예요.

왜 이게 1순위 기본일까요? 가장 단순해서 사고 칠 여지가 적기 때문이에요. 긴 브랜치도, 복잡한 단계도 없어요. 브랜치 하나 따서, 며칠 안에 PR 로 합치고, 지운다. 이 단순함 덕분에 작은 스타트업부터 큰 회사의 웹 서비스 팀까지 대부분이 GitHub Flow(또는 그 변형)로 일해요. 그래서 신입으로 입사하면 가장 높은 확률로 만나는 게 이 방식이에요.

⚠️ GitHub Flow 의 핵심은 "브랜치를 짧게 유지" 하는 거예요. 기능 브랜치를 몇 주씩 끌면, 그 사이 main 이 저만치 앞서가서 나중에 합칠 때 충돌이 산더미처럼 쌓여요(지난 시간에 본 그 충돌이요). 며칠 안에 작게작게 합치는 습관이 GitHub Flow 를 잘 굴러가게 하는 비결이에요.

💡 한 줄 정리

브랜치 전략은 팀이 브랜치를 따고 합치는 약속이다. 그중 가장 단순한 GitHub Flow 는 main 을 항상 배포 가능하게 두고, 짧은 기능 브랜치를 PR 로만 합친 뒤 지운다. 지난 시간 우리가 돌린 한 바퀴가 바로 이것이고, 가장 널리 쓰이는 1순위 기본이다.

Step 2: "한 발 더 빠르게 — 트렁크 기반 개발"

GitHub Flow 를 익혔으니, 한 걸음 더 나아간 약속을 봐요. 바로 트렁크 기반 개발(Trunk-Based Development) 이에요. 이름의 "트렁크(trunk)" 는 나무의 몸통 줄기를 뜻해요. 여기선 main 브랜치를 그 몸통 줄기로 보고, 모두가 이 줄기 하나에 아주 자주 합치는 방식이에요.

GitHub Flow 와 뭐가 다를까요? GitHub Flow 도 기능 브랜치가 짧긴 했어요. 트렁크 기반은 그걸 극단적으로 더 짧게 가져가요. 브랜치를 아예 안 따고 main 에 바로 작은 커밋을 올리거나, 따더라도 하루 안에 닫아버려요. 하루에도 여러 번 main 에 합치는 거죠.

   트렁크 기반 개발 — 줄기 하나(main)에 하루에도 여러 번 합친다

   main  ●─●─●─●─●─●─●─●─●─●─▶   ← 모두가 자주 합치는 몸통 줄기
          ↑ ↑   ↑ ↑ ↑   ↑ ↑
          작은 변경들이 하루에도 여러 번 들어온다
          (브랜치를 따더라도 하루 안에 닫는다)

왜 이렇게 자주 합칠까요? 역설적이게도 충돌을 줄이려고 그래요. 브랜치가 짧을수록 그 사이 main 이 변하는 양이 적어서, 합칠 때 부딪힐 거리가 거의 없거든요. "조금씩 자주 합치면 아플 일이 없다" 는 거예요. 한 달치를 한 번에 합치는 것보다, 하루치를 매일 합치는 게 훨씬 안 아파요.

그런데 여기서 의문이 들죠. "아직 안 끝난 기능을 main 에 올리면, 반쪽짜리 코드가 배포되는 거 아닌가요?" 맞아요, 그게 트렁크 기반의 숙제예요. 그래서 이 방식은 기능 플래그(feature flag) 라는 장치를 같이 써요. 미완성 기능을 코드엔 올리되, "이 기능은 아직 꺼둠" 이라는 스위치로 사용자에게 안 보이게 가려두는 거예요. 코드는 합쳐졌지만 기능은 잠들어 있다가, 다 완성되면 스위치를 켜요.

⚠️ 트렁크 기반은 아무 팀이나 바로 쓸 수 있는 게 아니에요. 하루에도 여러 번 main 에 합치려면, 합칠 때마다 코드가 안 깨졌는지 자동으로 검사해주는 장치(자동화된 테스트) 가 탄탄해야 해요. 그게 없으면 깨진 코드가 main 에 수시로 섞여 들어가요. 그래서 트렁크 기반은 보통 "테스트 자동화가 잘 갖춰진 성숙한 팀이 지향하는 다음 단계" 로 봐요. (그 자동 검사 장치를 만드는 본격적인 이야기는 A-8 에서 맛보고, 인프라 과목에서 깊이 다뤄요.)

그러니 순서로 정리하면 이래요. 입문이나 대부분의 웹 서비스 팀은 GitHub Flow 로 시작하고, 팀의 테스트·배포 자동화가 무르익으면 트렁크 기반으로 옮겨가는 거예요. 트렁크 기반은 GitHub Flow 의 "브랜치를 짧게" 정신을 끝까지 밀어붙인 모습이라고 보면 돼요.

💡 한 줄 정리

트렁크 기반 개발은 모두가 main(트렁크) 줄기 하나에 하루에도 여러 번 작게 합치는 방식이다. 짧을수록 충돌이 적다는 원리이고, 미완성 기능은 기능 플래그로 가린다. 탄탄한 테스트 자동화가 전제라, GitHub Flow 다음 단계로 성숙한 팀이 지향한다.

Step 3: "버전을 끊어 파는 소프트웨어 — Git Flow"

이번엔 좀 다른 약속이에요. Git Flow 는 앞의 둘과 정반대로, 브랜치를 여러 개 길게 유지하는 복잡한 전략이에요. 한때 가장 유명한 전략이었는데, 지금은 특수한 경우에만 쓰는 레거시(예전 방식)로 봐요. "왜 옛날엔 이렇게 복잡하게 했나" 를 알아두면, 반대로 GitHub Flow 가 왜 단순함을 택했는지가 또렷해져요.

Git Flow 는 오래 사는 브랜치를 두 개나 둬요. main(배포된 안정 버전)과 develop(다음 버전을 위해 개발 중인 코드)이에요. 거기에 더해 작업 성격마다 브랜치를 따로 만들어요.

   Git Flow — 여러 브랜치가 길게 공존하는 복잡한 약속

   main     ●──────────────●────────────●──▶   배포된 안정 버전 (+ 태그)
             \            / \          /
   release    \          /   ●───●────         출시 직전 마무리 브랜치
               \        /   /
   develop  ●───●──●───●───●──────●──────▶      다음 버전 개발 줄기
                \  /        \    /
   feature       ●           ●──●               기능별 작업 브랜치
                                 hotfix ●──▶     배포된 버전의 긴급 수정

이 다섯 종류 브랜치가 각자 역할을 나눠 가져요. 기능은 feature 에서 만들어 develop 에 모으고, 출시할 때가 되면 release 브랜치에서 마무리해서 main 에 올리고, 이미 배포된 버전에 급한 버그가 터지면 hotfix 로 긴급 수정해요. 규칙이 빡빡한 만큼 단계가 분명하다는 장점은 있어요.

문제는 무겁다는 거예요. 브랜치가 많고 합치는 단계가 복잡해서, 하루에도 여러 번 배포하는 요즘 웹 서비스엔 너무 굼떠요. 그래서 일반적인 웹 서비스 팀은 Git Flow 를 떠나 GitHub Flow 로 많이 옮겨갔어요.

그럼 Git Flow 는 이제 안 쓰냐고요? 아니에요, 여전히 어울리는 곳이 있어요. 핵심은 "버전을 끊어서 배포하는 소프트웨어" 예요. 예를 들면 이런 곳들이에요.

• 모바일 앱 — 앱스토어 심사를 거쳐 v3.1, v3.2 처럼 버전을 끊어 내보내고, 여러 버전이 사용자 폰에 동시에 깔려 있어요.
• 설치형·온프렘 소프트웨어 — 고객사 서버에 버전별로 설치되고, 옛 버전도 한동안 같이 유지보수해야 해요.
• 라이브러리·SDK — 남들이 가져다 쓰는 거라 버전마다 안정성이 중요하고, 옛 버전 버그도 따로 고쳐줘야 해요.

이런 곳은 "여러 버전을 동시에 관리하고 급한 수정도 버전별로 해야" 하니까, release·hotfix 같은 브랜치가 실제로 쓸모가 있어요. 웹 서비스처럼 "항상 최신 하나만 돌아가는" 곳과는 사정이 다른 거죠.

⚠️ Git Flow 를 소개하는 옛 자료들이 main 대신 master 라는 이름을 쓰는 걸 자주 보게 될 거예요. master 는 예전 기본 브랜치 이름이고, 지금은 main 이 표준이에요(A-1 에서 짚었죠). 이름만 바뀐 거니, 옛 자료에서 master 를 보면 머릿속으로 main 으로 바꿔 읽으면 돼요.

💡 한 줄 정리

Git Flow 는 main·develop·feature·release·hotfix 등 여러 브랜치를 길게 유지하는 복잡한 전략이다. 무거워서 일반 웹 서비스엔 레거시로 밀려났지만, 모바일 앱·설치형 SW·라이브러리처럼 버전을 끊어 배포하고 여러 버전을 동시에 유지하는 곳에선 여전히 어울린다.

Step 4: "우리 팀은 뭘 골라야 할까 — 세 전략 비교"

세 가지 약속을 다 만났어요. 이제 나란히 놓고 견줘봐요. 신입으로 입사하면 "우리 팀은 왜 이 방식으로 일하지?" 가 궁금할 텐데, 이 비교표 하나면 그 답이 보여요.

표를 한 문장으로 요약하면 이래요. "단일 최선은 없고, 팀의 배포 주기와 성숙도가 전략을 정한다." 항상 최신 하나만 돌리는 웹 서비스면 GitHub Flow 로 시작해서 자동화가 익으면 트렁크 기반으로, 버전을 끊어 파는 소프트웨어면 Git Flow 로. 이게 2026 년 현업의 큰 그림이에요.

고를 때 스스로에게 던질 질문은 딱 두 개예요.

   우리 팀 브랜치 전략 고르기 — 두 가지 질문

   Q1. 우리는 버전을 끊어서 배포하나?
        예                  → Git Flow 계열 (모바일·설치형·라이브러리)
        아니오(항상 최신 하나) → Q2 로

   Q2. 테스트 자동화가 하루 여러 번 배포를 받쳐줄 만큼 탄탄한가?
        아직 아니다  → GitHub Flow (기본)
        충분히 탄탄  → 트렁크 기반 (다음 단계)

그런데 여기서 꼭 안심시켜드릴 게 있어요. 신입인 여러분이 이 전략을 혼자 정하는 일은 거의 없어요. 전략은 보통 팀 리드나 선배들이 이미 정해뒀고, 여러분은 그 약속에 맞춰 따라가면 돼요. 오늘 이걸 배우는 이유는 직접 고르려는 게 아니라, "우리 팀은 왜 이렇게 일하는지" 를 이해하고 자연스럽게 녹아들기 위해서예요. 입사 첫 주에 "우리 브랜치 전략이 GitHub Flow 군요, 그래서 브랜치를 짧게 가져가는 거네요" 하고 알아채면, 그게 바로 빠르게 적응하는 신입이에요.

💡 한 줄 정리

세 전략에 단일 정답은 없다. 버전을 끊어 파나? 면 Git Flow, 항상 최신 하나면 GitHub Flow(기본)로 시작해 자동화가 익으면 트렁크 기반으로 간다. 신입은 보통 팀이 정해둔 전략을 따르므로, 고르는 능력보다 "왜 이걸 쓰는지" 를 이해하는 게 먼저다.

Step 5: "남의 공개 저장소에 기여하기 — fork와 upstream"

지금까지 우리가 PR 을 올린 곳은 전부 내 저장소였어요. 내가 만들었으니 push 권한이 있죠. 그런데 세상엔 내가 권한이 전혀 없는 멋진 공개 저장소가 가득해요. 리액트, 스프링, 파이썬 같은 유명한 도구들도 전부 GitHub 에 공개돼 있고, 누구나 코드를 볼 수 있어요. 이렇게 소스가 공개돼 모두가 함께 키우는 프로젝트를 오픈소스(open source) 라고 해요.

"저기 오타 하나가 보이는데 고쳐주고 싶다" 거나 "이 기능에 작은 개선을 보태고 싶다" 면 어떻게 할까요? 내 저장소가 아니니 브랜치를 따서 push 할 수가 없어요. 권한이 없으니까요. 여기서 등장하는 게 fork(포크) 예요.

fork 는 남의 공개 저장소를 내 GitHub 계정으로 통째로 복사해오는 거예요. 복사본은 내 것이니 마음대로 브랜치 따고 push 할 수 있죠. 거기서 고친 다음, "제가 이렇게 고쳤는데 원본에 합쳐주실래요?" 하고 원본 저장소에 PR 을 보내는 거예요.

여기서 두 개의 원격이 등장해요. 지난 시간까지 우리가 알던 원격은 origin 하나뿐이었죠. 이제 하나가 더 생겨요.

   오픈소스 기여 — 두 개의 원격(remote)

   upstream  ●  원본 저장소 (남의 것, 나는 읽기만 가능)
             │
             │ fork (내 계정으로 복사)
             ▼
   origin    ●  내 fork (내 계정, 읽기·쓰기 자유)
             │
             │ clone
             ▼
   로컬      ●  내 컴퓨터

• origin — 내 fork(내 계정에 복사된 저장소)예요. 내 것이라 push 할 수 있어요.
• upstream — fork 의 원본, 즉 진짜 원본 저장소예요. "위쪽 물줄기" 라는 뜻인데, 내 fork 가 흘러나온 본류라고 보면 돼요. 나는 보통 여기에 직접 push 못 하고, 변경 사항을 받아오기(fetch)만 해요.

A-4 에서 제가 "origin 말고 두 번째 원격을 나중에 만난다" 고 예고했었죠? 그 두 번째 원격이 바로 이 upstream 이에요. 오픈소스에 기여할 때 비로소 등장하는 거예요.

왜 굳이 두 개를 둘까요? 원본의 최신 변화를 따라가기 위해서예요. 내가 fork 를 뜬 뒤에도 원본(upstream)은 다른 기여자들 덕분에 계속 발전해요. 내 fork(origin)는 복사한 그 순간에 멈춰 있고요. 그래서 가끔 upstream 에서 최신 변경을 받아와 내 fork 를 따라잡게 해줘야 해요. 그 동기화 흐름은 다음 Step 에서 직접 해봐요.

💡 한 줄 정리

오픈소스처럼 권한 없는 공개 저장소엔 fork 로 내 계정에 복사본을 만들어 기여한다. 이때 원격이 둘이 된다 — 내 복사본인 origin(push 가능)과 원본인 upstream(받아오기만). A-4 에서 예고한 두 번째 원격이 바로 upstream 이다.

Step 6: "오픈소스 첫 PR 한 바퀴 — fork 흐름 실전"

이제 fork 로 오픈소스에 기여하는 한 바퀴를 직접 밟아봐요. 실제로 어떤 공개 저장소든 하나 골라(연습용으론 octocat/Spoon-Knife 같은 연습 저장소가 유명해요) 따라 하면 돼요. 순서는 여섯 단계예요.

   오픈소스 기여 한 바퀴 — fork에서 PR까지

   ① 원본을 fork            (GitHub 에서 버튼 한 번 → 내 계정에 복사)
   ② 내 fork를 clone         git clone (내 컴퓨터로)
   ③ upstream 원격 등록      git remote add upstream <원본 주소>
   ④ 기능 브랜치에서 작업     git switch -c fix/typo → 수정 → commit
   ⑤ 내 fork(origin)로 push   git push -u origin fix/typo
   ⑥ 원본을 향해 PR           내 fork → 원본 방향으로 Pull Request

먼저 ①은 GitHub 웹에서 해요. 원본 저장소 페이지 오른쪽 위의 "Fork" 버튼을 누르면, 내 계정 아래로 복사본이 생겨요. 그다음부터는 터미널이에요.

# ② 내 fork를 내 컴퓨터로 내려받기 (A-4의 clone)
git clone https://github.com/내아이디/Spoon-Knife.git
cd Spoon-Knife

# ③ 원본 저장소를 upstream이라는 이름의 두 번째 원격으로 등록
git remote add upstream https://github.com/octocat/Spoon-Knife.git

# 원격이 두 개가 됐는지 확인
git remote -v
# origin    https://github.com/내아이디/Spoon-Knife.git   ← 내 fork (push 가능)
# upstream  https://github.com/octocat/Spoon-Knife.git    ← 원본 (받아오기만)

git clone 으로 받으면 내 fork 가 자동으로 origin 으로 등록돼요(A-4 에서 봤죠). 거기에 git remote add upstream 으로 원본을 두 번째 원격으로 더해주면, git remote -v 에 두 줄이 보여요. 이제 준비 끝이에요.

# ④ 기능 브랜치를 따서 작업 (A-2의 switch)
git switch -c fix/readme-typo
# (파일을 고치고)
git add README.md
git commit -m "README 오타 수정"

# ⑤ 내 fork(origin)에 push (A-4의 push)
git push -u origin fix/readme-typo

보세요, ④⑤는 우리가 이미 수십 번 한 브랜치·커밋·push 그대로예요. 오픈소스라고 특별한 명령이 있는 게 아니에요. 딱 하나 다른 건 ⑥ PR 의 방향이에요.

내 fork 에서 push 한 뒤 GitHub 에 가면 "Compare & pull request" 버튼이 떠요(A-5 그대로). 누르면 PR 화면이 나오는데, 여기서 방향을 잘 봐야 해요. base(합쳐질 곳)가 원본 저장소의 main, compare(합쳐질 변경)가 내 fork 의 브랜치로 돼 있어요. 즉 "내 fork 의 변경을 원본에 합쳐주세요" 라는 요청이에요. 내 저장소 안에서 PR 올릴 때와 화면은 똑같은데, base 가 남의 원본을 가리킨다는 점만 달라요.

🌟 GUI 로는 — ① fork 는 GitHub 웹 저장소 페이지의 "Fork" 버튼으로, ② clone 은 GitHub Desktop 의 "Clone repository" 로 해요. 터미널을 떠나기 싫다면 GitHub CLI 로 한 번에 fork+clone 도 돼요 — gh repo fork octocat/Spoon-Knife --clone 한 줄이면 fork 를 뜨고 내 컴퓨터로 내려받고 upstream 까지 자동으로 등록해줘요.

PR 을 올리고 나면, 원본의 관리자가 검토하고 합칠지 말지를 결정해요. 합쳐지면 축하해요 — 여러분의 코드가 전 세계가 쓰는 오픈소스에 들어간 거예요! 그런데 한 가지 숙제가 남아요. 시간이 지나면 원본(upstream)은 다른 사람들 기여로 계속 앞서가는데, 내 fork(origin)는 뒤처져요. 그래서 다음에 또 기여하려면 내 fork 를 원본 최신 상태로 따라잡게 해줘야 해요.

# 내 fork를 원본(upstream) 최신으로 동기화하기
git switch main              # 내 로컬 main으로 이동 (A-2)
git fetch upstream           # 원본의 최신 변경을 받아오기만 (A-4의 fetch)
git merge upstream/main      # 받아온 원본 최신을 내 main에 합치기 (A-2의 merge)
git push origin main         # 따라잡은 내 main을 내 fork에도 올리기 (A-4의 push)

이 네 줄이 fork 기여에서 신입이 가장 많이 빠뜨리는 부분이에요. fetch upstream 으로 원본 변화를 받아와 merge 로 내 것에 합치고, push 로 내 fork 까지 맞춰주면, 내 fork 가 원본과 같은 출발선에 다시 서요. 이걸 게을리하면 한참 뒤처진 fork 에서 작업하다가 PR 올릴 때 충돌투성이가 돼요.

⚠️ fork 동기화는 자주 해주는 게 약이에요. 특히 새 기능에 손대기 직전엔 꼭 한 번 upstream 을 받아와 따라잡고 시작하세요. GitHub Flow 에서 "브랜치를 짧게" 가 비결이었듯, fork 기여에선 "원본을 자주 따라잡기" 가 충돌을 막는 비결이에요.

💡 한 줄 정리

오픈소스 기여는 fork → clone → upstream 등록 → 기능 브랜치 작업 → 내 fork(origin)에 push → 원본을 향해 PR 의 여섯 단계다. 작업 명령은 우리가 쓰던 브랜치·커밋·push 그대로이고, PR 의 base 가 원본을 가리키는 점만 다르다. 기여 뒤엔 fetch upstream + merge + push 로 내 fork 를 원본 최신에 맞춘다.

Step 7: "버전에 이름표 달기 — 태그·릴리스와 SemVer"

마지막이에요. 기능을 다 만들어 "이게 우리 서비스의 1.0 버전이다!" 하고 도장을 찍고 싶을 때가 있어요. 수많은 커밋 중 특정 순간을 콕 집어 "여기가 그 버전" 이라고 이름표를 붙이는 게 태그(tag) 예요.

커밋 해시는 a3f9c2e 처럼 외우기 힘든 글자죠. 태그는 그 위에 v1.0.0 같은 사람이 읽기 좋은 이름을 달아줘요. "그 버전 코드 좀 줘" 할 때 해시 대신 v1.0.0 으로 정확히 그 순간을 꺼낼 수 있어요.

# 지금 이 커밋에 버전 이름표 달기 (annotated 태그 — 권장)
git tag -a v1.0.0 -m "첫 정식 출시"

# 태그 목록 보기
git tag
# v1.0.0

# 태그는 자동으로 안 올라간다 — 따로 push 해야 원격에 보인다
git push origin v1.0.0

태그엔 두 종류가 있어요. 위에서 쓴 -a 옵션을 붙인 annotated 태그는 만든 사람·날짜·메시지까지 담긴 정식 이름표라, 출시 버전엔 이걸 써요. -a 없이 git tag v1.0.0 만 하면 lightweight 태그 — 그냥 포스트잇처럼 이름만 붙는 가벼운 거예요. 잠깐 표시용이면 가벼운 거, 진짜 출시면 annotated, 이렇게 기억하면 돼요.

여기서 GitHub 의 릴리스(release) 가 한 단계 더 얹혀요. 릴리스는 태그를 바탕으로 GitHub 가 만들어주는 출시 안내 페이지예요. "v1.0.0 에서 뭐가 바뀌었는지(변경 사항)" 와 내려받을 파일을 보기 좋게 정리해 보여줘요. 사용자는 이 페이지에서 원하는 버전을 골라 받아갈 수 있죠.

🌟 GUI 로는 — GitHub 저장소의 "Releases" → "Draft a new release" 에서 태그를 고르고 변경 사항을 적으면 릴리스가 만들어져요. 터미널파라면 gh release create v1.0.0 --notes "첫 정식 출시" 한 줄로도 돼요.

그런데 버전 번호를 아무렇게나 매기면 사용자가 헷갈려요. v1.0.0 다음이 v1.1.0 인지 v2.0.0 인지 규칙이 있어야죠. 그 약속이 바로 SemVer(Semantic Versioning, 유의적 버전) 예요. 버전을 점 두 개로 끊어 MAJOR.MINOR.PATCH(주·부·수)로 읽어요.

   SemVer — 버전 번호 X.Y.Z 의 의미

        1   .   4   .   2
        │       │       │
        │       │       └ PATCH : 버그 수정 (기존과 호환됨)
        │       └──────── MINOR : 기능 추가 (기존과 호환됨)
        └──────────────── MAJOR : 호환이 깨지는 큰 변경

규칙은 단순해요. 버그만 고쳤으면 맨 뒤(PATCH)를 올리고, 기존 걸 안 깨면서 기능을 더했으면 가운데(MINOR)를 올리고, 기존 사용 방식이 깨지는 큰 변경이면 맨 앞(MAJOR)을 올려요. 예를 들어 1.4.1 에서 버그만 고치면 1.4.2, 거기에 호환되는 기능을 더하면 1.5.0, 사용 방식이 깨지는 큰 변경이면 2.0.0 이 되는 식이에요. 사용자는 번호만 보고 "아, 가운데만 올랐으니 안심하고 올려도 되겠네" 하고 판단할 수 있어요. 버전 번호가 일종의 약속 신호가 되는 거예요.

마지막으로 가볍게 하나 더. 커밋 메시지에도 비슷한 약속이 있어요. Conventional Commits(컨벤셔널 커밋) 라고, 커밋 메시지 앞에 종류를 붙이는 규칙이에요.

git commit -m "feat: 프로필에 소개글 기능 추가"   # feat = 기능 추가
git commit -m "fix: 로그인 버튼 터치 오류 수정"    # fix  = 버그 수정
git commit -m "docs: README에 설치법 추가"        # docs = 문서

feat(기능)·fix(버그)·docs(문서)처럼 앞에 한 단어를 붙여요. 이게 왜 좋냐면, A-1 에서 배운 "좋은 커밋 메시지" 를 한 발 더 밀어서 기계도 알아볼 수 있게 만들거든요. feat 가 쌓이면 SemVer 의 MINOR 를, fix 가 쌓이면 PATCH 를 올리는 식으로, 도구가 커밋만 보고 다음 버전 번호와 변경 목록을 자동으로 만들어줄 수도 있어요. 좋은 커밋 메시지가 규약을 만나 자동화로 이어지는 거예요.

💡 한 줄 정리

태그(git tag -a v1.0.0)는 특정 커밋에 사람이 읽을 버전 이름표를 단다(따로 push 필요). GitHub 릴리스는 그 태그로 출시 안내 페이지를 만든다. 버전 번호는 SemVer 의 MAJOR.MINOR.PATCH 규칙으로 매기고, 커밋 메시지는 Conventional Commits(feat·fix·docs)로 일관되게 적으면 자동화까지 이어진다.

마무리

오늘 우리는 git 을 "여럿이 함께 쓰는 도구" 에서 "팀과 세상과 함께 협업하는 도구" 로 넓혔어요. 팀이 협업하는 약속인 브랜치 전략 세 가지를 구분하고, 우리 팀에 맞는 걸 고르는 기준을 세웠죠. 그리고 내 저장소를 넘어 남의 오픈소스에 fork 로 기여하는 한 바퀴를 익히고, 완성된 버전에 태그를 달아 SemVer 규칙으로 릴리스하는 법까지 손에 넣었어요. 이제 여러분은 "어느 팀, 어느 프로젝트에 가도 그들의 협업 약속에 자연스럽게 녹아들 수 있는" 협업의 뼈대를 갖췄어요.

오늘 배운 핵심 세 가지

• 💡 하나 — 브랜치 전략은 팀의 협업 약속이고, 정답은 상황이 정한다. 가장 단순한 GitHub Flow 가 기본, 자동화가 익으면 트렁크 기반, 버전을 끊어 파는 소프트웨어엔 Git Flow. 신입은 보통 팀이 정한 약속을 따르므로 "왜 이걸 쓰는지" 이해가 먼저다.
• 💡 둘 — 오픈소스엔 fork 와 두 원격으로 기여한다. 원본을 fork 해 내 계정에 복사하고, origin(내 fork)과 upstream(원본) 두 원격을 둔다. 작업 명령은 쓰던 그대로, PR 의 base 가 원본을 가리키는 점만 다르다. 기여 뒤엔 fetch upstream 으로 내 fork 를 자주 따라잡는다.
• 💡 셋 — 완성된 버전엔 이름표를 단다. 태그로 특정 커밋에 v1.0.0 을 달고 릴리스로 출시 페이지를 만든다. 버전 번호는 SemVer(MAJOR.MINOR.PATCH), 커밋 메시지는 Conventional Commits(feat·fix)로 일관되게.

다음 시간 예고

오늘 fork 동기화에서 merge 로 원본 최신을 합쳤죠. 그런데 합치는 방법이 merge 만 있는 게 아니에요. 지난 시간 GitHub 가 버튼으로 대신 해주던 합치기 중에 "Rebase" 가 있었던 거 기억하세요? 다음 시간엔 그 rebase 를 직접 손으로 다뤄요. merge 와 rebase 가 역사를 어떻게 다르게 만드는지(다이어그램으로 나란히), 지저분한 커밋 여러 개를 어떻게 깔끔히 정리하는지(rebase -i)를 배워요.

그리고 한 가지 꼭 짚을 게 있어요. rebase 는 역사를 고쳐 쓰는 강력한 도구라, "이미 남과 공유한 브랜치는 절대 rebase 하지 않는다" 는 황금률이 있어요. 이 약속을 어기면 동료의 저장소와 엉켜요. 다음 시간엔 이 황금률과, 부득이할 때 안전하게 강제 push 하는 --force-with-lease 까지 함께 익힙니다. 협업 git 의 마지막 고급 조각이에요.

과제

오늘 배운 건 눈으로만 보면 절대 안 익어요. 특히 fork 는 직접 한 바퀴 돌려봐야 "아, 두 원격이 이렇게 도는구나" 가 몸에 새겨져요. 꼭 여러분 GitHub 계정으로 직접 해보세요.

[기초] 내 저장소를 GitHub Flow 규칙대로 한 바퀴 돌리기

연습 저장소에서 GitHub Flow 의 다섯 규칙을 의식하며 한 바퀴를 돌려보세요.

git switch -c feature/연습 으로 짧은 기능 브랜치를 따고, 파일을 고쳐 커밋한 뒤 push 하고, PR 을 올려 합치고, 기능 브랜치를 지우세요(전부 지난 시간에 한 흐름이에요). 그러고 나서 "내가 방금 한 이 흐름이 왜 GitHub Flow 라고 불리는지, 다섯 규칙 중 어떤 걸 지켰는지" 를 한두 문장으로 적어보세요.

[응용] 실제 오픈소스를 fork 해서 두 원격 세팅까지

GitHub 에서 마음에 드는 공개 저장소를 하나 골라(연습용 octocat/Spoon-Knife 도 좋아요) fork → clone → upstream 등록까지 해보세요.

원본을 fork 하고, 내 fork 를 git clone 으로 내려받고, git remote add upstream <원본주소> 로 두 번째 원격을 등록한 뒤, git remote -v 로 origin 과 upstream 두 줄이 다 보이는지 확인하세요. (실제 PR 제출까지 가보면 더 좋지만, 무리하지 않아도 돼요.) 마지막으로 "origin 과 upstream 이 각각 무엇을 가리키는지, 왜 둘을 나눠 두는지" 를 한 문장으로 적어보세요.

상상해보세요 — 입사 후 팀이 쓰는 사내 라이브러리에 작은 개선을 보태야 하는 상황이요. 그때도 똑같이 fork 하고 두 원격을 세팅하게 될 거예요. 오늘 연습이 그대로 실무가 됩니다.

[심화] 버전에 이름표 달고 릴리스까지

연습 저장소의 어느 커밋에 SemVer 규칙으로 태그를 달고, GitHub 릴리스로 만들어보세요.

git tag -a v1.0.0 -m "첫 출시" 로 annotated 태그를 달고 git push origin v1.0.0 으로 올리세요. 그다음 GitHub "Releases" 에서 그 태그로 릴리스를 하나 만들어보고요. 여유가 되면 커밋 두세 개를 Conventional Commits 형식(feat:·fix:)으로 적어보세요. 마지막으로 "버그만 고쳤다면 다음 버전 번호가 v1.0.1 인지 v1.1.0 인지, 왜 그런지" 를 SemVer 규칙으로 설명해보세요.

생각해볼 주제

1. 우리 팀은 GitHub Flow 일까, 트렁크 기반일까

두 전략은 형제처럼 닮았지만, "브랜치를 얼마나 짧게" 와 "자동화에 얼마나 기대느냐" 에서 갈렸어요. 만약 여러분이 5명짜리 작은 팀의 리드라면, 막 시작한 단계에서 어느 쪽을 택하겠어요? 그리고 1년 뒤 팀이 20명으로 커지고 자동 테스트가 탄탄해졌다면, 그 선택을 바꿀까요? 트렁크 기반이 주는 속도의 이득과, 그걸 받치려면 먼저 갖춰야 하는 비용(테스트 자동화)을 견줘보세요.

2. Git Flow 가 한물갔다는데, 아직도 쓰는 곳이 있는 이유

요즘 웹 서비스는 대부분 Git Flow 를 떠났는데, 모바일 앱이나 설치형 소프트웨어 팀은 여전히 비슷한 다층 브랜치를 써요. 같은 git 인데 왜 어떤 곳은 단순함을, 어떤 곳은 복잡함을 택할까요? 힌트는 "배포의 모양" 에 있어요. 항상 최신 하나만 돌리는 서비스와, 여러 버전이 사용자에게 동시에 깔려 있는 소프트웨어의 차이를 떠올려보세요. 전략은 취향이 아니라 그 소프트웨어가 세상에 나가는 방식이 정한다는 걸 풀어보면 좋아요.

3. fork 동기화를 게을리하면 6개월 뒤 무슨 일이

fork 를 뜬 뒤 upstream 을 한 번도 안 따라잡고 6개월이 지났다고 해봐요. 그 사이 원본은 수백 개의 커밋이 쌓였고요. 이제 내 fork 에서 새 기능을 만들어 PR 을 올리려 하면 어떤 일이 벌어질까요? 왜 "기여 직전에 원본을 자주 따라잡기" 가 GitHub Flow 의 "브랜치를 짧게" 와 같은 정신인지, 충돌이라는 키워드로 엮어 생각해보세요.