Gitflow 워크플로
Gitflow는 원래 Git 브랜치를 관리하기 위한 파괴적인 최신 전략이었던 레거시 Git 워크플로입니다. Gitflow는 현재 최신 연속 소프트웨어 개발 및 DevOps 사례의 모범 사례로 간주되는 트렁크 기반 워크플로 때문에 인기가 떨어졌습니다. Gitflow는 CI/CD와 함께 사용하기 어려울 수도 있습니다. 이 게시물은 기록적 목적으로 Gitflow에 대해 자세히 설명합니다.
Gitflow란 무엇입니까?
Gitflow는 기능 브랜치와 여러 기본 브랜치를 사용하는 대체 Git 브랜칭 모델입니다. Vincent Driessen이 nvie에서 처음 게시하여 유명해졌습니다. 트렁크 기반 개발과 비교하여 Gitflow는 수명이 더 긴 무수한 브랜치와 더 큰 커밋을 제공합니다. 이 모델에서 개발자는 기능 브랜치를 만들고 기능이 완료될 때까지 메인 트렁크 브랜치에 병합하는 작업을 지연합니다. 이렇게 수명이 긴 기능 브랜치는 병합할 때 더 많은 공동 작업이 필요하며 트렁크 브랜치에서 벗어날 위험이 더 높습니다. 충돌하는 업데이트가 발생할 수도 있습니다.
Gitflow는 릴리스 주기가 예정된 프로젝트 및 지속적 배포의 DevOps 모범 사례에 사용할 수 있습니다. 이 워크플로는 기능 브랜치 워크플로에 필요한 것 이상으로 새로운 개념이나 명령을 추가하지 않습니다. 대신 서로 다른 브랜치에 매우 구체적인 역할을 할당하고 상호 작용하는 방식 및 시기를 정의합니다. feature 브랜치 외에도 개별 브랜치를 사용하여 릴리스를 준비, 유지 관리 및 기록합니다. 물론 풀리퀘스트, 격리된 실험, 보다 효율적인 공동 작업 등 기능 브랜치 워크플로의 모든 이점을 활용할 수 있습니다.
관련 자료
고급 Git 로그
솔루션 보기
Bitbucket Cloud에서 Git에 대해 알아보기
작동 방식
develop 및 main 브랜치
이 워크플로는 단일 main 브랜치 대신 두 개의 브랜치를 사용하여 프로젝트를 기록합니다. main 브랜치는 공식 릴리스 기록을 저장하고, develop 브랜치는 기능의 통합 브랜치 역할을 합니다. main 브랜치의 모든 커밋에 버전 번호로 태그하는 데도 편리합니다.
첫 번째 단계는 develop 브랜치로 기본 main 브랜치를 보완하는 것입니다. 이 작업을 수행하는 간단한 방법은 다음과 같이 한 개발자가 로컬에서 빈 develop 브랜치를 만들어 서버로 푸시하는 것입니다.
git branch develop
git push -u origin develop이 브랜치는 프로젝트의 전체 기록을 포함하지만 main 브랜치는 요약 버전만 포함합니다. 이제 다른 개발자는 중앙 리포지토리를 복제하고 develop용 추적 브랜치를 만들어야 합니다.
git-flow 확장 라이브러리를 사용할 때 다음과 같이 기존 리포지토리에서 git flow init 명령을 실행하면 develop 브랜치가 만들어집니다.
$ git flow init
Initialized empty Git repository in ~/project/.git/
No branches exist yet. Base branches must be created now.
Branch name for production releases: [main]
Branch name for "next release" development: [develop]
How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []
$ git branch
* develop
mainfeature 브랜치
1단계. 리포지토리 생성
각 새로운 기능은 백업/공동 작업을 위해 중앙 리포지토리로 푸시할 수 있는 자체 브랜치에 있어야 합니다. 그러나 feature 브랜치는 main 브랜치에서 분기하는 대신 develop 브랜치를 상위 브랜치로 사용합니다. 기능이 완료되면 다시 개발로 병합됩니다. 기능은 main과 직접 상호 작용해서는 안 됩니다.
develop 브랜치와 결합된 feature 브랜치는 모든 의도 및 목적에 걸맞은 기능 브랜치 워크플로입니다. 하지만 Gitflow 워크플로는 여기서 멈추지 않습니다.
feature 브랜치는 일반적으로 최신 develop 브랜치까지 만들어집니다.
기능 브랜치 만들기
git-flow 확장이 없는 경우:
git checkout develop
git checkout -b feature_branchgit-flow 확장을 사용하는 경우:
git flow feature start feature_branch작업을 계속하며 평소처럼 Git을 사용하세요.
기능 브랜치 마무리
기능에 대한 개발 작업이 완료되면 다음 단계는 feature_branch를 develop로 병합하는 것입니다.
git-flow 확장이 없는 경우:
git checkout develop
git merge feature_branchgit-flow 확장을 사용하는 경우:
git flow feature finish feature_branchrelease 브랜치
develop가 릴리스를 위한 기능을 충분히 획득한 경우(또는 사전에 정해진 릴리스 날짜가 다가오는 경우), release 브랜치를 develop에서 포크합니다. 이 브랜치를 만들면 다음 릴리스 주기가 시작되므로 이 시점 이후에는 새로운 기능을 추가할 수 없습니다. 버그 수정, 설명서 생성 및 기타 릴리스 중심의 작업만 브랜치에 포함되어야 합니다. 제공할 준비가 되면 release 브랜치가 main 브랜치에 병합되고 버전 번호로 태그가 지정됩니다. 또한 릴리스가 시작된 이후 진행되었을 수 있는 develop에 다시 병합해야 합니다.
전용 브랜치를 사용하여 릴리스를 준비하면 한 팀이 현재 릴리스를 다듬는 동안 다른 팀이 다음 릴리스의 기능을 계속 작업할 수 있습니다. 또한 잘 정의된 개발 단계를 만듭니다(예: “이번 주에는 버전 4.0을 준비 중입니다.”라고 말하고 실제로 리포지토리 구조에서 쉽게 볼 수 있습니다).
release 브랜치를 만드는 것은 또 다른 간단한 분기 작업입니다. feature 브랜치와 마찬가지로 release 브랜치는 develop 브랜치를 기반으로 합니다. 다음 방법을 사용하여 새 release 브랜치를 만들 수 있습니다.
git-flow 확장이 없는 경우:
git checkout develop
git checkout -b release/0.1.0git-flow 확장을 사용하는 경우:
$ git flow release start 0.1.0
Switched to a new branch 'release/0.1.0'릴리스를 제공할 준비가 되면 main 및 develop으로 병합된 다음 release 브랜치가 삭제됩니다. 중요한 업데이트가 release 브랜치에 추가되어 새로운 기능에 액세스할 수 있어야 하므로 develop 브랜치로 다시 병합하는 것이 중요합니다. 조직에서 코드 검토를 강조한다면 풀리퀘스트를 위한 이상적인 장소가 될 수 있습니다.
release 브랜치를 완료하려면 다음 방법을 사용합니다.
git-flow 확장이 없는 경우:
git checkout main
git merge release/0.1.0또는 git-flow 확장을 사용하는 경우:
git flow release finish '0.1.0'hotfix 브랜치
유지 관리 또는 "hotfix" 브랜치는 프로덕션 릴리스를 빠르게 패치하는 데 사용됩니다. hotfix 브랜치는 develop 브랜치 대신 main 브랜치를 기반으로 한다는 점을 제외하면 release 브랜치 및 feature 브랜치와 매우 유사합니다. main에서 직접 포크해야 하는 유일한 브랜치입니다. 수정이 완료되는 즉시 main 및 develop(또는 현재 release 브랜치)에 병합되어야 하며, 업데이트된 버전 번호로 main 브랜치에 태그를 지정해야 합니다.
버그 수정을 위한 전용 개발 라인을 보유하면 팀에서 워크플로의 나머지 부분을 중단하거나 다음 릴리스 주기를 기다리지 않고도 문제를 해결할 수 있습니다. 유지 관리 브랜치는 main과 직접 작동하는 임시 release 브랜치로 생각할 수 있습니다. 다음 방법을 사용하여 hotfix 브랜치를 만들 수 있습니다.
git-flow 확장이 없는 경우:
git checkout main
git checkout -b hotfix_branchgit-flow 확장을 사용하는 경우:
$ git flow hotfix start hotfix_branchrelease 브랜치를 완료하는 것과 마찬가지로 hotfix 브랜치는 main 및 develop 브랜치 모두에 병합됩니다.
git checkout main
git merge hotfix_branch
git checkout develop
git merge hotfix_branch
git branch -D hotfix_branch$ git flow hotfix finish hotfix_branch예
기능 브랜치 흐름을 보여주는 전체 예제는 다음과 같습니다. main 브랜치가 있는 리포지토리 설정이 있다고 가정합니다.
git checkout main
git checkout -b develop
git checkout -b feature_branch
# work happens on feature branch
git checkout develop
git merge feature_branch
git checkout main
git merge develop
git branch -d feature_branchfeature 및 release 흐름 외에도 hotfix 예제는 다음과 같습니다.
git checkout main
git checkout -b hotfix_branch
# work is done commits are added to the hotfix_branch
git checkout develop
git merge hotfix_branch
git checkout main
git merge hotfix_branch요약
여기서는 Gitflow 워크플로에 대해 논의했습니다. Gitflow는 사용자와 팀이 활용할 수 있는 다양한 스타일의 Git 워크플로입니다.
Gitflow에 대해 알아야 할 몇 가지 주요 내용은 다음과 같습니다.
- 릴리스 기반 소프트웨어 워크플로에 적합한 워크플로입니다.
- Gitflow는 프로덕션에 핫픽스 전용 채널을 제공합니다.
Gitflow의 전체 흐름:
1. develop 브랜치를 main 브랜치에서 만듭니다
2. release 브랜치를 develop 브랜치에서 만듭니다
3. feature 브랜치를 develop 브랜치에서 만듭니다.
4 feature 브랜치가 완료되면 develop 브랜치에 병합됩니다
5. release 브랜치가 완료되면 develop 및 main 브랜치에 병합됩니다
6. main 브랜치에서 문제가 감지되면 hotfix 브랜치가 main 브랜치에서 만들어집니다
7. hotfix 브랜치가 완료되면 develop 및 main 브랜치에 병합됩니다
다음으로, 포킹 워크플로에 대해 알아보거나 워크플로 비교 페이지를 방문하세요.
이 문서 공유
다음 토픽
여러분께 도움을 드릴 자료를 추천합니다.
이러한 리소스에 책갈피를 지정하여 DevOps 팀의 유형에 대해 알아보거나 Atlassian에서 DevOps에 대한 지속적인 업데이트를 확인하세요.
Bitbucket 블로그
DevOps 학습 경로
