Git flow strategy

|  GIT 이란?

프로젝트의 어떤 부분도 겹쳐쓰지 않게 프로젝트의 변경을 관리하는 버전 관리 소프트웨어이다.

회사에서 깃을 사용하지 않는다면? A님과 B님이 같은 웹사이트에서 게시판 페이지를 업데이트하고 있다고 가정해보자. A님이 무언가를 변경하고 저장한 다음 웹사이트에 업로드한다. A님 혼자 일을 한다면 문제가 없다. 문제는 B님과 함께 게시판 페이지의 이슈들을 처리해야 할 때이다.  A님이 이슈a를 처리하고 사이트 업데이트 했다. 그리고 B님이 이슈b를 처리하고 사이트를 업데이트 했다. 결과적으로 이슈b는 처리되었지만 B님이 사이트를 업데이트 하기전 처리되었던 이슈a가 작업하기 전 상태로 돌아갔다. 같은 페이지에서 작업을 하기 때문에 누군가의 작업은 겹쳐쓰여지거나 지워질 것이다.

깃을 사용한다면? A님과 B님은 같은 페이지에 각자의 수정사항을 각각 업로드할 수 있고, 깃은 두 개의 복사본을 저장한다. 나중에, A님과 B님은 어떤 작업도 잃어버리지 않고 변경사항들을 병합할 수 있다. 깃은 이전에 만들어진 모든 변경사항의 스냅샷을 저장하기 때문에 이전 시점의 어떤 버전으로 되돌릴 수도 있다.

|  Before getting into GIT!

버전관리(Version Control): 깃이 서비스되도록 고안된 목적. MS 워드 작업할 때, 변경 사항을 저장하면 이전 파일 위에 겹쳐쓰거나 여러 버전으로 나누어 저장한다. 깃을 사용하면 그럴 필요가 없다. 프로젝트 히스토리를 스냅샷으로 유지하므로 잃어버리거나 겹쳐쓰지 않을 수 있다.

저장소(Repository): 프로젝트가 거주(live)할 수 있는 디렉토리나 저장 공간. 깃허브 사용자는 종종 repo로 줄여서 사용한다. 당신의 컴퓨터 안의 로컬 폴더가 될 수도 있고, 깃허브나 다른 온라인 호스트의 저장 공간이 될 수도 있다.

커밋(Commit): 작업한 내용을 로컬 저장소에 저장, 소스 코드의 수정 내용은 커밋 단위로 관리 / 커밋 명령으로 깃은 저장소의 히스토리를 스냅샷으로 찍어, 프로젝트를 이전 시점으로 복원할 수 있는 체크포인트를 가질 수 있다.

 

브랜치(Branch): 작업자들은 메인 프로젝트(보통 마스터)의 브랜치를 따와서(branch off), 자신이 변경하고 싶은 자신만의 버전을 만든다. 작업을 끝낸 후, 프로젝트의 메인 디렉토리인 master에 작업했던 브랜치를 다시 merge한다.

 

|  git flow model

git flow란 저장소를 보다 고수준으로 관리하기 위한 브랜칭 기법이다. Git이란 개념도 이미 충분이 복잡한데 굳이 더 프로젝트를 복잡하게 관리할 필요가 있나 싶을 수도 있지만, 프로젝트의 규모가 점점 커지고 많은 인원들이 코드에 동시에 접근하면서 필연적으로 문제가 발생하게 된다. 따라서 현재 내 브랜치가 어떤 문맥에서 생겨나게 됐는지 파악하기 위해 Git Flow에 대한 이해는 반드시 필요하다.

git flow model은 2개의 핵심 브랜치와 3개의 서브 브랜치 총 5개의 브랜치를 가진다.

2개의 핵심 브랜치는 항상 유지되어야한다. (추가적으로 생성되거나 삭제되지 않는다.)

 

1.      master 

Ø  모든 테스트 등이 끝나고 상용화가 가능한 최종 브랜치

Ø  실제 클라이언트들이 이용하는 서비스

 

 

2.      develop 

Ø  현재 개발이 진행 중인 브랜치

Ø  다음 버전 개발

Ø  마스터에서 분기

Ø  상시 버그를 수정한 커밋들이 추가됨

 

 

3.      feature 

Ø  새로운 기능 추가 브랜치

Ø  develop 브랜치에서 파생되며 develop에 병합된다.

Ø  Remote repo에는 업데이트 할 필요는 없고 보통 local에만 존재

Ø  브랜치의 이름은 master,develop,release,hotfix 를 제외한 어떠한 이름이든 가능

Ø  가장 많이 삭제되고 생성되는 브랜치

 

4.      release 

Ø  이번 버전 출시 전 QA를 위한 브랜치

Ø  지금까지 작업한 내역을 develop 브랜치에서 따와 배포하기 전 테스트하며 발견되는 버그들을 수정

Ø  배포 준비가 완료되었다면 master 브랜치와 develop에 병합

 

5.      Hotfix

Ø  갑자기 오류가 나서 디버그해야하는 경우와 같이 긴급하게 코드를 수정해야 하는 경우의 사용하는 branch

Ø  master 브랜치에서 파생

Ø  수정된 버그들을 반영하기 위해 develop와 master 두 개의 브랜치에 병합된다.

Ø  release 브랜치가 존재한다면 거기에도 반영되어야 한다.