Git flow branch 전략

Git이란 분산형 버전 관리 시스템(Version Control System)의 한 종류이다.

Git 을 이용하면 하나의 프로젝트를 여러 사람들과 함께 효과적으로 관리하며 협업할 수 있고, 많은 회사들이 Git을 도입하여 실제 프로젝트에 적용하고있다.

Git은 저장소가 서버에 있는 SVN 과는 다르게 Git은 저장소가 로컬 피시(Local Repository)에 존재한다. 

그러면 Git Hub는 무엇일까? 그것은 원격 저장소(remote repository)를 만들어서 저장한 것이다.

협업을 위해서는 이 remote repository에서 commit 후 버전 저장 후  push 하여 소스코드를 remote repository로 이동시킨다.

글씨를 너무 못써서 다음부터는 타자로 대체해야겠다.

이때 git이 가지는 가장 큰 장점은 branch 모델을 가지고 있다는 것이다.

git의 기초에 대해서 배워보고자 한다면 생활코딩의 지옥에서 온 Git 페이지를 추천한다.

https://opentutorials.org/course/2708

 

git flow 전략에 대해 알아보기 전에 branch에 대해서 알아야 한다.

Git은 데이터를 Change Set이나 변경사항(Diff)으로 기록하지 않고 일련의 스냅샷으로 기록하게 된다.

branch는 변경 사항의 스냅샷에 대한 포인터라고 생각하면 된다. 코드상 새 기능을 추가하거나, 버그를 수정하려는 경우 변경 사항을 캡슐화하기 위해 새 branch를 생헝한다. 왜 branch를 생성할까? 불안정한 (아직 테스트 중인 소스코드)가 main 코드에 병합되는 것을 막고, main 코드에 병합하기 전에 다른 branch에 기록 시키고, 테스트할 수 있는 기회를 제공한다.

 

예를 들면 하기와 같이 2명의 다른 사용자가 master branch에 소스코드를 올리기 위해서 다른 가지 2개를 뻗어 최종적인 결과 스냅샷 포인트를 각각 master branch에 병합(merge)시킬 수 있다.

 

동그라미 크기는 무시해주자.

Master Branch가 뻗어가는 과정에서 '회사원1의 branch'와 '회사원2의 branch' 가 master branch에 합쳐지는 과정이다.

만약 Master Branch만을 가지고 두 회사원이 코드를 짠다면 어떻게 될까??
'회사원1'이 master branch를 건드린다면 계속적으로 master branch의 소스코드에 영향이 될것이고, '회사원2'가 소스코드를 짜는 과정도 master branch에 계속 영향을 주어서 서로의 코드가 꼬이는 경우가 발생할 수 있다.

 

이러한 branch를 새로 만들고 합치는 일종의 흐름 전략을 git flow 전략이라고 한다.

Vincent Driessen은 효과적으로 git 브랜치 전략을 사용하는 것에 대해서 제안을 했다.

하기는 Vincent Driessen가 제안한 전략이다.(https://nvie.com/posts/a-successful-git-branching-model/)

• master : 정식으로 배포되는 안정적인 버전의 소스코드가 관리된다. master 브랜치는 제품으로 출시할 수 있을만큼 안정성이 출분히 검증된 코드들만이 병합되어야 한다.
• develop : 다음 버전을 개발하는 브랜치로, 소스코드들이 끊임 없이 추가된다. 버그들을 수정하기 위한 코드와 새로운 기능을 추가하기 위한 코드,  성능 개선하기 위한 코드들이 검증이 완료되고 PR 요청을 거치게 되면 develop branch로 병합뇌다.
• feature : 단위별로 기능을 개발하는 브랜치로 완료되면 develop 브랜치와 병합된다.
• release : 배포 전 QA를 통해 버그를 찾아내는 브랜치로 develop에서 master로 병합되기전에 테스팅을 위한 브랜치라고 생각하면된다.
• hotfix : master 브랜치에서 발생한 버그를 긴급하게 수정하는 브랜치이다.

이때 master와 develop은 항상 유지되는 메인 브랜치이며, 그 외의 feature, release, hotfix는 필요한 기간에만 유지되는 보조 브랜치들이다.

 

메인 브랜치

메인 브랜치는 다음과 같은 과정을 거친다.

 

master branch는 항상 프로덕션 레벨로 유지가 된다. 

develop branch는 항상 다음릴리스에 대한 최신 개발 변경 사항을 제공한다. 

develop branch의 소스코드가 안정적인 지점에 도달하고 릴리즈할 준비가 되면 모든 변경사항을 master에 병합한다음 release 번호로 태그를 지정한다. 

보조 브랜치

보조 브랜치는 feature, release, hotfix branch 등이 있다.

feature branch는 develop branch에서 분기해서 다시 develop branch 로 다시 병합된다.

 

feature는 기능단위로 개발이 되며, 기능이 개발될 경우 develop으로 병합되거나, 폐기된다.

하기 명령어로 feature branch를 만들 수 있다.

$ git checkout -b feature기능1 develop
Switched to a new branch "feature기능1"

feature기능1 개발이 완료되면 develop branch로 병합해주고, feature기능1를 지워준다.

 

release branch의 경우에는 develop branch에서 분기 후 develop branch와 master branch에 병합시켜준다.

release branch의 명명규칙은 release-*를 따르며, qa작업이 끝나고 안정된 상태라고 판단되면 develop branch와 master branch에 병합 후 realease branch가 필요하지 않다 생각되면, 삭제해준다.

 

hotfix branch의 경우 master branch에서 분기해야한다.  이유는 master 프로덕션 레벨에서 발생된 버그를 빨리 수정해야하기 때문이다. 그리고 수정된 버그를 반영할때는 master와 develop branch에 동시에 해줘야한다. master branch에 반영된 정보를 develop branch도 알아야 하기 때문이다.

 

분기 명명 규칙은 'hotfix-*'를 따른다.

hotfix branch의 이점은 다른 이에 의해서 develop branch가 수정되는동안 hotfix branch를 통해 버그를 고치고 master와 develop에 빠르게 반영을 시킬 수 있다는 점이다. 

 

master에 1.2버전이 배포가 되었을때 hotfix를 통해서 버그가 수정된다면 다음 태그는 1.2.1로 변경해주면된다.

 

이러한 branch 전략을 바탕으로 한다면 좀 더 안정적이고 효율적이게 코드형상관리를 할 수 있을 것 같다.

 

ref

- https://hbase.tistory.com/60

- https://velog.io/@shin6403/Git-%EC%9D%B4%EB%9E%80

- https://backlog.com/git-tutorial/kr/stepup/stepup1_1.html

- https://ndb796.tistory.com/186

- https://flowerykeyboard.tistory.com/9

- https://git-scm.com/book/ko/v2/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EB%B8%8C%EB%9E%9C%EC%B9%98%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80

- https://mylko72.gitbooks.io/git/content/branch/branch_type.html