아무래도 Git 브랜치를 사용하는 것 같은데 어떻게 관리하고 계신가요?
이 수수께끼를 풀기 위해 우리는 정글 깊은 곳으로 갔다.

1. 지점이란 무엇인가

Git에서 서로 다른 작업을 동시에 수행하는 메커니즘을 분기라고 합니다.

# testing-branchという名前のブランチを作る場合
$ git branch testing-branch

# testing-branchブランチで作業する場合
$ git checkout testing-branch

말하자면, 점심은 언제 쓸까요?SVN 아닌가!
나도 이렇게 생각하는 시대가 있다.
SVN과 같은 중앙 집중식 저장소를 사용하면 자신의 약속과 상관없이 다른 사람에게 영향을 미칩니다.
(제출 후 A 씨가 수정한 소스가 고장났다
자신의 원천을 합쳐 행동을 확인하고 싶다!하지만 남에게 폐를 끼치고 싶지 않다!
그때는 점심이 편했어요.
생산 환경에서 실행되는 원본 저장소에서 자신의 개발 지점을 만들고 수정된 부분만 테스트하고 통합하는 것은 매우 간단하다.

2. 지점 전략이란 무엇인가

사람마다 몇 가지 지점을 잘 할 수 있다.
분지의 분지도 할 수 있다.
불법 지대의 예감..!!!
따라서 무법지대가 되지 않기 위해 지점을 계획적으로 제작하고 운용하기 위해 개발된 것이 지점 전략이다.
Git를 사용하는 팀의 수량에만 분기 전략이 있다.그렇게 지도 모른다, 아마, 아마...

3. 대표적인 지점 전략

대표적인 지점 전략을 조사해 보자.

git-flow

GitHub Flow

gitworkflows

안정trunk 모드

마스터 라인 모델

GitLab Flow

1. git-flow

다음 분기를 주축에 사용하는 방법.

master

hotfix

release branches

develop

feature branches

개발 프로세스

아래 규칙에 따라 운용하다.

develop은master의 최신 창설

에서

개발자의 최신 창설 피처

release는 발표 대상 피처로부터 개발된 최신 창설

각 피처의 합병 목적지는 개발자

release 발표 시 버전 조정 등

master에서 방출 모듈 만들기

버전 업그레이드 시 릴리스에서 마스터로 통합

통합된 피처

삭제

치명적인 오류가 발생했을 때 hotfix

사용

2. GitHub Flow

다음 분기를 주축에 사용하는 방법.

master

work branches

(integration branches)

개발 프로세스

아래 규칙에 따라 운용하다.

master는 항상 배포 가능 상태

작업 지점 창설 명칭은master에서 작업 내용을 알 수 있는 지점

여러 작업 지점을 통합하는 통합 지점을 만들 수 있음

개발자가 작성한 각 지점에 제출

정기push

master에 통합하기 전에 PullRequest를 만들고 다른 개발자의 심사를 받습니다

master에 통합된 후 배포 작업을 완전 자동화하여 즉시 배포

테스트 중시

3. gitworkflows

다음 분기를 주축에 사용하는 방법.

maint

master

next

pu(proposed updates, 제안 중의 변경)

개발 프로세스

아래 규칙에 따라 운용하다.

maint 관리 지난번에 발표된 안정적인 버전 업데이트

master 관리 다음 발표 제출

next는 마스터 테마를 안정시키기 위해 테스트 지점으로 사용됩니다.마스터 발표 후git reset --hard master.

pu는 조기 제출을 포함하는 통합 지점으로도 사용된다.마스터 발표 후git reset --hard master.

병합 작업이 많음

드래그 요청을 사용하지 않음(메일 목록에 메일 알림 변경을 보냄)

4. 트렁크 모드 안정화

다음 분기를 주축에 사용하는 방법.

stable

Milestone1

Milestone2

(이하 약관)

개발 프로세스

아래 규칙에 따라 운용하다.

Milestone은 stable 분기에서 생성해야 합니다

stable=trunk=발표/수시 발표

다중 버전 개발, 결합

이정표가 신설될 때마다 지속적인 통합 설정이 필요합니다

여러 버전을 유지 관리할 수 없음

5. 메인 모델

다음 분기를 주축에 사용하는 방법.

develop

version 1.x

version 2.x

(이하 약관)

개발 프로세스

아래 규칙에 따라 운용하다.
- develop 브랜치 사용
- 여러 버전 관리 가능
- 여러 버전을 관리하지 않으면 이른바 개발 & stable 모델과 같다

6. Git Lab Flow

다음 분기를 주축에 사용하는 방법.

master

pre-production/staging

production

(feature/hotfix)

개발 프로세스

아래 규칙에 따라 운용하다.

pre-production=GitHub Flow의 통합 지점 =git-flow의release

완료 후 피처 지점에 제출

CI 테스트를 통과한 후 pre-production에 자동 배치

pre-production 테스트를 통해 자동으로 프로덕션에 배치

4. 느끼는 것

GitHub flow와 GitLab-flow의 차이는 아직 잘 알려지지 않았다.

CI 환경이 완비된 경우 병합이 많은 프로세스에도 문제가 없음

소규모 그룹이나 프로젝트라면 master와 develop의 GitHub flow만 사용하기 쉽다

팀 규모, 발표 빈도, 팀 기능 수준, 운용 난이도 등 관점에서 재정리하고 싶다

참고 자료

GitHub 실천 입문 Pul Request의 개발 변혁
대총홍기 저/기술평론사/2014.04.25 초판/
A successful Git branching 모델 번역
책 "Pro Git" 의 내용
git 운용 절차의 선택 방법
Git 브랜치 모델 정보
Using git-flow to automate your git branching workflow
(분포식) 버전 제어 시스템의 조직화
Gitlab-flow 설명
Introduction to GitLab Flow