Git Flow Note

최근 에 Git 코드 버 전 관리 에 곤 혹 스 러 워 서 이틀 동안 연 구 를 집중 했다. 그 중에서 기초 지식 은 에서 기원 되 었 고 분기 사상 은 박문 인 (저자: Vincent Driessen, 원문 링크:http://nvie.com/posts/a-successful-git-branching-model/) 자세히 읽 으 면 많은 것 을 얻 을 수 있 습 니 다.이 글 에 만 소감 을 기록 하고 상세 한 내용 은 원문 을 참고 하 시기 바 랍 니 다.
Main Branch
master
메 인 지점 은 배치 (생산) 환경의 최신 버 전의 코드 상 태 를 대표 합 니 다. 즉, 코드 는 항상 배치 환경의 최신 버 전 코드 와 일치 합 니 다.
develop
개발 지점 은 곧 발 표 될 다음 버 전의 코드 상 태 를 대표 합 니 다.'통합' 분기 로 도 이해 할 수 있 으 며, 새로운 특성 을 개발 하거나 버그 를 복구 하 는 과정 에서 발생 하 는 새로운 코드 는 정기 적 으로 개발 분기 로 통합 하여 '매일' 구축 에 사용 해 야 합 니 다.
개발 분기 (develop) 의 코드 가 발표 가능 한 상태 로 안정 되 었 을 때 메 인 분기 (master) 로 통합 되 어 메 인 분기 에서 해당 버 전 (Tag) 을 만들어 야 합 니 다.
Supporting Branch
Feature
특성 분기, 새로운 기능 특성 개발 에 사용 되 며, 생명 주 기 는 다음 과 같 습 니 다.
(1) 새로운 기능 특성 을 개발 해 야 할 때 개발 지점 에서 하나 이상 의 특성 지점 을 만 듭 니 다.

git checkout -b myfeature develop

(2) 새로운 기능 특성 개발 이 완료 되 었 을 때 특성 지점 은 개발 지점 으로 통합 되 어야 한다.

git checkout develop
git merge --no-ff myfeature

(3) 특성 분기 삭제;

git branch -d myfeature

(4) 원 격 버 전 라 이브 러 리 로 개발 지점 전송;

git push origin develop

주: 특성 가 지 는 개발 자의 로 컬 환경 에 만 존재 하 며 원 격 버 전 라 이브 러 리 로 전송 하지 않 습 니 다.
Release
발표 분기, 특정 버 전 발표 전 "준비" 분기, 테스트 또는 버그 복구 에 사용, 생명 주 기 는 다음 과 같 습 니 다:
(1) 특정한 버 전의 기능 특성 이 모두 개발 되 었 습 니 다 (즉, 이 버 전의 모든 기능 특성 분기 가 개발 분기 로 통합 되 었 습 니 다). 정식 발표 전에 해당 하 는 발표 가 지 를 만들어 야 합 니 다.

git checkout -b release-1.2 develop

주: 발표 지점 을 만들어 야 하 는 이 유 는 발표 지점 이 생 성 되면 지점 테스트 를 발표 하거나 버그 를 복구 하 는 과정 에서 다음 버 전의 코드 개발 에 사용 할 수 있 기 때 문 입 니 다.
(2) 버 전 정보 업데이트, 제출;

./bump-version.sh 1.2
git commit -m "Bumped version number to 1.2"

bump - version. sh 는 예제 스 크 립 트 일 뿐 버 전 파일 의 버 전 번 호 를 업데이트 하 는 데 사용 되 며, 실제 상황 에 따라 수 동 으로 버 전 번 호 를 업데이트 할 수 있 습 니 다.
(3) 테스트 또는 버그 복 구 는 모두 이 발표 지점 에서 진행 합 니 다.
(4) 테스트 또는 bug 복구 가 완료 되면 메 인 분기, 버 전 생 성, 원 격 버 전 라 이브 러 리 로 통합 합 니 다.

git checkout master
git merge --no-ff release-1.2
git push origin master

git tag -m "Version 1.2" 1.2
git push origin 1.2

(5) 개발 지점 에 통합 하여 원 격 버 전 라 이브 러 리 로 전송 해 야 합 니 다.

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

(6) 발표 지점 삭제;

git branch -d release-1.2

주 1: 왜 발표 지점 에서 개발 지점 으로 합병 하고 개발 지점 에서 메 인 지점 으로 합병 하지 않 았 습 니까?이 는 발표 분기 가 테스트 나 bug 복구 과정 에서 개발 분기 가 다음 버 전의 코드 개발 에 참여 할 수 있 기 때 문 입 니 다. 이렇게 하면 현재 버 전의 코드 에 다음 버 전이 완 성 된 코드 를 혼합 할 수 있 습 니 다.
주 2: 주요 지점 및 개발 지점 에 지점 을 합병 할 때 버 전 번호 업데이트 와 관련 되 기 때문에 구체 적 인 방식 이 다 르 기 때문에 충돌 이 발생 할 수 있 습 니 다.메 인 지점 으로 통합 할 때 발표 지점 을 위주 로 합 니 다.개발 지점 에 합병 할 때 개발 지점 을 위주 로 한다.
Hotfix
발 표 된 버 전에 존재 하 는 버그 를 복구 하 는 데 사 용 됩 니 다. 수명 주 기 는 다음 과 같 습 니 다.
(1) 발 표 된 버 전에 버그 가 존재 할 때 해당 버 전에 서 복구 지점 을 만 들 고 버그 와 테스트 를 복원 해 야 합 니 다.

git checkout -b hotfix-1.2.1 1.2

(2) 버 전 정보 업데이트, 제출;

./bump-version.sh 1.2.1
git commit -m “Bumped version number to 1.2.1”

(3) 버그 복구 및 테스트 완료 후 새 버 전 을 만 들 고 원 격 버 전 라 이브 러 리 로 전송 합 니 다.

git tag -m "Version 1.2.1” 1.2.1
git push origin 1.2.1

(4) 개발 지점 에 통합 하여 원 격 버 전 라 이브 러 리 로 전송 해 야 합 니 다.

git checkout develop
git merge --no-ff hotfix-1.2.1
git push origin develop

(5) 복구 지점 삭제;

git branch -d hotfix-1.2.1

주 1: 복구 분기 (1) 는 (3) 원문 설명 과 일치 하지 않 으 며 주로 다음 과 같은 몇 가지 측면 에서 고려 합 니 다.
(1) 메 인 분기 (master) 는 최신 버 전 코드 만 유지 합 니 다.(2) 배치 환경 은 여러 버 전 코드 를 동시에 사용 할 수 있 고 버 전 간 에 코드 가 호 환 되 지 않 는 상황 이 존재 합 니 다.(3) bug 는 비교적 오래된 버 전에 나타 날 수 있 습 니 다.
모든 버 전의 버그 복구 가 메 인 지점 에서 복구 지점 을 만 든 다음 메 인 지점 으로 통합 되면 코드 가 혼 란 스 러 울 수 있 습 니 다.
주 2: 개발 지점 에 통합 하면 새로 발 표 된 버 전에 복 구 된 버그 가 포함 되 지 않 습 니 다.
주 3: 특정 버 전의 Bug 를 복구 할 때 '큰' 버 전 번호 (1.2) 를 바탕 으로 '작은' 버 전 번 호 를 만들어 야 합 니 다.
Code Deploy
코드 배 치 는 원문 토론 범위 안에 있 지 않 지만 매우 중요 한 점 입 니 다. 여 기 는 자신의 방식 만 설명 합 니 다.
git clone git pull git checkout
주: 버 전 파일 의 버 전 번 호 를 통 해 구체 적 인 버 전 정 보 를 확인 할 수 있 습 니 다.
Git Flow 의 구체 적 인 방식 과 방법 은 차별 화 되 어 논란 이 많 으 니 지적 토론 을 환영 합 니 다.