2026-01-18 | 9 min read | 190 | git gitflow 실습 고급

4-3. Git의 workflow: Gitflow 실습

1. Gitflow의 재조명: 왜 Gitflow인가?

Gitflow는 Git을 활용한 브랜치 관리 전략 중 하나로, 소프트웨어 개발 과정에서 코드의 안정성과 협업 효율성을 극대화하기 위해 고안되었습니다. Gitflow는 단순히 명령어 집합이 아닌, 일련의 규칙과 절차를 통해 개발팀이 코드 변경 사항을 체계적으로 관리하고, 릴리스 프로세스를 자동화할 수 있도록 돕는 프레임워크입니다.

Gitflow가 등장하기 전에는, 개발팀은 주로 단일 main 브랜치 또는 간단한 feature 브랜치 기반의 워크플로우를 사용했습니다. 이러한 방식은 규모가 작거나 단순한 프로젝트에서는 괜찮았지만, 프로젝트가 복잡해지고 여러 팀원이 동시에 작업하게 되면서 다음과 같은 문제점에 직면했습니다.

잦은 충돌: 여러 개발자가 동일한 파일을 수정하면서 발생하는 병합 충돌은 개발 속도를 늦추고, 통합 과정에서 많은 시간과 노력을 소모하게 합니다.
불안정한 릴리스: 릴리스를 준비하는 과정에서 예상치 못한 버그가 발생하거나, 이전 버전과의 호환성 문제가 생길 가능성이 높았습니다.
복잡한 롤백: 릴리스 후 치명적인 버그가 발견될 경우, 이전 상태로 롤백하는 과정이 복잡하고 위험했습니다.

Gitflow는 이러한 문제점을 해결하기 위해 특정 목적을 가진 여러 개의 브랜치를 활용하여 개발, 릴리스, 유지보수 과정을 세분화하고, 각 단계별로 명확한 역할을 부여했습니다. Gitflow는 이러한 구조를 통해 코드의 안정성을 높이고, 릴리스 주기를 단축하며, 협업 효율성을 향상시키는 것을 목표로 합니다.

2. Gitflow의 핵심 브랜치 구조: 영원한 브랜치

Gitflow는 크게 두 가지 유형의 브랜치를 사용합니다.

영원한 브랜치(Permanent Branches): 프로젝트의 수명과 함께 유지되며, 지속적으로 관리되는 브랜치입니다.
- main 브랜치: 가장 안정적인 코드를 포함하며, 제품으로 릴리스될 수 있는 상태의 코드를 관리합니다. main 브랜치는 항상 최신 릴리스 버전을 가리키며, tag를 사용하여 특정 릴리스 버전을 표시합니다.
- develop 브랜치: main 브랜치로부터 파생되며, 개발의 중심지점 역할을 합니다. 각 기능 개발이 완료되면 feature 브랜치로부터 병합되고, 릴리스 준비가 완료되면 release 브랜치로 병합됩니다.
영원한 브랜치는 프로젝트의 핵심적인 코드 흐름을 관리하며, 코드의 안정성을 유지하는 데 중요한 역할을 합니다. main 브랜치는 릴리스 가능한 코드만을 포함하므로, 언제든지 배포 가능한 상태를 유지합니다. develop 브랜치는 각 기능 개발 브랜치들의 통합 지점으로, 지속적인 통합(Continuous Integration)을 가능하게 합니다.
보조 브랜치(Supporting Branches): 특정 작업을 위해 일시적으로 생성되고, 작업 완료 후 삭제되는 브랜치입니다.
- feature 브랜치: 새로운 기능을 개발할 때 develop 브랜치로부터 파생됩니다. 각 기능 개발이 완료되면 develop 브랜치로 병합됩니다.
- release 브랜치: 릴리스를 준비하기 위해 develop 브랜치로부터 파생됩니다. 릴리스 버그 수정 및 최종 테스트를 거친 후 main 브랜치와 develop 브랜치로 병합됩니다. release 브랜치는 릴리스 준비 과정에서 발생하는 버그 수정과 관련된 코드를 격리하여, develop 브랜치의 안정성을 유지하는 역할을 합니다.
- hotfix 브랜치: 이미 릴리스된 버전에 긴급한 버그 수정이 필요할 때 main 브랜치로부터 파생됩니다. 버그 수정 후 main 브랜치와 develop 브랜치로 병합됩니다.
보조 브랜치는 특정 목적을 위한 작업을 독립적으로 수행할 수 있도록 돕습니다. feature 브랜치는 새로운 기능 개발을, release 브랜치는 릴리스 준비를, hotfix 브랜치는 긴급한 버그 수정을 담당합니다. 이러한 보조 브랜치를 활용하면, 각 작업의 독립성을 보장하고, 코드의 안정성을 유지하면서도 유연한 개발을 가능하게 합니다.

3. Gitflow 워크플로우: 단계별 실전 가이드

Gitflow 워크플로우는 각 브랜치의 역할과 상호작용을 정의하여, 개발 과정 전체를 체계적으로 관리합니다. 다음은 Gitflow 워크플로우의 주요 단계입니다.

1) 기능 개발 (Feature Development)

각 기능 개발은 develop 브랜치로부터 파생된 feature 브랜치에서 시작합니다.

```bash git checkout develop git checkout -b feature/feature-name

기능 개발...

git add . git commit -m "feat: implement feature-name" git push origin feature/feature-name ```

기능 개발이 완료되면, develop 브랜치로 병합합니다.

bash git checkout develop git merge --no-ff feature/feature-name git push origin develop git branch -d feature/feature-name

--no-ff 옵션은 병합 시 "Non-Fast Forward" 병합을 수행하여, 병합 기록을 명확하게 남깁니다.

2) 릴리스 준비 (Release Preparation)

develop 브랜치가 릴리스 준비 단계에 도달하면, develop 브랜치로부터 release 브랜치를 생성합니다. bash git checkout develop git checkout -b release/1.0.0
release 브랜치에서 릴리스 버그 수정, 릴리스 관련 메타데이터 업데이트 (버전 정보, 릴리스 노트 등)를 수행합니다. bash # 릴리스 버그 수정 및 준비 git add . git commit -m "fix: bug fixes for release 1.0.0" git push origin release/1.0.0
릴리스 준비가 완료되면, release 브랜치를 main 브랜치와 develop 브랜치로 병합합니다. bash git checkout main git merge --no-ff release/1.0.0 git tag -a 1.0.0 -m "Release version 1.0.0" # 릴리스 태깅 git push origin main git push origin --tags git checkout develop git merge --no-ff release/1.0.0 git push origin develop git branch -d release/1.0.0

main 브랜치로 병합 후, 반드시 릴리스 버전을 태깅합니다. 이 태그는 특정 릴리스 버전을 쉽게 식별하고, 필요시 해당 버전으로 롤백하는 데 사용됩니다. develop 브랜치로도 병합하여, 릴리스 관련 변경 사항을 develop 브랜치에 반영합니다.

3) 긴급 수정 (Hotfix)

main 브랜치에서 버그가 발견되면, main 브랜치로부터 hotfix 브랜치를 생성합니다. bash git checkout main git checkout -b hotfix/1.0.1
hotfix 브랜치에서 버그를 수정합니다. bash # 버그 수정 git add . git commit -m "fix: critical bug fix" git push origin hotfix/1.0.1
버그 수정이 완료되면, hotfix 브랜치를 main 브랜치와 develop 브랜치로 병합합니다. bash git checkout main git merge --no-ff hotfix/1.0.1 git tag -a 1.0.1 -m "Hotfix for version 1.0.1" # 핫픽스 태깅 git push origin main git push origin --tags git checkout develop git merge --no-ff hotfix/1.0.1 git push origin develop git branch -d hotfix/1.0.1

hotfix 브랜치를 main 브랜치로 병합한 후, 반드시 핫픽스 버전을 태깅합니다. develop 브랜치로도 병합하여, 버그 수정 사항을 develop 브랜치에 반영합니다.

4. Gitflow 실습: 실제 프로젝트에 적용하기

Gitflow를 실제 프로젝트에 적용하기 위한 실습을 진행합니다. 다음은 실습을 위한 예시 시나리오입니다.

1) 프로젝트 초기 설정

새로운 Git 저장소를 초기화하거나, 기존 저장소를 활용합니다. bash git init # or git clone [repository URL]
.gitignore 파일을 생성하여 불필요한 파일을 관리합니다. (예: node_modules, build 폴더 등)

2) 기능 개발 (Feature Development)

develop 브랜치를 기반으로 새로운 feature 브랜치를 생성합니다. bash git checkout develop git checkout -b feature/add-login-feature
feature/add-login-feature 브랜치에서 새로운 로그인 기능을 개발하고, 변경 사항을 커밋합니다. bash # 로그인 기능 구현 git add . git commit -m "feat: implement login feature" git push origin feature/add-login-feature
기능 개발이 완료되면, develop 브랜치로 병합합니다. (Pull Request를 활용하는 것이 좋습니다.) bash git checkout develop git merge --no-ff feature/add-login-feature git push origin develop git branch -d feature/add-login-feature

3) 릴리스 준비 (Release Preparation)

develop 브랜치가 릴리스 준비 단계에 도달하면, develop 브랜치로부터 release 브랜치를 생성합니다. bash git checkout develop git checkout -b release/1.0.0
release/1.0.0 브랜치에서 릴리스 버그 수정 및 버전을 업데이트합니다. bash # 릴리스 버그 수정 git add . git commit -m "fix: bug fixes for release 1.0.0" # 버전 업데이트 git add . git commit -m "chore: update version to 1.0.0" git push origin release/1.0.0
릴리스 준비가 완료되면, release/1.0.0 브랜치를 main 브랜치와 develop 브랜치로 병합합니다. bash git checkout main git merge --no-ff release/1.0.0 git tag -a 1.0.0 -m "Release version 1.0.0" git push origin main git push origin --tags git checkout develop git merge --no-ff release/1.0.0 git push origin develop git branch -d release/1.0.0

4) 긴급 수정 (Hotfix)

main 브랜치에서 치명적인 버그가 발견되면, main 브랜치로부터 hotfix 브랜치를 생성합니다. bash git checkout main git checkout -b hotfix/1.0.1
hotfix/1.0.1 브랜치에서 버그를 수정합니다. bash # 버그 수정 git add . git commit -m "fix: critical bug fix" git push origin hotfix/1.0.1
버그 수정이 완료되면, hotfix/1.0.1 브랜치를 main 브랜치와 develop 브랜치로 병합합니다. bash git checkout main git merge --no-ff hotfix/1.0.1 git tag -a 1.0.1 -m "Hotfix for version 1.0.1" git push origin main git push origin --tags git checkout develop git merge --no-ff hotfix/1.0.1 git push origin develop git branch -d hotfix/1.0.1

위 실습 단계를 통해 Gitflow의 핵심 개념과 워크플로우를 직접 경험하고, 실제 프로젝트에 적용하는 방법을 익힐 수 있습니다.

5. Gitflow의 장단점 및 고려 사항

Gitflow는 강력한 브랜치 관리 전략이지만, 모든 프로젝트에 적합한 것은 아닙니다. Gitflow를 사용하기 전에 장단점을 충분히 이해하고, 프로젝트의 특성에 맞게 적용해야 합니다.

1) 장점

코드의 안정성 향상: main 브랜치와 develop 브랜치를 통해, 릴리스 가능한 코드와 개발 중인 코드를 명확하게 분리하여 코드의 안정성을 높입니다.
협업 효율성 증대: 각 기능 개발을 feature 브랜치에서 독립적으로 수행하고, 릴리스 준비, 긴급 수정을 위한 별도의 브랜치를 활용하여, 여러 개발자가 동시에 작업하는 환경에서 충돌을 최소화하고 협업 효율성을 높입니다.
유연한 릴리스 관리: release 브랜치와 tag를 사용하여 릴리스 프로세스를 세분화하고, 롤백 및 유지보수를 용이하게 합니다.
체계적인 워크플로우: Gitflow는 명확한 브랜치 구조와 워크플로우를 제공하여, 개발팀이 코드 변경 사항을 체계적으로 관리하고, 릴리스 주기를 예측 가능하게 만듭니다.

2) 단점

브랜치 관리 복잡성 증가: Gitflow는 여러 개의 브랜치를 사용하므로, 브랜치 관리 및 병합 과정이 복잡해질 수 있습니다. 특히, Git에 익숙하지 않은 개발자에게는 학습 곡선이 필요합니다.
작은 프로젝트에 비효율적: 소규모 프로젝트에서는 Gitflow의 복잡성이 오히려 개발 속도를 늦출 수 있습니다.
병합 충돌 발생 가능성: 여러 개발자가 동시에 develop 브랜치에 기능을 병합하는 경우, 병합 충돌이 발생할 수 있습니다.

3) 고려 사항

프로젝트 규모: Gitflow는 대규모 프로젝트 또는 여러 개발자가 협업하는 프로젝트에 적합합니다. 소규모 프로젝트의 경우, Gitflow의 복잡성이 오히려 비효율적일 수 있습니다.
개발팀의 Git 숙련도: Gitflow는 Git에 대한 기본적인 이해를 필요로 합니다. 개발팀의 Git 숙련도가 낮을 경우, Gitflow를 도입하기 전에 충분한 교육과 연습이 필요합니다.
지속적인 통합 및 배포(CI/CD) 환경: Gitflow는 CI/CD 환경과 함께 사용하면 더욱 효과적입니다. CI/CD 파이프라인을 구축하여, 자동화된 테스트, 빌드, 배포를 수행하면, 릴리스 프로세스를 더욱 효율적으로 관리할 수 있습니다.

6. Gitflow 활용 팁과 트러블 슈팅

Gitflow를 효과적으로 활용하기 위한 팁과 발생 가능한 트러블 슈팅에 대한 정보를 제공합니다.

1) Gitflow 활용 팁

Pull Request(PR) 활용: feature, release, hotfix 브랜치를 develop 또는 main 브랜치로 병합하기 전에, 반드시 PR을 생성하여 코드 리뷰를 진행합니다. 코드 리뷰를 통해 코드 품질을 향상시키고, 잠재적인 버그를 미리 발견할 수 있습니다.
CI/CD 파이프라인 구축: CI/CD 파이프라인을 구축하여, 자동화된 테스트, 빌드, 배포를 수행합니다. 이를 통해 릴리스 프로세스를 자동화하고, 릴리스 주기를 단축할 수 있습니다.
자동화 도구 활용: Gitflow를 자동화하는 도구를 활용하여, 브랜치 생성, 병합, 릴리스 프로세스를 간소화합니다. 예를 들어, git flow 명령어를 사용하거나, Git GUI 툴을 활용할 수 있습니다.
커밋 메시지 규칙 준수: 일관된 커밋 메시지 규칙을 준수하여, 코드 변경 사항을 명확하게 기록합니다. 이를 통해 코드 변경 내역을 쉽게 파악하고, 문제 발생 시 빠르게 해결할 수 있습니다.
정기적인 브랜치 정리: 불필요한 브랜치를 삭제하고, 오래된 브랜치를 정리하여, 저장소를 깔끔하게 유지합니다.

2) 트러블 슈팅

병합 충돌 해결: 병합 충돌이 발생하면, 충돌을 해결하기 위해 수동으로 코드를 수정해야 합니다. 충돌 해결 후, 변경 사항을 커밋하고 병합을 다시 시도합니다.
잘못된 병합: 잘못된 브랜치를 병합한 경우, git revert 명령어를 사용하여 해당 병합을 되돌릴 수 있습니다.
릴리스 관련 문제: 릴리스 과정에서 문제가 발생하면, 롤백하거나 핫픽스 브랜치를 생성하여 문제를 해결합니다.
Gitflow 명령어 오류: git flow 명령어 사용 시 오류가 발생하면, 해당 명령어의 문법을 다시 확인하고, 관련 문서를 참조합니다.
저장소 동기화 문제: 원격 저장소와의 동기화 문제가 발생하면, git pull 및 git push 명령어를 사용하여 로컬 저장소와 원격 저장소를 동기화합니다.