Git 분기 관리 전략

프로 그래 밍 에 진지 하 게 임 하면 반드시'버 전 관리 시스템'(Version Control System)을 사용 할 것 이다.
현재 가장 유행 하 는'버 전 관리 시스템'은Git이 아니면 안 된다.

Git 은 같은 종류의 소프트웨어 에 비해 장점 이 많다.그 중에서 도 현저 한 점 은 버 전의 분기(branch)와 합병(merge)이 매우 편리 하 다 는 것 이다.일부 전통 적 인 버 전 관리 소프트웨어 는 분기 작업 이 실제 적 으로 기 존 코드 의 물리 적 복사 본 을 만 들 고 Git 은 현재 버 전(일명'스냅 샷')을 가리 키 는 지침 만 생 성하 기 때문에 매우 빠 르 고 사용 하기 쉽다.
하지만 너무 편리 하면 부작용 도 생 길 수 있다.만약 당신 이 주 의 를 기울 이지 않 는 다 면,지엽 적 이 고 사방 에 열 린 버 전 라 이브 러 리 를 남 길 수 있 습 니 다.곳곳에 가지 가 있어 서 주간 발전의 맥락 을 전혀 찾 을 수 없습니다.

Vincent Driessen지점 관리 전략 을 제 시 했 는데 저 는 매우 참고 할 만하 다 고 생각 합 니 다.이 는 버 전 라 이브 러 리 의 발전 을 간결 하고 주요 한 부분 이 뚜렷 하 며 각 부분 이 각각 직무 를 맡 고 질서 정연 하 게 할 수 있다.이론 적 으로 이런 전략 은 모든 버 전 관리 시스템 에 적용 되 고 Git 은 예 를 들 뿐이다.Git 에 익숙 하지 않 으 면 예시 부분 을 건 너 뛰 면 된다.
1.메 인 분기 Master
우선,코드 라 이브 러 리 는 하나 있 고,단지 하나의 주요 지점 만 있어 야 한다.사용자 에 게 제공 되 는 모든 정식 버 전 은 이 메 인 지점 에서 발 표 됩 니 다.

Git 메 인 브 랜 치 이름 은 기본적으로 Master 입 니 다.이것 은 자동 으로 만들어 진 것 입 니 다.버 전 라 이브 러 리 가 초기 화 된 후에 기본 값 은 메 인 지점 에서 개발 하 는 것 입 니 다.
2.개발 지점 Develop
주요 지점 은 중대 한 버 전 을 분포 하 는 데 만 사용 되 며,일상적인 개발 은 다른 지점 에서 이 루어 져 야 한다.우 리 는 개발 용 가 지 를 Develop 이 라 고 부른다.

이 가 지 는 코드 를 만 드 는 최신 격 야 버 전(nightly)에 사용 할 수 있 습 니 다.공식 적 으로 대외 적 으로 발표 하려 면 Master 분기 에서 Develop 분기 에 대해'합병'(merge)을 한다.
Git 에서 Develop 브 랜 치 를 만 드 는 명령:

　git checkout -b develop master

Develop 지점 을 Master 지점 에 발표 하 는 명령:

#    Master  
git checkout master
#  Develop      
git merge --no-ff develop

이전 명령 의--no-ff 인자 가 무슨 뜻 인지 조금 설명 하 겠 습 니 다.기본 적 인 상황 에서 Git 은'빠 른 병합'(fast-farward merge)을 실행 하고 Master 지점 을 Develop 지점 으로 직접 가리 킵 니 다.

--no-ff 인 자 를 사용 하면 정상 적 인 합병 을 실행 하고 Master 분기 에 새 노드 를 생 성 합 니 다.판본 의 진전 이 뚜렷 함 을 확보 하기 위해 서 우 리 는 이런 방법 을 채택 하 기 를 희망 한다.합병 에 대한 더 많은 설명 은 Benjamin Sandofsky 의Understanding the Git Workflow를 참고 하 세 요.

3.임시 적 인 갈래
앞에서 말 한 버 전 라 이브 러 리 의 두 가지 주요 부분:Master 와 Develop.전 자 는 정식 발표 에 사용 되 고 후 자 는 일상적인 개발 에 사용 된다.사실 상설 분 지 는 이 두 가지 만 있 으 면 됩 니 다.다른 것 은 필요 없습니다.
그러나 상설 분기 외 에 도 일부 임시 분기 가 있어 특정 목적 에 대응 하 는 버 전 개발 에 사용 된다.임시 적 인 가 지 는 주로 세 가지 가 있다.
*기능(feature)분기
*사전 발표(release)분기
*버그 수정(fixmug)분기
이 세 가지 가 지 는 모두 임시 적 인 수요 에 속 합 니 다.사용 한 후에 삭제 해 야 합 니 다.코드 라 이브 러 리 의 상설 가 지 는 항상 Master 와 Develop 만 있 습 니 다.
기능 분기
다음은 이 세 가지'임시 적 분기'를 하나씩 살 펴 보 자.
첫 번 째 는 기능 분기 로 특정한 기능 을 개발 하기 위해 Develop 분기 에서 분 리 된 것 이다.개발 이 완료 되면 Develop 에 합병 해 야 합 니 다.

기능 분기 의 이름 은 feature-*형식 으로 명명 할 수 있 습 니 다.
기능 분기 만 들 기:

git checkout -b feature-x develop

개발 이 완료 되면 개발 지점 에 기능 지점 을 통합 합 니 다.

git checkout develop
git merge --no-ff feature-x

feature 분기 삭제:

git branch -d feature-x

5.사전 발표 분기
두 번 째 는 사전 발표 분기 입 니 다.정식 버 전 을 발표 하기 전에(즉,Master 분기 로 통합 하기 전에)사전 발표 버 전 을 테스트 해 야 할 수도 있 습 니 다.
사전 발표 지점 은 Develop 지점 에서 나 뉘 어 져 있 으 며,사전 발표 가 끝 난 후 에는 반드시 Develop 과 Master 지점 에 통합 되 어야 합 니 다.그것 의 이름 은 release-*형식 을 사용 할 수 있 습 니 다.
사전 발표 분기 만 들 기:

git checkout -b release-1.2 develop

문제 가 없 는 지 확인 한 후 master 분기 로 통합:

git checkout master
git merge --no-ff release-1.2
#          ，     
git tag -a 1.2

develop 분기 로 통합:

git checkout develop
git merge --no-ff release-1.2

마지막 으로 미리 발 표 된 지점 을 삭제 합 니 다:

git branch -d release-1.2

버그 분기 보수
마지막 으로 bug 가 지 를 수선 하 는 것 입 니 다.소프트웨어 가 정식으로 발 표 된 후 에는 bug 가 나타 날 수 밖 에 없다.이 때 는 가 지 를 만들어 bug 수 리 를 해 야 합 니 다.
버그 지점 을 수리 하 는 것 은 Master 지점 에서 나 온 것 입 니 다.패 치가 끝 난 후 Master 와 Develop 분기 에 통합 합 니 다.그것 의 이름 은 fixbug-*형식 을 사용 할 수 있 습 니 다.

버그 수정 지점 만 들 기:

git checkout -b fixbug-0.1 master

패 치가 끝 난 후 master 분기 로 통합:

git checkout master
git merge --no-ff fixbug-0.1
git tag -a 0.1.1

develop 분기 로 통합:

git checkout develop
git merge --no-ff fixbug-0.1

마지막 으로"버그 지점 수정"을 삭제 합 니 다.

git branch -d fixbug-0.1

이상 이 바로 본 고의 모든 내용 입 니 다.여러분 의 학습 에 도움 이 되 고 저 희 를 많이 응원 해 주 셨 으 면 좋 겠 습 니 다.