기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
Gitflow 전략의 브랜치
Gitflow 분기 전략에는 일반적으로 다음과 같은 분기가 있습니다.
기능 브랜치
Feature 브랜치는 기능을 개발하는 단기 브랜치입니다. feature 브랜치는 브develop랜치에서 분기하여 생성됩니다. 개발자는 feature브랜치에서 코드를 반복, 커밋 및 테스트합니다. 기능이 완료되면 개발자는 해당 기능을 승격합니다. 특성 브랜치에서 전달되는 경로는 두 개뿐입니다.
-
sandbox브랜치에 병합 -
develop브랜치에 병합 요청 생성
명명 규칙: |
|
명명 규칙 예제: |
|
샌드박스 브랜치
sandbox 브랜치는 Gitflow의 비표준 단기 브랜치입니다. 그러나 CI/CD 파이프라인 개발에 유용합니다. sandbox 브랜치는 주로 다음과 같은 목적으로 사용됩니다.
-
수동 배포 대신 CI/CD 파이프라인을 사용하여 샌드박스 환경에 대한 전체 배포를 수행합니다.
-
개발 또는 테스트와 같은 하위 환경에서 전체 테스트를 위한 병합 요청을 제출하기 전에 파이프라인을 개발하고 테스트합니다.
Sandbox 브랜치는 본질적으로 일시적이며 수명이 길지 않습니다. 특정 테스트가 완료된 후 삭제해야 합니다.
명명 규칙: |
|
명명 규칙 예제: |
|
브랜치 개발
develop 브랜치는 기능이 통합, 구축, 검증 및 개발 환경에 배포되는 수명이 긴 브랜치입니다. 모든 feature브랜치는 브develop랜치에 병합됩니다. develop 브랜치로의 병합은 성공적인 빌드와 2개의 개발자 승인이 필요한 병합 요청을 통해 완료됩니다. 삭제를 방지하려면 브랜치에서 develop브랜치 보호를 활성화합니다.
명명 규칙: |
|
릴리스 브랜치
Gitflow에서 브release랜치는 단기 브랜치입니다. 이러한 브랜치는 build-once, deploy-many 방법론을 수용하여 여러 환경에 배포할 수 있으므로 특별합니다. Release브랜치는 테스트, 스테이징 또는 프로덕션 환경을 대상으로 할 수 있습니다. 개발 팀이 기능을 더 높은 환경으로 승격하기로 결정한 후 새 release브랜치를 생성하고 이전 릴리스의 버전 번호 증가를 사용합니다. 각 환경의 게이트에서 배포를 진행하려면 수동 승인이 필요합니다. Release브랜치는 병합 요청을 변경해야 합니다.
release 브랜치를 프로덕션에 배포한 후에는 develop 및 main브랜치에 다시 병합하여 버그 수정 또는 핫픽스가 향후 개발 작업에 다시 병합되도록 해야 합니다.
명명 규칙: |
|
명명 규칙 예제: |
|
기본 브랜치
main 브랜치는 프로덕션에서 실행 중인 코드를 항상 나타내는 수명이 긴 브랜치입니다. 코드는 릴리스 파이프라인에서 성공적으로 배포된 후 릴리스 main브랜치에서 브랜치로 자동으로 병합됩니다. 삭제를 방지하려면 브랜치에서 main브랜치 보호를 활성화합니다.
명명 규칙: |
|
bugfix 브랜치
브bugfix랜치는 프로덕션에 릴리스되지 않은 릴리스 브랜치의 문제를 해결하는 데 사용되는 단기 브랜치입니다. bugfix 브랜치는 release브랜치의 수정 사항을 테스트, 스테이징 또는 프로덕션 환경으로 승격하는 데만 사용해야 합니다. bugfix 브랜치는 항상 브release랜치에서 분기됩니다.
버그 수정을 테스트한 후 병합 요청을 통해 release브랜치로 승격할 수 있습니다. 그런 다음 표준 릴리스 프로세스에 따라 release브랜치를 앞으로 푸시할 수 있습니다.
명명 규칙: |
|
명명 규칙 예제: |
|
핫픽스 브랜치
hotfix 브랜치는 프로덕션 문제를 해결하는 데 사용되는 단기 브랜치입니다. 프로덕션 환경에 도달하기 위해 신속하게 처리해야 하는 수정 사항을 승격하는 데만 사용됩니다. hotfix 브랜치는 항상에서 분기됩니다main.
핫픽스를 테스트한 후 병합 요청을 통해에서 생성된 release브랜치로 핫픽스를 프로덕션으로 승격할 수 있습니다main. 그런 다음 테스트를 위해 표준 릴리스 프로세스에 따라 release브랜치를 앞으로 푸시할 수 있습니다.
명명 규칙: |
|
명명 규칙 예제: |
|