Git
워크 플로 유형 분석

비고

Gitflow 워크 플로우

원래 Vincent Driessen에 의해 제안 된 Gitflow는 git 및 몇 가지 사전 정의 된 분기를 사용하는 개발 워크 플로입니다. Feature Branch Workflow 의 특별한 경우로 볼 수 있습니다.

이 중 하나의 아이디어는 개발중인 특정 부품에 대해 별도의 분기를 예약하는 것입니다.

• master 브랜치는 항상 가장 최근의 프로덕션 코드입니다. 실험 코드는 여기에 속하지 않습니다.
• develop 지점에는 모든 최신 개발이 포함되어 있습니다. 이러한 발달상의 변화는 거의 모든 것이 될 수 있지만, 더 큰 특징은 그들 자신의 가지를 위해 예비되어 있습니다. 여기에있는 코드는 릴리스 / 배포 전에 항상 작업되고 release 로 병합됩니다.
• hotfix 분기는 다음 릴리스까지 기다릴 수없는 사소한 버그 수정을위한 것입니다. hotfix 분기는 master 에서 벗어나서 master 와 develop 로 병합됩니다.
• release 지점은 새로운 개발을 develop 에서 master 로 릴리스하는 데 사용됩니다. 최종 버전 변경 (예 : 버전 번호 부름)은 릴리스 분기에서 수행 된 다음 master 로 다시 병합되고 develop 됩니다. 새 버전을 배포 할 때 master 는 나중에 참조하고 쉽게 롤백 할 수 있도록 현재 버전 번호 (예 : 의미 적 버전 관리 )로 태그를 지정해야합니다.
• feature 브랜치는 더 큰 기능을 위해 예약되어 있습니다. 이들은 지정된 지점에서 구체적으로 개발되고 완성되면 develop 과 통합됩니다. 전용 feature 분기는 개발을 분리하고 완성 된 기능을 서로 독립적으로 배포 할 수 있도록 도와줍니다.

이 모델의 시각적 표현 :

이 모델의 원래 표현 :

워크 플로우 포킹

이 유형의 워크 플로는이 항목에서 언급 한 다른 워크 플로와 근본적으로 다릅니다. 모든 개발자가 액세스 할 수있는 중앙 집중식 리포지토리를 보유하는 대신 각 개발자는 주 리포에서 분기 된 고유 한 리포를 보유합니다. 이 기능의 장점은 개발자가 공유 된 repo가 ​​아닌 자신의 repos에 게시 할 수 있고 유지 보수 담당자가 필요할 때마다 분기 된 repos의 변경 사항을 원본에 통합 할 수 있다는 것입니다.

이 워크 플로우의 시각적 표현은 다음과 같습니다.

중앙 집중식 워크 플로

이 기본 워크 플로 모델을 사용하면 master 분기에 모든 활성 개발이 포함됩니다. 기여자는 개발을 계속하기 전에 최신 변경 사항을 가져올 것이 확실해야합니다.이 지점은 빠르게 변경 될 예정입니다. 모든 사용자는이 저장소에 액세스 할 수 있으며 마스터 지점에 바로 변경 사항을 적용 할 수 있습니다.

이 모델의 시각적 표현 :

이것은 고전적인 버전 제어 패러다임으로 Subversion 및 CVS와 같은 구형 시스템이 구축되었습니다. 이런 방식으로 작동하는 소프트웨어를 중앙 집중식 버전 제어 시스템 (CVCS)이라고합니다. 힘내는 이런 방식으로 작업 할 수 있지만, 매 순간마다 앞에 병합을 수행해야한다는 등의 단점이 있습니다. 팀이 이런 방식으로 작동하는 것은 가능하지만 지속적인 병합 충돌 해결로 귀중한 시간을 많이 소비 할 수 있습니다.

이것이 Linus Torvalds가 Git을 CVCS가 아닌 DVCS 나 Mercurial과 유사한 Distributed Version Control System 으로 만든 이유입니다. 이 새로운 방식의 장점은이 페이지의 다른 예제에서 보여준 유연성입니다.

기능 분기 워크 플로

Feature Branch Workflow의 핵심 아이디어는 모든 기능 개발이 master 분기 대신 전용 분기에서 수행되어야한다는 것입니다. 이 캡슐화를 통해 여러 개발자가 주요 코드베이스를 방해하지 않고 특정 기능을 쉽게 작업 할 수 있습니다. 또한 master 브랜치가 깨진 코드를 절대로 포함하지 않기 때문에 지속적인 통합 환경에 큰 이점이됩니다.

기능 개발을 캡슐화하면 지점을 중심으로 토론을 시작하는 방법 인 끌어 오기 요청을 활용할 수도 있습니다. 그들은 다른 개발자에게 공식 프로젝트에 통합되기 전에 기능을 승인 할 수있는 기회를 제공합니다. 또는 기능의 한가운데에 갇히게되면 동료로부터 제안을 요청하는 요청을 열 수 있습니다. 요점은, 끌어 오기 요청을 통해 팀이 서로의 작업에 대해 쉽게 의견을 말할 수 있다는 것입니다.

Atlassian 자습서를 기반으로합니다.

GitHub 흐름

많은 오픈 소스 프로젝트에서 인기가 있지만 그 뿐만이 아닙니다.

특정 위치의 마스터 지점 (Github, Gitlab, Bitbucket, 로컬 서버)에는 최신 출시 버전이 포함되어 있습니다. 새로운 기능 / 버그 수정 / 아키텍처 변경마다 각 개발자가 지점을 만듭니다.

해당 분기에서 변경이 발생하고 풀 요청, 코드 검토 등에서 논의 할 수 있습니다. 일단 승인되면 마스터 분기에 병합됩니다.

Scott Chacon의 전체 흐름 :

• 마스터 브랜치의 모든 것이 배치 가능합니다.
• 새로운 것을 만들기 위해서 master의 설명 적으로 명명 된 브랜치 (예 : new-oauth2-scope)
• 해당 지사에 로컬로 커밋하고 정기적으로 작업을 서버의 동일한 명명 된 분기로 푸시합니다.
• 의견이나 도움이 필요하거나 분기가 병합 될 준비가되었다고 생각되면 당겨 요청을 엽니 다.
• 다른 사람이이 기능을 검토하고 승인 한 후 마스터로 병합 할 수 있습니다.
• 병합되고 '마스터'에 푸시되면 즉시 배포 할 수 있고 배포해야합니다.

Scott Chacon의 개인 웹 사이트 에서 처음 발표되었습니다.

이미지 제공 : GitHub Flow 참조