Git on kastori

알아두면 구하는 Git 명령어 — rebase, squash, cherry-pick, stash, revert

Thu, 11 Jun 2026 00:00:00 +0900

언제 이 명령어들이 필요한가

"PR 전에 WIP 커밋 5개를 하나로 합치고 싶다" → squash
"main이 업데이트됐는데 내 브랜치에 깔끔하게 반영하고 싶다" → rebase
"hotfix 커밋을 다른 브랜치에도 적용하고 싶다" → cherry-pick
"작업 중인데 급하게 다른 브랜치로 가야 한다" → stash
"push한 커밋을 이력을 남기며 취소하고 싶다" → revert
"실수로 커밋을 날렸다" → reflog

rebase — 커밋 히스토리 재배치

merge vs rebase

상황: main에 새 커밋이 생긴 동안 feature 브랜치에서 작업

merge 결과 (머지 커밋 생성):
 main: A → B → C → M
 ↗
 feature: D → E

rebase 결과 (feature를 main 위로 재배치):
 main: A → B → C → D' → E'

rebase는 히스토리가 선형으로 유지된다. PR 전에 main의 최신 상태를 반영할 때 유용하다.

git checkout feature/login-api
git rebase main

# 충돌 발생 시
# 1. 충돌 파일 수정
# 2. git add <파일>
# 3. git rebase --continue
# 취소: git rebase --abort

주의: rebase는 커밋 해시가 바뀐다. 팀원과 공유 중인 브랜치에는 절대 쓰지 않는다. 자신의 feature 브랜치에서만.

Interactive Rebase — 커밋 편집

git rebase -i로 과거 커밋을 합치거나 편집한다.

# 최근 3개 커밋 편집
git rebase -i HEAD~3

에디터가 열리면:

pick a1b2c3 WIP: 로그인 API 작업 중
pick d4e5f6 WIP: 유효성 검증 추가
pick g7h8i9 feat(auth): 로그인 API 완성

# 명령어:
# pick → 그대로 유지
# squash → 이전 커밋과 합치기 (커밋 메시지 편집 가능)
# fixup → 이전 커밋과 합치기 (메시지는 이전 것 유지)
# drop → 커밋 삭제
# reword → 커밋 메시지만 수정

WIP 커밋들을 squash로 정리:

pick a1b2c3 WIP: 로그인 API 작업 중
squash d4e5f6 WIP: 유효성 검증 추가
squash g7h8i9 feat(auth): 로그인 API 완성

저장하면 세 커밋이 하나로 합쳐지고 메시지를 새로 작성할 수 있다.

cherry-pick — 특정 커밋만 가져오기

# 커밋 해시 확인
git log --oneline feature/payment
# a1b2c3 feat(payment): 카드 결제 핵심 로직

# 해당 커밋만 현재 브랜치로 가져오기
git cherry-pick a1b2c3

주로 쓰는 상황:

hotfix를 main에 적용했는데 develop에도 반영해야 할 때
특정 기능 커밋만 다른 브랜치에 선별 적용할 때

# 여러 커밋 한 번에
git cherry-pick a1b2c3 d4e5f6

# 범위로
git cherry-pick a1b2c3..g7h8i9

cherry-pick은 커밋을 복사하는 것. 원본 브랜치에도 커밋이 그대로 남는다.

stash — 작업 중간에 브랜치 전환

커밋하기엔 이르고 전환은 해야 할 때.

# 현재 변경사항 임시 저장
git stash

# 다른 브랜치 작업 후 돌아와서
git stash pop # 꺼내고 목록에서 삭제
git stash apply # 꺼내되 목록에 유지

# stash 목록 확인
git stash list
# stash@{0}: WIP on feature/login: ...
# stash@{1}: WIP on feature/payment: ...

# 특정 stash 적용
git stash apply stash@{1}

reflog — 실수 복구의 안전망

# 실수로 커밋을 날렸다
git reset --hard HEAD~3 # 최근 3개 커밋 삭제

# reflog로 삭제 전 상태 찾기
git reflog
# a1b2c3 HEAD@{0}: reset: moving to HEAD~3
# d4e5f6 HEAD@{1}: commit: feat: 주문 API 추가 ← 이걸 살려야 함
# g7h8i9 HEAD@{2}: commit: feat: 상품 조회 API

# 복구
git reset --hard d4e5f6

reflog는 로컬 Git의 모든 HEAD 이동 기록이다. git push한 후가 아니라면 대부분의 실수를 복구할 수 있다.

reset 정리

git reset --soft HEAD~1
 → 커밋만 취소. 변경사항은 staged 상태로 남음.
 → 커밋 메시지만 고치고 싶을 때.

git reset --mixed HEAD~1 (기본값)
 → 커밋 취소. 변경사항은 unstaged 상태.
 → 파일은 남아있음.

git reset --hard HEAD~1
 → 커밋 취소 + 변경사항 완전 삭제.
 → 되돌릴 수 없음. 신중하게.

revert — 이력을 남기며 되돌리기

reset은 커밋을 삭제하지만 revert는 되돌리는 새 커밋을 만든다. 이미 push한 브랜치에서는 revert가 안전하다.

# 특정 커밋 되돌리기
git revert a1b2c3

# 여러 커밋 되돌리기
git revert a1b2c3 d4e5f6

# 커밋 메시지 편집 없이 바로
git revert --no-edit a1b2c3

reset vs revert 선택 기준:

reset → 로컬에서만 작업 중, 아직 push 안 함
 커밋 자체를 없애고 싶다

revert → 이미 push했거나 팀과 공유 중인 브랜치
 "이 커밋을 취소했다"는 이력을 남겨야 한다

# 예시: 배포 후 문제가 생긴 커밋 롤백
git log --oneline
# f1a2b3 feat: 결제 모듈 배포 ← 이게 문제

git revert f1a2b3
# → "Revert 'feat: 결제 모듈 배포'" 커밋 생성
git push origin main

이력에 revert 커밋이 남기 때문에 “언제 왜 롤백했는지"가 추적된다.

마치며

이 시리즈에서 다룬 것들:

#1 브랜칭 전략 → 팀이 브랜치를 어떻게 운영할지
#2 커밋 컨벤션 → 변경 이력을 어떻게 기록할지
#3 PR & 코드리뷰 → 변경을 어떻게 검토하고 합칠지
#4 릴리즈 관리 → 버전을 어떻게 관리하고 배포할지
#5 고급 명령어 → 실무에서 마주치는 상황별 도구

혼자 프로젝트를 할 때도 이 흐름을 연습해두면, 팀에 합류했을 때 코드보다 협업 방식을 배우는 데 시간을 쓰지 않아도 된다.

버전 번호가 약속인 이유 — SemVer, Git Tag, CHANGELOG 관리

Wed, 10 Jun 2026 00:00:00 +0900

버전 번호는 사용자와의 약속이다

spring-boot-3.2.1을 쓰고 있다가 3.2.2로 올릴 때와 4.0.0으로 올릴 때 대응이 다르다. 3.2.2는 버그 수정이니 그냥 올려도 되지만, 4.0.0은 Breaking Change가 있을 수 있으니 마이그레이션 가이드를 먼저 읽어야 한다.

이 약속이 **Semantic Versioning(SemVer)**이다.

Semantic Versioning

형식: MAJOR.MINOR.PATCH — 예: 1.4.2

MAJOR → 하위 호환 안 되는 변경 (Breaking Change)
 API 응답 형식 변경, 파라미터 제거
 사용자가 코드를 수정해야 함
 예: 1.4.2 → 2.0.0

MINOR → 하위 호환되는 새 기능 추가
 기존 코드 수정 없이 새 기능 사용 가능
 예: 1.4.2 → 1.5.0

PATCH → 하위 호환되는 버그 수정
 예: 1.4.2 → 1.4.3

Conventional Commits와 연결

커밋 타입이 버전에 자동으로 영향을 준다.

feat: → MINOR 업 (1.4.2 → 1.5.0)
fix:, perf: → PATCH 업 (1.4.2 → 1.4.3)
docs:, style: 등 → 변화 없음
feat!: 또는
BREAKING CHANGE: → MAJOR 업 (1.4.2 → 2.0.0)

초기 개발 (0.x.x)

0.1.0 → 아직 안정적이지 않음. 언제든 Breaking Change 가능.
1.0.0 → 공개 API 확정. 이후부터 SemVer 약속 적용.

Git Tag — 버전 번호를 커밋에 붙이기

# 태그 생성 (annotated tag 권장)
git tag -a v1.2.0 -m "Release v1.2.0"

# 원격에 푸시 (태그는 git push에 포함 안 됨)
git push origin v1.2.0

# 모든 태그 한 번에 푸시
git push origin --tags

# 태그 목록 확인
git tag

# 특정 태그로 체크아웃
git checkout v1.2.0

lightweight vs annotated tag

lightweight tag: git tag v1.2.0
 → 단순 포인터. 커밋 해시에 별칭을 붙이는 것.

annotated tag: git tag -a v1.2.0 -m "메시지"
 → 태그 작성자, 날짜, 메시지, GPG 서명 포함
 → 릴리즈에는 annotated tag 권장

CHANGELOG — 릴리즈 이력 문서화

변경 이력을 사람이 읽을 수 있는 형태로 정리한 문서.

Keep a Changelog 형식

# CHANGELOG

## [Unreleased]

## [1.3.0] - 2026-06-04

### Added
- Google OAuth2 소셜 로그인 추가 (#123)
- 주문 취소 API 추가 (#124)

### Fixed
- 로그아웃 후 토큰 무효화 안 되는 버그 수정 (#125)

### Changed
- 회원 API 응답 형식 userId → id 변경

## [1.2.1] - 2026-05-20

### Fixed
- 주문 목록 페이징 오류 수정

자동 생성

Conventional Commits를 지켰다면 CHANGELOG를 자동으로 생성할 수 있다.

npm install -g conventional-changelog-cli
conventional-changelog -p angular -i CHANGELOG.md -s

릴리즈 프로세스 (GitHub Flow 기준)

# 1. 릴리즈할 main이 준비됐는지 확인
git checkout main && git pull

# 2. 버전 번호 결정 (커밋 내역 기반)
# feat 있으면 MINOR, fix만 있으면 PATCH

# 3. CHANGELOG 업데이트
conventional-changelog -p angular -i CHANGELOG.md -s
git add CHANGELOG.md
git commit -m "chore: v1.3.0 릴리즈 노트 업데이트"

# 4. 태그 생성 및 푸시
git tag -a v1.3.0 -m "Release v1.3.0"
git push origin main --tags

# 5. GitHub Release 생성 (UI 또는 gh CLI)
gh release create v1.3.0 --notes-from-tag

마치며

버전 관리는 “배포했다"를 기록하는 것이 아니라 “무엇이 어떻게 바뀌었는가"를 약속하는 것이다. SemVer + Conventional Commits + CHANGELOG 세 가지가 맞물리면 릴리즈마다 노트를 수동으로 작성할 필요도 없다.

다음 편에서는 rebase, squash, cherry-pick 같은 실무 고급 명령어를 다룬다.

PR을 잘 쓴다는 것 — 작성자와 리뷰어가 모두 편한 코드 리뷰

Mon, 08 Jun 2026 00:00:00 +0900

리뷰어의 입장에서 생각하기

PR을 올리고 “리뷰 부탁드립니다"를 남긴다. 리뷰어는 맥락 없이 diff만 본다. “이게 왜 바뀐 거지?”, “뭘 테스트해야 하지?”, “어디서 실행해볼 수 있지?” — 이 질문들이 드는 PR은 리뷰 시간이 3배가 된다.

좋은 PR은 리뷰어의 이 질문들을 미리 답해놓은 문서다.

PR 크기 — 작을수록 좋다

✅ 이상적인 PR
 - 변경 파일 5~10개 이하
 - 변경 라인 400줄 이하
 - 하나의 목적 (기능 1개, 버그 1개)

❌ 피해야 할 PR
 - "기능 A + 리팩터링 + 의존성 업그레이드" 한 번에
 - 1,000줄 넘는 PR → 리뷰어가 세부 사항을 놓침

큰 기능을 어떻게 쪼개는가: 레이어 단위로 나눈다.

PR 1: Entity + Repository 추가
PR 2: Service 로직 구현
PR 3: Controller + API 엔드포인트
PR 4: 테스트 코드

각 PR이 독립적으로 리뷰·머지 가능하도록 설계하면 리뷰 속도가 빨라진다.

PR 본문 — 리뷰어가 필요한 정보를 모두 담는다

## 변경 사항
Google OAuth2를 통한 소셜 로그인 기능을 구현했습니다.
기존 이메일/비밀번호 로그인과 함께 사용할 수 있습니다.

## 변경 이유
회원가입 과정의 마찰을 줄이기 위해 소셜 로그인을 추가합니다.

## 주요 변경 파일
- `OAuthController.java` — OAuth2 콜백 처리
- `OAuth2UserService.java` — 사용자 정보 조회 및 저장
- `SecurityConfig.java` — OAuth2 설정 추가

## 테스트 방법
1. 로컬 실행 후 `/oauth2/authorization/google` 접속
2. Google 계정으로 로그인
3. 리다이렉트 후 JWT 토큰 발급 확인

## 관련 이슈
Closes #123

코드 리뷰 — 리뷰어 가이드

코멘트 레이블

의견의 강도를 명확히 표현하면 작성자가 우선순위를 잡을 수 있다.

[MUST] → 반드시 수정 필요. 머지 전 해결.
 예: "NPE 발생 가능 [MUST]"

[SHOULD] → 수정을 강하게 권장. 이유 설명.
 예: "이 로직은 Service로 옮기는 게 좋을 것 같습니다 [SHOULD]"

[OPINION] → 개인 의견. 수정 강제 아님.
 예: "저라면 메서드명을 ~로 했을 것 같아요 [OPINION]"

[QUESTION] → 이해를 위한 질문. 비판 아님.
 예: "여기서 왜 synchronized를 쓰셨나요? [QUESTION]"

[PRAISE] → 잘한 부분 칭찬.
 예: "이 패턴 깔끔하네요! [PRAISE]"

리뷰 에티켓

✅ 코드를 비판하지 말고 개선을 제안한다
 "이건 잘못됐어요" → "이렇게 하면 더 나을 것 같습니다"

✅ 질문형으로 작성한다
 "왜 이렇게 했나요?" → "이렇게 한 이유가 있으신가요?"

✅ 칭찬도 남긴다
 좋은 코드를 보면 [PRAISE]로 표현

✅ 24시간 이내에 리뷰한다
 리뷰가 밀리면 PR 작성자의 컨텍스트도 날아간다

머지 전략

GitHub에서 PR 머지 시 세 가지 방법을 제공한다.

Merge commit
 → 머지 커밋 생성. 브랜치 기록 보존.
 → Git Flow에 적합

Squash and merge
 → 브랜치의 모든 커밋을 하나로 합쳐서 머지
 → 커밋 히스토리 깔끔. GitHub Flow에 적합
 → WIP 커밋이 많아도 괜찮음

Rebase and merge
 → 브랜치 커밋들을 main 위로 rebase 후 머지
 → 선형 히스토리 유지

팀이 하나의 전략을 통일해서 쓰는 게 중요하다. 섞어 쓰면 히스토리가 일관성 없어진다.

Draft PR 활용

완성되지 않았지만 피드백을 받고 싶을 때는 Draft PR로 올린다.

PR 생성 시 "Create draft pull request" 선택
→ 머지 불가 상태
→ 완료되면 "Ready for review"로 전환

“WIP:”, “DO NOT MERGE” 같은 제목 접두사 대신 Draft PR을 쓰는 게 GitHub 표준이다.

다음 편에서는 PR이 머지된 후 릴리즈를 어떻게 관리하는지 다룬다.

Git + Jira — 브랜치·커밋·PR에 이슈 키 연결하기

Sun, 07 Jun 2026 00:00:00 +0900

코드 변경에 이유를 남기는 방법

6개월 전에 작성한 코드를 보면서 “이게 왜 있지?“를 되묻는 경험이 있다면, 이 글이 그 문제를 해결해 준다.

Git 커밋 메시지와 Jira 이슈를 연결하면 코드 한 줄이 어떤 맥락에서 생겼는지 항상 추적할 수 있다.

연동의 핵심: 이슈 키

모든 것은 이슈 키 하나로 연결된다.

이슈 키 형식: {프로젝트 키}-{번호}
예) BLOG-42

이 키를 브랜치명, 커밋 메시지, PR 어디에든 넣으면 Jira가 자동으로 해당 이슈와 연결한다.

브랜치 네이밍

git switch -c feature/BLOG-42-add-comment-api

패턴: {type}/{이슈키}-{설명}

feature/BLOG-42-add-comment-api ← 기능 추가
bugfix/BLOG-37-fix-jwt-expiry ← 버그 수정
refactor/BLOG-55-split-service ← 리팩터링

이슈 키가 앞에 있으면 브랜치 목록에서 어떤 이슈와 연결됐는지 바로 보인다.

커밋 메시지

git commit -m "feat(comment): 댓글 생성 API 구현 BLOG-42"

커밋 끝에 이슈 키를 붙이는 것만으로 Jira가 연결을 감지한다.

조금 더 자세히 쓰고 싶다면:

git commit -m "feat(comment): 댓글 생성 API 구현

- POST /api/comments 엔드포인트 추가
- 댓글 내용 500자 유효성 검증

BLOG-42"

Smart Commits — 커밋 메시지로 Jira 이슈 상태를 자동으로 바꿀 수도 있다.

# 작업 시작 시 이슈를 In Progress로
git commit -m "feat: 댓글 API 작업 시작 BLOG-42 #in-progress"

# 완료 시 Done으로
git commit -m "feat: 댓글 API 완료 BLOG-42 #done"

PR 작성

제목: [BLOG-42] feat(comment): 댓글 생성 API 구현

PR 본문에는 이슈 링크를 추가한다:

## 관련 이슈
- Jira: [BLOG-42](https://your-domain.atlassian.net/browse/BLOG-42)
- Closes BLOG-42

## 변경 내용
- POST /api/comments 엔드포인트 추가
- 댓글 내용 500자 유효성 검증

## 테스트
- [ ] 댓글 생성 정상 응답
- [ ] 빈 내용 검증

Closes BLOG-42를 적으면 PR이 머지될 때 이슈가 자동으로 Done 처리된다.

GitHub for Jira 앱 연동

브랜치·커밋·PR이 Jira 이슈 페이지에서 바로 보이려면 앱 연동이 필요하다.

1. Jira → Apps → 앱 탐색
 → "GitHub for Atlassian" (by Atlassian) 설치

2. GitHub 계정 연결
 → Jira와 다른 구글 계정이어도 무관
 → OAuth 토큰 기반이라 계정 종류 상관없음

3. 연결할 레포 선택 → 승인

연동 후 Jira 이슈 페이지:

Development 패널:
 ├── Branches (1) : feature/BLOG-42-add-comment-api
 ├── Commits (3) : 관련 커밋 목록
 └── Pull Requests : [Open] 댓글 생성 API

이슈 하나에서 관련 코드 변경 전체를 볼 수 있다.

실전 워크플로우 요약

1. Jira에서 이슈 생성 → BLOG-42
2. 브랜치 생성 → feature/BLOG-42-add-comment-api
3. 커밋 → "feat: 구현 BLOG-42"
4. PR → [BLOG-42] feat: 댓글 API / Closes BLOG-42
5. 머지 → 이슈 자동 Done

혼자 쓸 때는 이 흐름을 다 지키기보다 브랜치명 + 커밋에 이슈 키만 챙겨도 충분하다. 나중에 git log에서 이슈 키로 검색하면 그 작업의 전체 맥락을 찾을 수 있다.

다음 편에서는 Slack과 연동해서 Jira + GitHub 알림을 한 곳에 모으는 방법을 다룬다.

커밋 메시지를 잘 쓴다는 것 — Conventional Commits 실전 가이드

Sat, 06 Jun 2026 00:00:00 +0900

git log에 남는 것들

git log --oneline

a3f21c9 수정
b12e8f1 fix
c94d3a2 asdf
d77f0e1 작업 완료
e23b1c7 ㅁㄴㅇ

6개월 전 내가 쓴 커밋들이다. 뭘 고쳤는지, 왜 고쳤는지 전혀 알 수 없다. 커밋 메시지는 코드의 히스토리이고, 미래의 나(또는 동료)에게 보내는 메모다.

Conventional Commits 형식

<type>(<scope>): <subject>

[optional body]

[optional footer]

# 실제 예시
feat(auth): Google OAuth2 소셜 로그인 추가

기존 이메일/비밀번호 로그인과 병행 사용 가능.
Google Cloud Console에서 OAuth 앱 등록 필요.

Closes #123

type 종류

type	언제 쓰나	버전 영향
`feat`	새 기능 추가	Minor ↑
`fix`	버그 수정	Patch ↑
`refactor`	리팩터링 (기능 변화 없음)	없음
`test`	테스트 추가/수정	없음
`docs`	문서 변경	없음
`style`	코드 포맷팅 (로직 무변화)	없음
`chore`	빌드, 패키지, CI 설정	없음
`perf`	성능 개선	Patch ↑

좋은 커밋 메시지의 조건

제목은 50자 이하, 명령형으로

# ✅ 좋음
feat(order): 주문 취소 API 추가
fix(auth): 로그아웃 후 토큰 무효화 안 되는 버그 수정

# ❌ 나쁨
feat(order): 주문 취소 기능을 구현했습니다 (과거형, 너무 김)
fixed bug (type 없음, 뭘 고쳤는지 모름)

body는 “왜"를 설명한다

refactor(payment): 결제 전략 패턴으로 분리

기존 PaymentService에 if/else로 결제 수단이 추가될 때마다
코드 수정이 필요했음. 전략 패턴 도입으로 OCP 달성.
새 결제 수단 추가 시 PaymentStrategy 구현체만 추가하면 됨.

what(무엇을 바꿨는가)은 코드 diff를 보면 안다. body에는 **why(왜 바꿨는가)**를 쓴다.

Breaking Change

하위 호환성이 깨지는 변경은 반드시 명시한다.

feat!: 사용자 API 응답 형식 변경

BREAKING CHANGE: userId 필드가 id로 변경됨.
기존 클라이언트는 필드명 수정 필요.

feat!의 !가 Breaking Change를 의미한다. SemVer에서 Major 버전 업 트리거.

커밋 단위 원칙

하나의 커밋 = 하나의 목적

# ✅ 좋음 — 목적이 명확한 단위
git commit -m "feat(user): 회원가입 엔티티 추가"
git commit -m "feat(user): 회원가입 서비스 로직 구현"
git commit -m "feat(user): 회원가입 API 엔드포인트 추가"
git commit -m "test(user): 회원가입 서비스 단위 테스트"

# ❌ 나쁨 — 여러 목적이 섞임
git commit -m "회원가입 기능 구현 및 버그 수정 및 테스트"

WIP 커밋 처리

작업 중간에 저장해야 할 때는 WIP 커밋을 만들고, PR 전에 정리한다.

# 작업 중 임시 저장
git commit -m "WIP: 결제 API 작업 중"

# PR 전에 squash로 깔끔하게 정리
git rebase -i HEAD~3
# WIP 커밋들을 squash해서 하나로 합치기

squash는 이 시리즈 마지막 편(고급 명령어)에서 다룬다.

CHANGELOG 자동 생성

Conventional Commits 형식을 지키면 CHANGELOG를 자동 생성할 수 있다.

# conventional-changelog 설치
npm install -g conventional-changelog-cli

# CHANGELOG.md 생성
conventional-changelog -p angular -i CHANGELOG.md -s

# CHANGELOG

## [1.3.0] - 2026-06-04

### Features
- **auth**: Google OAuth2 소셜 로그인 추가 (#123)
- **order**: 주문 취소 API 추가 (#124)

### Bug Fixes
- **auth**: 로그아웃 후 토큰 무효화 버그 수정 (#125)

커밋 메시지 하나하나가 릴리즈 노트가 된다. 다음 편에서는 이 커밋들을 담는 PR을 잘 쓰는 법을 다룬다.

팀 Git의 시작 — 브랜칭 전략, Git Flow vs GitHub Flow 언제 뭘 쓰나

Thu, 04 Jun 2026 00:00:00 +0900

브랜치 전략이 없으면 생기는 일

main에 직접 push하다가 배포 직전에 미완성 코드가 섞인다. 두 사람이 같은 파일을 수정해서 충돌이 쏟아진다. 버그를 고쳤는데 어디서 배포된 건지 모른다.

브랜칭 전략은 이런 혼돈을 막는 팀이 동의한 브랜치 운영 규칙이다.

브랜치 역할 이해

어떤 전략이든 기본 개념은 같다.

main
 → 항상 배포 가능한 상태. 직접 push 금지.

feature/xxx
 → 기능 하나를 개발하는 브랜치
 → 완료 후 PR로 main 또는 develop에 머지

hotfix/xxx
 → 운영 중 긴급 버그 수정
 → main에서 바로 생성, 수정 후 즉시 배포

Git Flow — 체계적인 릴리즈 관리

Vincent Driessen이 제안한 전략. 브랜치 종류가 많고 릴리즈 사이클이 명확하다.

main ─────────────────────────────── 배포 완료 버전
 ↑ merge ↑ merge
 release/1.2 hotfix/1.1.1
 ↑
develop ─────────────────────────── 다음 릴리즈 통합
 ↑ merge ↑ merge
feature/login feature/payment

흐름

# 기능 개발
git checkout develop
git checkout -b feature/user-auth
# ... 개발 ...
git checkout develop
git merge --no-ff feature/user-auth # 머지 커밋 강제 생성
git branch -d feature/user-auth

# 릴리즈 준비
git checkout -b release/1.2.0 develop
# 버전 번호 변경, QA 수정
git checkout main && git merge --no-ff release/1.2.0
git tag -a v1.2.0 -m "Release 1.2.0"
git checkout develop && git merge --no-ff release/1.2.0

적합한 상황

✅ 릴리즈 주기가 정해진 서비스 (앱 스토어, 패키지 배포)
✅ QA 기간이 별도로 필요한 경우
✅ 여러 버전을 동시에 유지해야 하는 경우
❌ 매일 배포하는 웹 서비스 → 브랜치가 너무 복잡

GitHub Flow — 단순하고 빠른 배포

main 하나 + feature 브랜치. 머지 즉시 배포.

main ─────────────────────────── 항상 배포됨
 ↑ PR merge ↑ PR merge
feature/login feature/cart

흐름

# main에서 바로 feature 브랜치 생성
git checkout main && git pull
git checkout -b feature/add-comment

# 개발 후 PR 생성 → 리뷰 → 머지
# 머지 즉시 main으로 배포

적합한 상황

✅ 웹 서비스, SaaS — 지속적 배포(CD) 환경
✅ 소규모 팀
✅ 빠른 피드백과 반복이 중요한 경우
❌ 릴리즈 관리가 복잡한 경우

Trunk-based Development — 최소한의 브랜치

모든 개발자가 main(trunk)에 직접 또는 짧은 수명의 브랜치로 자주 통합.

main ────────────────── 모든 것이 여기로
 ↑ ↑ ↑
feature feature feature
(1~2일 이내 수명)

Feature Flag로 미완성 기능을 숨겨두고 main에 merge한다.

if (featureFlags.isEnabled("new-payment")) {
 // 새 결제 로직
} else {
 // 기존 로직
}

✅ CI/CD가 완벽히 갖춰진 팀
✅ 테스트 커버리지가 높은 경우
❌ 테스트 없이 쓰면 main이 자주 깨짐

전략 선택 기준

	Git Flow	GitHub Flow	Trunk-based
배포 주기	주기적 릴리즈	수시 배포	하루 여러 번
팀 규모	중~대규모	소~중규모	성숙한 팀
CI/CD	선택	권장	필수
복잡도	높음	낮음	낮음

현실적인 조언: 처음 팀에 합류하면 GitHub Flow부터 익히자. 대부분의 스타트업과 웹 서비스 팀이 쓴다. Git Flow는 배포 주기가 정해진 팀에서 만나게 된다.

브랜치 네이밍 컨벤션

어떤 전략이든 이름 규칙은 통일하는 게 좋다.

feature/PROJ-42-add-login ← 기능 추가
bugfix/PROJ-37-fix-jwt ← 버그 수정
hotfix/PROJ-61-null-pointer ← 긴급 수정
refactor/PROJ-55-split-svc ← 리팩터링
chore/PROJ-70-update-deps ← 의존성 등

이슈 키를 브랜치명에 포함하면 Jira와 자동 연동된다. 다음 편에서는 커밋 메시지 컨벤션을 다룬다.