github flow

 

git flow

우선 github Flow를 알기 전에 git flow를 먼저 알아보자.

 

git flow는 거의 사용하지 않지만 비교수단으로 github flow를 이해하기 쉽다.

 

- 우선 git flow는 5개의 브랜치로 나누어 진다.

- 주요 브랜치는 master과 develop 브랜치로 나머지는 보조 브랜치에 해당한다.

- release 브랜치는 배포(출시) 예정일때 사용하는 브랜치이다.

- feature 브랜치는 develop 브랜치에서 기능을 개발할때 사용한다.

- hotFix 브랜치는 master 브랜치에서 발생한 버그를 빠르게 수정할때 사용한다.

 

작업 순서는 다음과 같다.

1. master 브랜치에서 develop 브랜치를 생성해 개발을 시작한다.

2.배포 예정 준비 브랜치인 release 브랜치도 생성해서 대기한다.

3. develop 브랜치에서 feature을 통해 개발을 진행하고 계속해서 성공적인 개발상태로 업데이트 한다.

4. 배포가 가능한 상태가 되면 release 브랜치와 먼저 merge 한다.

5. release에서도 ok하면 master로 병합하고 버그가 발생하면 수정해서 develop에 다시 병합한다.

6. 배포가 완료되고 hotFix브랜치는 master에서 운영중 갑작스런 버그가 발생해서 다급하게 고치는 상황에 사용한다.

 

대충 살펴만 봐도 복잡하다. git flow와는 상반되는 github flow를 살펴보자. 요즘은 다 이거 쓴다고 한다.

 

github flow

 

- github flow는 다음과 같이 2개의 주요 브랜치만 운용한다.

- 배포의 개념이 없다. (항시배포/무중단배포)

 

github flow는 어떤 전략일까 ?

- master 브랜치는 항상 최신 상태이고, 항상 서비스중이라고 생각하면 된다.

- 개발할 상황이 생기면 어떠한 이유로든 새로운 브랜치를 생성하며 시작한다.

- 브랜치명을 명확하게 드러내야 한다. 주로 "(bug, documentation, enhancement)/1" 로 설정한다.

 git checkout -b enhancement/1

- 수시로 커밋하고 커밋메시지를 명확하게 작성한다. (자기가 하고 있는 내용을 모두 알 수 있게)

- master 브랜치에서 함께 작업하고 있는 팀원들이 계속해서 최신화하고 있을 수도 있으니 계속 최신화해준다.

  git pull origin main --rebase

- 개발을 완료했다면 원격지에 해당 브랜치 이름으로 push한다. (바로 main으로 못간다.) -------> 1번 실행 (PR)

git push origin enhancement/1

- master 브랜치에서 배포 자동화 도구를 통해 즉시 라이브 서버로 배포된다. (CI / CD)

 

의문이 생길 수도 있다. 그럼 너무 위험하지 않을까 ?

그래서 github flow는 2가지의 대비를 하고 있다.

 

1. 개발을 완료하고 master에 반영하기 전 PR(Pull Request)를 오픈한다. PR은 관계자들과 코드리뷰, 토의 등이 이루어지고 master에 반영해도 되는가를 의논한다.

 

2. PR에서 반영이 수락되면 해당 내용을 테스트 환경에 배포해본다. 배포시 문제가 생기면 master 브랜치의 내용을 다시 배포하여 초기화 시킨다.