version tag 원칙

tag는 release 버전을 서버에 배포할때 조작한다.

• github repository에서 조작할 수 도 있고 local respository에서도 조작할 수 있다.

과정

1. develop에서 나가는 release 브랜치 생성
   • master: 제품으로 출시될 수 있는 브랜치
   • develop : 다음 출시 버전을 개발하는 브랜치
   • release : 이번 버전으로 출시하는 브랜치
   • hotfix : 출시 버전에서 발생한 버그를 수정하는 브랜치
   • git checkout -b relase develop
2. 이후 커밋한 내용은 이번 버전에 넣을 내용일 경우 release에 넣고 다음 버전에 넣어도 될 개발은 develop에 넣는다.
3. release를 master에 merge한다
   • [master] git merge --no-ff release
     • merge된 모든 커밋이 표시되며 Merge branch 'release' into master 문이 생성된다
4. master branch에 tag를 붙인다.
   • git tag -a 1.0.0
5. origin master에 push 한다.
6. develop에서는 master를 rebase한다
   • 다른회사의 gitflow를보면 develop에서도 위와같이 rebase없이 merge 하지만 이러면 merge message가 두개 뜨게되어 보기 좋지않기때문에 본인은 rebase를 택했다.

예시

develop의 rebase master 없이 merge하는 경우와 rebase 한 경우와 비교를 해보자.

먼저 다음의 공통 상황이후부터 차이가 시작된다.

1. master와 develop에 commit 1이 다음과 같이 들어있다
2. 새로운 개발 commit develop 2가 들어왔다.여기서 이제 새로운 버전을 생성하기로 하고 release branch를 열었다.
3. 이번 버전에 급하게 release하기위한 commit release 3가 생겨 release branch에 commit 했다.
   

   

   master

   

   release

no rebase

1. 이제 버전을 tag하기 위해 release를 develop과 master에 merge했다. 이후 release branch는 삭제한다.
2. 버전 업그레이드를 할 시기가 또 왔다. 현재 develop에는 develop 4 가 commit 되어있고 이 내용을 위와같이 release한 결과는 mster와 develop이 각각 다음과 같다.
   

   

   no rebase master

   

   no rebase develop

yes rebase

1. 이제 버전을 tag하기 위해 release 를 master에 merge한후 develop에는 master를 rebase 한다. 이후 release branch는 삭제한다.
2. 버전 업그레이드를 할 시기가 또 왔다. 현재 develop에는 develop 4 가 commit 되어있고 이 내용을 위와같이 release한 결과는 mster와 develop이 각각 다음과 같다.
   

   

   yes rebase master

   

   yes rebase develop