정면

이용, 학습에 대한 개인적인 소감이 적힌 내용이다.
오류와 부족이 있을 수 있기 때문에 무슨 일이 있으면'댓글'과'편집 요청'을 받을 수 있다면 큰 도움이 될 것입니다.

GitFlow란 무엇입니까?

Git를 사용하는 데 있어서 브랜치의 사용법(규칙·방침)이요?
GitFlow라는 규칙을 정하고 그 도움말을 따르는 편리한 도구(플러그인)라고 할 수 있습니까?

형상

GitFlow의 유명한 그림을 빌려보도록 하겠습니다.

참조:https://leanpub.com/site_images/git-flow/git-flow-nvie.png

분기 유형

master

방출 가능한 상태를 유지하는 지점.
개발자는 여기에 수정원을 적용하지 않을 것이다.
줄곧 청결한 상태를 유지하고 있다.

develop

현재 개발 중인 최신 지점.
여기도 개발자가 직접 수정(push)하는 일은 없지만, 각 개발자가 수정한 원본이 여기에 모인다.

feature

모든 개발자가 자유롭게 만들고 수정하는 지점.
기본적으로 로컬에만 존재하고, 원격에 존재하는 것은 통합을 기다리는 것입니까, 아니면 개발자에 보존하는 것입니까?
지점 명칭의 수정 내용은 이해하기 쉽거나 Redmine 등 티켓 구동 개발을 하는 상황에서 티켓 번호라면 편리하다.

release

게시할 때 생성된 브랜치입니다.
개발자에서 만들고 발행판에 대한 수정이 있으면 이 지점에서 이 동작을 실행하십시오.
릴리스 지점 이후의 지점 이름은 발행 번호(V1.0.0 등)라면 편리합니다.

hotfix

발표 후 발견된 오류 등 개발 진행 중
다음 발표를 기다리면 안 돼요!이 색상은 색상이 바래집니다.

개발 단계(develop → feature → develop)

개발자마다 자신의 피처링을 만들고 수정합니다.

git flow feature start {ブランチ名}

복구가 완료되면 원격publish

git flow feature publish {ブランチ名}

병합 요청 (당기기 요청) 에서 develop (코드 검토)
GitLab 또는 GitHub에서 develop에 통합합니다.
※ 여기서 단계를 생략합니다.
개인 개발 등 코드 심사 생략하면featurefinish

git flow feature finish {ブランチ名}

릴리즈 노트(develop → release → master)

발표 준비 중,release 분기 만들기

git flow release start {ブランチ名}

버전 수정이 있으면 수정하고 제출하십시오.publish

git flow release publish {ブランチ名}

완료 후 종료 및 배포 지점 통합

git flow release finish {ブランチ名}

태그가 생성됩니다.

오류 처리 단계 (master → hotfix → master /develop)

오류 수정 패치에 hotfix 분기 만들기

git flow hotfix start {ブランチ名}

오류 수정 및 제출,publish

git flow hotfix publish {ブランチ名}

수정이 완료되면 hotfix 분기 합병

git flow hotfix finish {ブランチ名}

※ 마스터와 개발자가 통합됩니다.

총결산

여러 가지 가지가 생겼지만 기본적으로
1. 시작(start)
2. 수정
3. 공개 공유(publish)
4. 끝(finish)
이런 느낌.