Git Flow

Posted Feb 1, 2019

By Hyoeun Choi

13 min read

Git Flow

[Git] Starting a Team Project: Branch Strategy to Separate Dev and Prod Environments (Git Flow)

When developing solo, the single main branch was enough. However, things change when you move to a team environment and need to separate the Development Environment (Dev) from the Production Environment (Prod).

To avoid nightmares like “It works on my local but breaks on the server” or “Did someone overwrite the production code?”, we’ve organized and shared the Git Branch Strategy and Collaboration Workflow our team has adopted.

1. Core Strategy: Branch Segregation by Environment

We have streamlined the most popular and stable Git Flow method to suit our team’s needs. The core idea is managing two primary branches by mapping them 1:1 with the server environments.

Main (Master) Branch = Production Env

Purpose: Used for deploying to the Production Server (Prod) used by real users.
Characteristics: Must always be in a deployable state. Only the most stable code exists here.
Rule: Absolutely no direct Pushes. Updates only occur by Merging code that is ready for release.

Develop Branch = Development Env

Purpose: Used for deploying to the Development Server (Dev) where developers’ code is integrated.
Characteristics: Features for the next release are integrated here. QA and testing take place in this branch.
Rule: Individual feature work is merged into this branch upon completion.

2. Scenario-Specific Workflow

Here are the Git commands and flow for the three situations you’ll encounter in actual work.

Case A. Developing a New Feature

This is the most frequent scenario. All work is based on the develop branch.

Create Branch: Fetch the latest code from develop and branch off.

git checkout develop
git pull origin develop
git checkout -b feature/login-page  # Use clear feature naming

Work and Push: Commit freely and push to the remote repository (GitHub).

git commit -m "Feat: Complete login UI implementation"
git push origin feature/login-page

Pull Request (PR): Create a PR on GitHub from feature/login-page → develop. Merge once team review is complete and approved.

Case B. Deploying to the Production Server (Release)

Testing on the develop server is complete, and it’s time to showcase it to customers.

Create Release PR: Submit a PR to merge the content of the develop branch into the main branch.
Final Review: Team members perform a final check of the changes before merging.
Automated Deployment: (If CI/CD is set up) The moment code is merged into main, it is deployed to the Production Server.

Case C. Critical Bug in the Production Server (Hotfix)

To prevent mixing with ongoing development (develop), the fix must happen directly from main.

Create Branch: Branch directly from the problematic main branch.

git checkout main
git pull origin main
git checkout -b hotfix/payment-error

Fix and Deploy: After fixing, send a PR directly to main and deploy.
Crucial: This fix must be reflected in the develop branch as well. (Otherwise, the bug will reappear in the next release!)
- After merging to main, merge the hotfix branch into the develop branch too.

3. Essential Settings for Secure Collaboration (Rules)

Since people are prone to error, it’s best to enforce these rules using the GitHub system and clear team conventions.

A. Branch Protection Rules

Set this up in the GitHub repository’s Settings > Branches menu.
Check ‘Require a pull request before merging’ for both main and develop branches to prevent direct pushes and enforce PRs.
Ensure that merges are impossible without Code Review Approval to guarantee code quality.

B. Commit Message Rules

Commit messages are not just simple records; they are a critical tool for quickly grasping a project’s history and aiding automation (Semantic Release).

1. Adopting Conventional Commits

Follow Conventional Commits, the most widely used standard. The first line of the message is structured as type(scope): subject.

Recommended Commit Types

Type	Meaning	Example
feat	New feature	`feat: add login API endpoint`
fix	Bug fix	`fix: correct balance error in payment module`
docs	Documentation changes	`docs: fix typo in README file`
style	Code formatting, semicolons, etc. (no logic change)	`style: unify spacing in function declarations`
refactor	Code restructuring (no functional change)	`refactor: split utility functions into separate file`
test	Add/modify tests	`test: add unit tests for main page component`
chore	Build settings, library updates, etc. (non-code related)	`chore: update webpack version`

2. Best Practice Principles

Use Imperative Mood: Write using the present tense imperative (Add function), not past tense (Added function).
- Bad: Fixed login bug
- Good: fix: resolve bug occurring during login attempt
Limit Subject Length: Keep the first line concise, preferably within 50–72 characters, for easy viewing.
Separate Subject and Body: If detailed explanation is needed, separate the subject from the body with a blank line. Use the body to detail what was changed and why (the motivation for the change).
Reference Issue Numbers: If using a tracking system like Jira or GitHub Issues, link the change history by referencing the issue number at the end of the commit message in the format Closes #123 or [JIRA-456].

[Git] 팀 프로젝트의 시작: Dev와 Prod 환경을 분리하는 브랜치 전략 (Git Flow)

혼자 개발할 때는 main 브랜치 하나만 있어도 충분했습니다. 하지만 팀 단위로 넘어가고,개발 환경(Dev)**과운영 환경(Prod)**을 분리해야 하는 시점이 오면 이야기가 달라집니다.

“내 로컬에서는 잘 되는데 서버에 올리니까 안 돼요”, “누가 운영 서버 코드를 덮어썼나요?” 같은 악몽을 피하기 위해, 우리 팀이 도입하기로 한 Git 브랜치 전략과 협업 워크플로우를 정리해 공유합니다.

1. 핵심 전략: 환경에 따른 브랜치 이원화

가장 대중적이고 안정적인 Git Flow 방식을 우리 팀 상황에 맞춰 경량화했습니다. 핵심은 두 개의 주요 브랜치를 서버 환경과 1:1로 매핑하여 관리하는 것입니다.

Main (Master) Branch = Production Env

용도: 실제 사용자가 사용하는 운영 서버(Prod) 배포용입니다.
특징: 언제나 배포 가능한 상태여야 합니다. 가장 안정적인 코드만 존재합니다.
규칙: 직접 Push 절대 금지. 오직 배포 준비가 끝난 코드를 Merge하는 방식으로만 업데이트합니다.

Develop Branch = Development Env

용도: 개발자들의 코드가 모이는 개발 서버(Dev) 배포용입니다.
특징: 다음 배포를 위한 기능들이 이곳에 통합됩니다. QA 및 테스트가 이루어지는 곳입니다.
규칙: 각자의 기능(Feature) 작업이 끝나면 이곳으로 합쳐집니다.

2. 실전 시나리오별 워크플로우 (Workflow)

실제 업무에서 마주하게 될 3가지 상황별 Git 명령어와 흐름입니다.

Case A. 새로운 기능을 개발할 때 (Feature)

가장 빈번하게 일어나는 상황입니다. develop 브랜치를 기준으로 작업합니다.

브랜치 생성: develop에서 최신 코드를 받아와 새 가지를 칩니다.

git checkout develop
git pull origin develop
git checkout -b feature/login-page  # 기능명 명확히

작업 및 Push: 자유롭게 커밋하고 원격 저장소에 올립니다.

git commit -m "Feat: 로그인 UI 구현 완료"
git push origin feature/login-page

Pull Request (PR): GitHub에서 feature/login-page → develop으로 PR을 생성합니다. 팀원 리뷰 후 승인되면 Merge 합니다.

Case B. 운영 서버에 배포할 때 (Release)

develop 서버에서 테스트가 끝났고, 이제 고객에게 선보일 차례입니다.

배포 PR 생성: develop 브랜치의 내용을 main 브랜치로 합치는 PR을 올립니다.
최종 확인: 팀원들이 마지막으로 변경 사항을 확인하고 Merge 합니다.
자동 배포: (CI/CD가 구축되어 있다면) main에 코드가 합쳐지는 순간 운영 서버로 배포됩니다.

Case C. 운영 서버에서 긴급 버그가 터졌을 때 (Hotfix)

개발 중인 기능(develop)과 섞이지 않게, main에서 바로 수정해야 합니다.

브랜치 생성: 문제가 발생한 main에서 바로 가지를 칩니다.

git checkout main
git pull origin main
git checkout -b hotfix/payment-error

수정 및 배포: 수정 후 main으로 바로 PR을 보내 배포합니다.
중요: 이 수정 사항은 develop 브랜치에도 반드시 반영해줘야 합니다. (안 그러면 다음 배포 때 버그가 부활합니다!)
- main에 병합 후, hotfix 브랜치를 develop 브랜치에도 병합합니다.

3. 안전한 협업을 위한 필수 설정 (Rule)

사람은 실수를 할 수밖에 없기 때문에, GitHub 시스템으로 강제하고 규칙을 만드는 것이 좋습니다.

A. 브랜치 보호 규칙 (Branch Protection Rules)

GitHub 저장소의 Settings > Branches 메뉴에서 설정합니다.
main과 develop 브랜치에 대해**‘Require a pull request before merging’**을 체크하여 직접 푸시를 금지하고 PR을 강제합니다.
코드 리뷰 승인(Approve)이 없이는 병합할 수 없도록 설정하여 코드 품질을 확보합니다.

B. 커밋 메시지 규칙 (Commit Message Rules)

커밋 메시지는 단순한 기록이 아니라, 프로젝트의 변경 이력을 한눈에 파악하고 자동화(Semantic Release)를 돕는 핵심 도구입니다.

1. Conventional Commits 도입

가장 널리 쓰이는 표준인 Conventional Commits를 따릅니다. 메시지의 첫 줄은 타입(스코프): 제목 형태로 작성합니다.

추천하는 커밋 타입

타입 (Type)	의미	예시
feat	새로운 기능 추가 (Feature)	`feat: 로그인 API 추가`
fix	버그 수정 (Bug Fix)	`fix: 결제 모듈 잔액 오류 수정`
docs	문서 수정 (Documentation)	`docs: README 파일 오타 수정`
style	코드 포맷, 세미콜론 등 (로직 변경 없음)	`style: 함수 선언 시 띄어쓰기 통일`
refactor	코드 리팩토링 (기능 변경 없음)	`refactor: 유틸 함수 파일 분리`
test	테스트 코드 추가/수정	`test: 메인 페이지 컴포넌트 테스트 추가`
chore	빌드 설정, 라이브러리 업데이트 등 (코드와 무관)	`chore: webpack 버전 갱신`

2. Best Practice 원칙

명령형(Imperative) 사용: 과거형(Added function)이 아닌 현재형 명령문(Add function)으로 작성합니다.
- Bad: 로그인 버그 수정했음
- Good: fix: 로그인 시도 시 발생하는 버그 수정
제목 길이 제한: 첫 줄은 50~72자 이내로 간결하게 작성하여 한눈에 파악할 수 있도록 합니다.
제목과 본문 분리: 자세한 설명이 필요하다면 제목과 본문을 한 줄 띄어 분리하고, 본문에 무엇을 변경했고 왜 변경했는지(변경의 동기)를 상세히 작성합니다.
Issue 번호 참조: Jira, GitHub Issue 등 트래킹 시스템이 있다면, 커밋 메시지 마지막에 Closes #123 또는 [JIRA-456] 형식으로 참조하여 변경 이력을 연결합니다.

Development, Git

Git Collaborate

This post is licensed under CC BY 4.0 by the author.

[Git] Starting a Team Project: Branch Strategy to Separate Dev and Prod Environments (Git Flow)

1. Core Strategy: Branch Segregation by Environment

Main (Master) Branch = Production Env

Develop Branch = Development Env

2. Scenario-Specific Workflow

Case A. Developing a New Feature

Case B. Deploying to the Production Server (Release)

Case C. Critical Bug in the Production Server (Hotfix)

3. Essential Settings for Secure Collaboration (Rules)

A. Branch Protection Rules

B. Commit Message Rules

1. Adopting Conventional Commits

2. Best Practice Principles

[Git] 팀 프로젝트의 시작: Dev와 Prod 환경을 분리하는 브랜치 전략 (Git Flow)

1. 핵심 전략: 환경에 따른 브랜치 이원화

Main (Master) Branch = Production Env

Develop Branch = Development Env

2. 실전 시나리오별 워크플로우 (Workflow)

Case A. 새로운 기능을 개발할 때 (Feature)

Case B. 운영 서버에 배포할 때 (Release)

Case C. 운영 서버에서 긴급 버그가 터졌을 때 (Hotfix)

3. 안전한 협업을 위한 필수 설정 (Rule)

A. 브랜치 보호 규칙 (Branch Protection Rules)

B. 커밋 메시지 규칙 (Commit Message Rules)

1. Conventional Commits 도입

2. Best Practice 원칙

Trending Tags