(git) git 브랜칭 전략과 git flow

기본브랜치

-master : 최종 릴리즈한 안정된 버전
-develop : 다음 릴리즈를 위한 개발 중인 최신 빌드

위 두 브랜치는 계속 존재한다.
아래 브랜치는 필요할 때 생성했다 master 나 develop 브랜치로 머지하고 삭제하는,
이벤트 성격의 브랜치이다.

-featrue : 특정한 기능을 위한 브랜치
 -develop 브랜치에서부터 가져오며, 다시 develop 브랜치로 머지한다.
 -develop 브랜치 이외의 브랜치와는 머지하지 않는다.
 -일반적으로 개발자의 로컬에서만 유지하고 origin에 푸시하지 않는다.
 -develop 브랜치에 머지하면 feature 브랜치는 삭제한다.


-release : 릴리즈 점검을 위한 브랜치
 -develop 브랜치에서 가져오며, develop 과 master 브랜치로 머지한다.
 -release-* 형태로 이름을 짓는다. 예를들어, 다음 릴리즈 버전이 1.2라면, release-1.2라고 한다.
 - 다음 릴리즈까지 개발이 최종 완료되었다고 판단하는 시점에서 브랜치를 생성한다.
 - 릴리즈 대상이 되는 feature 는 미리 develop에 머지되어 있어야 하고,
      다음에 릴리즈할 feature 라면 develop에 머지되어 있으면 안된다.
 - release 브랜치를 생성한 이후의 버그 픽스는, develop 이 아닌 release 브랜치에서 진행한다.
 - 릴리즈가 모두 준비되었다고 생각하면, release 브랜치를 master에 머지한다.
 - release 브랜치에서 버그 픽스한 것들을 develop 브랜치로 머지한다.
 - release가 종료되면, release 브랜치를 삭제한다.



-hotfix : 긴급 버그 픽스를 위한 브랜치 
 -master에서 가져오며, master와 develop 브랜치로 머지한다.
 -hotfix-* 형태로 이름을 지음
 -release 브랜치와  사용 방법은 동일하지만, 예상치 못한 긴급 버그 수정을 위해 사용한다.
 -release 와 마찬가지로, 소스 코드 내 버전 정보를 업데이트 한다.
 -작업이 완료되면, master에 머지하고 버전을 태그로 남긴다.
 -수정 사항을 develop 브랜치로 머지한다.
  만약 release 브랜치가 이미 존재하면, develop이 아닌 release 브랜치로 머지한다.
 - 핫픽스가 종료되면 브랜치를 삭제한다.


주의할점은 다음과 같다.
-브랜치를 머지할 때 --no-ff 옵션을 쓴다.
 fast forward 머징을 하지 않고, 머지 커밋을 생성하겠다는 의미다.
 머징 히스토리를 유지하기 위함이다.
-가능하다면 버전 정보는 소스 코드 내에서 직접 작성하지 않는다.
 버전과 관련된 정보를 찾아 현재 버전으로 업데이트하는 스크립트를 작성하자.

각 커맨드에 대한 간단한 설명은 다음과 같다.

$ git flow init
 git 저장소를 초기화하고  master, develop 브랜치를 생성한다.

$ git flow feature start iss511
 develop 브랜치로부터  feature/iss511란 이름의 브랜치를 따오고 체크아웃한다.

$ git flow feature finish iss511 
 feature/iss511 브랜치를 develop 브랜치에 머지하고, 브랜치를 삭제한다.

$ git flow feature track iss70
이미 origin에 존재하는 feature/iss70 브랜치를 가져오고 체크아웃한다.



댓글

이 블로그의 인기 게시물

(18장) WebSocekt과 STOMP를 사용하여 메시징하기

(네트워크)폴링방식 vs 롱 폴링방식

(ElasticSearch) 결과에서 순서 정렬