개시하다

5일째는 세일즈맨의 오사@okuderap가 맡는다.
이번에는 Giit에 관한 지점 모형입니다.
내가 처음 Git를 사용했을 때, 하나의 마스터 지점으로 개발을 진행하였다
나는 분기를 어떻게 구분해서 사용하는지 전혀 모른다.
제가 겪었던 안 좋은 예를 몇 개 들어보세요.
마지막으로 이 문제들을 해결하는 지점 모델을 소개하겠습니다.
※ iOS 개발에 지트를 사용한 경험이 기재되어 있습니다.
제품과 서비스의 개발을 이용하면 통용된다고 생각합니다.
항목에 따라 다른 부분도 있다.

Case1: 마스터 브랜치 1개

내가 지트를 처음 만났을 때 이 사용법이었어.
[개발 작업의 흐름]
1. 무슨 일을 하든지 마스터 지점에 제출해야 한다
[등장하는 지점]
master:
만약 개발을 진행한다면 전부 이 지점에 제출될 것이다
이미지

[문제점]
· 발표 시간 등 안정적인 버전을 저장할 수 없습니다.
잠깐만요.

Case2: Master &develop 분기

Case1에서 반 걸음 전진했다고요?차이가 많지 않다.
[개발 작업의 흐름]
1. 개발 시작 시 마스터 지점에서 개발자 지점 만들기
2. 개발 과정에서 모두 개발자 참여
3. 출시 시 개발자→마스터 통합
[등장하는 지점]
master:
발표할 때 원본 코드의 지점을 관리합니다
개발자 (마스터에서 파생):
개발 업무용 지점
이미지

[문제점]
• 설치된 특정 기능의 사양 변경 시 대응하기 어려움
잠깐만요.

Case3:master &develop &feature 분기

[개발 작업의 흐름]
1. 마스터 지점에서 개발자 지점 만들기
2. 개발자 지점에서 이루어진 모든 기능에 대한feature 지점 만들기
3. 피처 지점의 기능을 개발자 지점에 통합
4. 출시 시 개발자→마스터 통합
[등장하는 지점]
master:
발표할 때 원본 코드의 지점을 관리합니다
개발자 (마스터에서 파생):
개발 작업의 주축 지점
feature(develop):
모든 기능을 실현하는 지점(feature/◯,feature/xx 등)
이미지

[문제점]
• 작업 발표 시 조정도 개발자 지점에 의존
• 발표 후 치명적인 문제를 발견했을 때 대응하는 지점이 없음
잠깐만요.

현재 사용 중인 브랜치 모델

다음은 각종 문제를 해결할 수 있는 현재 활용되고 있는 지점 디자인을 소개한다.
[개발 작업의 흐름]
1. 마스터 지점에서 개발자 지점 만들기
2. 개발자 지점에서 이루어진 모든 기능에 대한feature 지점 만들기
3. 피처 지점의 기능을 개발자 지점에 통합
4. 발표 작업이 시작되었을 때 개발자에서release 지점을 만듭니다
5. 발표 작업이 끝났을 때release에서develop,master 지점으로 통합
[출시 후 장애 대응 프로세스]
1. 마스터 지점에서hotfix 지점 만들기
2.hotfix 지점에서 고장 대응 완료 시 개발자,master 지점에 통합
[등장하는 지점]
master:
발표할 때 원본 코드의 지점을 관리합니다
개발자 (마스터에서 파생):
개발 작업의 주축 지점
feature(develop):
모든 기능을 실현하는 지점(feature/◯,feature/xx 등)
develop에서 release:
개발 작업이 끝난 후 발행 시 미세하게 조정하는 지점
버전 번호 변경 등에 사용됩니다.
hotfix(master에서 파생):
출시된 제품에 치명적인 결함(붕괴 등)이 있을 때 긴급 대응하는 지점
이미지

참고 자료

A successful Git branching model
http://nvie.com/posts/a-successful-git-branching-model/

최후

SmartTec Bencers에서는 경험이 없지만 iOS를 개발하고 싶어요!라고 말했다.
Advent Calendar의 SmiltTec Bencers 페이지에 회사와 Wantedly의 URL이 게재되었으니 관심 있는 분들은 꼭 보십시오.
http://qiita.com/advent-calendar/2016/stv
내일은 @EnoMt입니다.
기대해주세요!