Page/area: Capgo marketing website. Role: Short UI label or navigation item. Seen in: component BlogAuthorByline.astro. Message key `content_marketer` (Content Marketer). Git Flow Git Flow와 트렁크 기반 개발 사이에 선택하는 것은 CI/CD 워크플로우에 큰 영향을 미칠 수 있습니다. 여기서 빠른 요약을 제공합니다.
- Git FlowGit Flow
main,develop,feature,release, andhotfixGit Flow는 여러 branch를 사용하여 버전 관리를 하며, 대형 팀, 느린 릴리스 주기 및 엄격한 QA 프로세스를 위한 것입니다. - 트리크 기반 개발: 단일 메인 branch에 초점을 맞추고, 짧은 수명 feature branches를 사용합니다. 작은 팀, 빠른 릴리즈, 강력한 자동화 테스트에 적합합니다.
빠른 비교:
| Aspect | Git Flow | 트리크 기반 개발 |
|---|---|---|
| Branch Complexity | 여러 개의 장기 branch | 단일 branch, 짧은 수명 branch |
| 릴리즈 주기 | 예약된 릴리즈 | 연속적인 배포 |
| 팀 크기 | 대규모 팀 | 작은 팀부터 중간 크기 팀 |
| 테스트 | 주기 테스트 | 자동화 테스트 |
| 배포 위험 | 스테이지 릴리즈로 낮음 | 자주 업데이트로 높음 |
| 되돌리기 | Slower | 느린 속도 |
주요 takeaway: 구조화된, 느린 워크플로우를 위한 Git Flow를 사용하고, 속도와 유연성을 위한 TBD를 사용하십시오. 두 가지 모두 성공하기 위해坚固한 CI/CD pipeline이 필요합니다.
29 - GitFlow vs. Trunk-Based Development: 관리 …
Git Flow 워크플로우 기본
Git Flow는 개발을 위해 다섯 가지 branch 유형을 사용합니다: main, develop, feature, release, and hotfix. 이 구조는 릴리스 관리 및 병렬 개발을 효과적으로 관리하는 데 도움이 됩니다.
Git Flow Branch 구조
| Branch Type | 목적 | Merge 대상 |
|---|---|---|
| Main | 제품 준비가 완료된 code | N/A |
| Develop | 기능을 통합하며 기능 branch의 기본으로 사용됩니다. | N/A |
| 기능 | __CAPGO_KEEP_0__ | 개발 |
| 릴리즈 | __CAPGO_KEEP_1__ & 개발 | 핫픽스 |
| Git Flow의 장점 | 여러 기능이 동시에 개발되어도 충돌이 발생하지 않습니다. | 핫픽스 |
여러 기능이 동시에 개발되어도 충돌이 발생하지 않습니다.
- 여러 기능이 동시에 개발되어도 충돌이 발생하지 않습니다.
- 릴리즈 branch는 최종 테스트 및 버전 준비를 위한 전용 공간을 제공하여 개발 branch를 계속 진행할 수 있도록 합니다.
- Hotfix Git Flow의 단점
Branch 관리의 복잡성
- 여러 활성 branch를 관리하는 것은 병합이 더 어려워질 수 있습니다.느린 배포
- 형식적인 릴리즈 프로세스는 더 단순한 워크플로우보다 배포를 늦추는 데 기여할 수 있습니다.증가된 유지보수
- 각 branch는 자신의 pipeline 구성이 필요하므로 유지보수 작업 부하를 증가시킵니다.Git Flow의 단점
이 워크플로는 버전 관리가 엄격히 필요한 프로젝트, 여러 릴리스 트랙, 규제와의 호환성을 필요로 하는 프로젝트에 적합합니다. 다음으로, 우리는 이 워크플로가 트러스트 기반 개발의 스트리밍된 접근 방식과 어떻게 비교되는지 살펴보겠습니다.
트러스트 기반 개발의 기초
트러스트 기반 개발(TBD)은 주로 트러스트나 메인이라고 불리는 단일 메인 브랜치에 revolves합니다. 이 접근 방식은 DevOps 관행과 지속적인 통합과 밀접하게 연관되어 있습니다.
트러스트 기반 브랜치 구조
일반적인 TBD 워크플로에서, 다음 브랜치 유형을 만날 수 있습니다:
| 브랜치 유형 | 목적 | 수명 |
|---|---|---|
| 메인/트러스트 | 생산 준비가 된 code | 영구 |
| 기능 브랜치 | 개별 변경 사항에 대한 임시 branch | 단기적 |
| 릴리즈 branch | 릴리즈 전에 최종 조정을 위해 사용 | 임시 |
개발자들은 주로 일일로 여러 번 작은 incremental 변경 사항을 main branch에 merge합니다. 이로 인해 지속적인 테스트와 빠른 충돌 해결이 가능합니다.
트렁크 베이스 이점
TBD는 CI/CD 및 DevOps와 함께 팀이 사용하는 경우 여러 이점을 제공합니다.
- 병합 충돌이 적다: 정기적인 병합으로 충돌을 관리할 수 있습니다.
- 빠른 feedback: 자동화된 빌드는 매 병합 시 버그를 빠르게 잡습니다.
- 간소화된 Pipe라인: 단일 branch는 CI/CD 설정의 복잡성을 줄입니다.
- 보다 나은 팀 협력: 공유된 트렁크는 팀이 일치하는 것을 보장합니다.
이 구조는 단순화된 워크플로를 만듭니다. 다음 섹션에서 Git Flow와의 비교를 위해 단계를 설정합니다.
트렁크 기반 제한 사항
TBD는 강점이 있지만 팀이 해결해야 하는 제약 사항도 있습니다:
| 문제 | 영향 | 해결 방법 |
|---|---|---|
| Code 안정성 | 메인에 영향을 미치는 변경 사항의 위험 | 자동화된 테스트를 강력하게 사용하세요 |
| 팀 협력 | 중복 작업은 팀의 혼란을 일으킬 수 있습니다 | 기능 플래그와 작은 커밋을 빈번하게 사용하여 의존하지 마세요 |
| 학습 곡선 | 긴 생명 주기의 branch에서 전환하는 것 | 훈련을 제공하고 점진적으로 도입하세요 |
| 확장성 문제 | 큰 팀에서 빈번한 병합이 팀을 압도할 수 있습니다 | code 검토를 철저히 강제하세요 |
팀 내에서 열린 의사소통과 강력한 자동화된 테스트가 성공적으로 TBD를 채택하기 위한 필수 조건입니다.
Git Flow vs. Trunk-Based: 직접적인 비교
Git Flow와 Trunk-Based Development의 주요 영역에서 어떻게 비교되는지 알아보세요.
기능 비교 표
| 영역 | Git Flow | 트렁크 기반 개발 |
|---|---|---|
| Branch Complexity | 여러 개의 장기 유지되는 branch | 단일 메인 branch와 짧은 유지되는 branch |
| 릴리스 주기 | 예약된 릴리즈 | 지속적인 배포 |
| 팀 크기 | 큰 팀에 적합합니다. | 작은 팀에 더 적합합니다. |
| Code 검토 과정 | Branch merge 시 공식 검토 | 작은 변경 사항에 대한 지속적인 검토 |
| 테스트 요구 사항 | 주기 테스트에 중점 | 자동화 테스트에 의존 |
| 학습 곡선 | 여러 Branch로 인한 복잡성 | 단순한 워크플로우, 강력한 테스트 필요 |
| 배포 위험 | 위험 감소와 단계별 릴리스 | 빈번한 업데이트와 더 높은 위험 |
| 복구 시간 | 느린 롤백 프로세스 | 빠른 복원 기능 |
각 워크플로우 사용 시기
Git Flow 기업급 프로젝트에 적합한 구조화된 버전 릴리스를 필요로 하는 경우에 사용됩니다. 여러 버전을 관리하는 팀과 공식 QA 또는 규정 준수 요구가 있는 프로젝트에 적합합니다.
트렁크 기반 개발 속도와 유연성을 우선하는 팀과 프로젝트에 적합합니다. 예를 들어:
- 빠른 업데이트 필요하는 SaaS 플랫폼
- 강력한 CI/CD PIPELINE을 갖춘 팀
- 정확한 자동 테스트에 의한 프로젝트
- 연속적인 배포 워크플로우 또는 빈번한 릴리스
- 모바일 앱 프로젝트에 필요한 정기적인 업데이트
일부 팀은 심각한 릴리스 트랙이 있는 프로젝트에 Git Flow를 사용하고 코어 서비스에 Trunk-Based Development를 사용하는 방법을 combination합니다.
다음은 두 가지 접근 방식에 대한 CI/CD pipeline 설정 방법입니다.
CI/CD Pipeline 설정
Git Flow CI/CD 설정
- 개발 Branch Pipeline: 단위 테스트, 통합 테스트, code 품질 검사, 빌드 검증, 개발 환경에 배포
- 릴리즈 브랜치 PIPELINE: 전체 테스트 스위트를 실행하고, 보안 스캔, 릴리스 후보를 빌드하고, 스테이징 환경에 배포
- 메인 Branch PipelineCI/CD 통합
트렁크 기반 CI/CD 설정
- 기능 branch pipeline빠른 단위 테스트, code 스타일 검사, 빌드 검증 및 미리보기 환경으로의 배포에 중점을 둡니다.
- CI/CD 통합Capgo로 PR 제출
Capgo Capgo와 통합
CI/CD 설정에 실시간으로 업데이트를 추가하려면 Capgo을 간소하게 통합할 수 있습니다.
Capgo은 GitHub 작업, GitLab CI, 그리고 Jenkins Git Flow와 Trunk-Based pipeline에서 실시간 업데이트, 단계별 출시, 즉시 롤백을 모두 지원하기 위해 사용됩니다. Apple과 Google의 요구 사항을 충족시키며 클라우드 및 자체 호스팅 배포를 모두 지원합니다. [1].
요약 및 권장 사항
워크플로를 선택하세요.
| 시나리오 | Git Flow | 트렁크 기반 |
|---|---|---|
| 팀 크기 | 50명 이상의 개발자 | 50명 미만의 개발자 |
| 릴리즈 주기 | 주간 또는 월간 | 일주일 또는 일주일에 여러 번 |
| 테스트 및 QA | 전통적인 QA 주기 | 자동화된 테스트에 중점 |
| 배포 모델 | 다중 버전, 전통적인 | 클라우드 네이티브, 컨테이너화 |
| 위험 수용도 | conservative, 규제된 환경 | progressive, 빠른 feedback |
- 작업 팀이 작을 때부터 Trunk-Based Development을 시작하고, 그룹이 커질 때까지 확장하세요. CI/CD pipeline이 완전히 자동화되기 전에 전환하세요.
- Git Flow와 Trunk-Based Development 모두에서 일관적인 code 리뷰를 유지하고, 기능 토글을 사용하세요. 선택한 워크플로에 맞춰 pipeline 설정을 조정하세요.
일부 팀은 Git Flow를 주요 릴리스에 사용하면서 Trunk-Based Development을 기능 배달에 사용할 수 있습니다. 어떤 경로를 선택하더라도 CI/CD가 적절히 통합되고 테스트가 자동화되고 팀이 동일한 페이지에 있도록 유지되면 성공할 수 있습니다.
Git Flow vs Trunk-Based for CI/CD
Git Flow vs Trunk-Based for CI/CD를 사용하여 CI/CD 자동화 계획을 수립하고, 그것을 __CAPGO_KEEP_0__ CI/CD와 연결하세요. __CAPGO_KEEP_0__ CI/CD __CAPGO_KEEP_0__ CI/CD에서 제품 워크플로를 위한 Capgo Native Builds Capgo Native Builds에서 제품 워크플로를 위한 Capgo Integrations Capgo 원본 제품 워크플로우에 대해 Capgo 통합(Integrations) Capgo 제품 워크플로우에 대한 Capgo 통합에 대해 CI/CD 통합 CI/CD 통합에 대한 구현 세부 정보에 대해 GitHub 액션 통합 구현 세부 정보에 대한 GitHub 액션 통합에 대해
