TIL.81 Git Flow

이전까지는 프로젝트 진행간

main 과 feature 브랜치 단 2개만 사용하였다

하지만 Git Flow에서는 2개 말고도 Devlop, Hotfix, Release 로 

총 5개의 Branch가 존재한다.

https://gmlwjd9405.github.io/2018/05/11/types-of-git-branch.html

1. main branch

제품으로 배포/출시 할 수 있는 브랜치

가장 깨끗한 상태를 유지해야한다. 

main branch는 절대 배포가능한 상태만으로 존재해야한다.

 

2. Devlop branch

다음 출시 버전을 개발하는 브랜치

기능 개발을 위한 브랜치들을 병합하기 위해 사용하는 브랜치다.

원하고자 하는 기능을 추가하고 디버깅(QA)까지 하여 문제없이 동작된다고 판단할 경우 이 브랜치를 main브랜치에 Merge 한다.

 

만약 1.0 카카오톡을 메인에서 클라이언트들에게 배포를 마친 다음 개발자들은 무슨 일을 해야할까?

개발자는 이제 2.0을 준비하면 된다. 그동안 개발자들은 Devlop 브랜치에 PR을 계속 날리고 있을것이다.

따라서 실제로는 main에서 feature를 따지 않고 Devlop 에서 브랜치를 따서 사용해야 한다.

여지껏 Devlop 브랜치의 개념을 무시하고 작업하고 있었던 것이다.

 

3. Feature branch

feature 브랜치는 기능 개발 및 버그 수정이 필요할때마다 Devlop 브랜치에서 부터 분기하여 사용한다.

기본적으로 공유할 필요가 없어 로컬 저장소에서 관리하며 원학고자하는 기능을 모두 구현 하여을때 Devlop 브런치와 Merga하여 팀원과 공유하면 된다.

여기서 기능 개발 완료하고나서 더이상 필요하지 않는 feature 브랜치는 삭제한다.

feature brach name convention

main, devlop, release, hotfix - 제외

feature/기능요약 -> ex feature/signup 

 

 

실제 현업에서는 이와 같이 5가지의 모든 브랜치를 사용하니 반드시 각기 상황에 맞는 브랜치를 판단할 줄 알고 사용해야 한다.

 

4. Release branch 

이번 출시 버전을 준비하는 브랜치!

배포를 위한 전용 브랜치를 사용함으로써 한 팀이 배포를 준비하는 동안 다른팀은 다음 배포를 위한 기능 개발을 계속 할 수 있다.

 

위에서 추가 기능 개발을 완료된 상태의 Devlop 브랜치를 바로 main에 Merge 시키지 않고

Release 브랜치를 Devlop 브랜치에서 새로 따서 디버깅(QA)를 진행한다.

왜냐면 다른 팀원들이 각각 기능을 계속 Devlop로 Merge를 하고 있기에 Devlop 브랜치에서 버그 Fix를 할 수 없다.

이것이 Release 브랜치에서 디버깅을 진행하는 이유이다.

디버깅을 마무리하면 Devlop 브랜치는 Release를 다시 Pull 받고 

각 기능을 만들고 있는 개발자는 다시 한번 devlop 브랜치를 Pull 받아줘야한다

따라서 릴리즈 브랜치를 모두 디버깅을 완료하여 메인에 머지해서 배포한다!

 

5. Hotfix branch

출시 버전에서 발생한 버그를 수정하는 브랜치!

미처 QA에서 발견하지 못한 예기치 못한 에러를 확인하게 되는 경우가 있다.

대부분 이 경우 Devlop 브랜치에서 문제가 되는 부분을 수정하여 배포 가능한 버전을 만들기에 시간이 많이 소요되고 안정성도 보장하기 어렵기 때문에 Hotfix 브랜치를 새로 따서 문제가 되는 부분마 빠르게 수정한 후 main에 Merge 해준다

 

Hotfix 브랜치를 머지하면 당연히 Devlop이 다시 pull 해야하고 각 기능 개발자는 다시 pull을 받아야한다.

 

실제 현업에서는 이와 같이 5가지의 모든 브랜치를 사용하니 반드시 각기 상황에 맞는 브랜치를 판단할 줄 알고 사용해야 한다.

 

---

 

아래가 대표적인 Git flow이다.