[GITHUB] 깃허브 브랜치 전략 - GITHUB FLOW

1. GITHUB-FLOW 전략

GITHUB-FLOW 전략

- GitHub flow는 Git flow가 좋은 방식이지만 GitHub에 적용하기에는 복잡하여 만들어진 새로운 깃 관리 방식

- Git flow에 비해 흐름이 단순해짐에 따라 규칙도 단순해졌다.

- 기본적으로 master branch에 대한 규칙만 정립되어 있다면 나머지 가지들에 대해서는 특별한 관여를 하지 않으며 pull request 기능을 사용하도록 권장

 

2. GITHUB-FLOW 특징

- release branch가 명확하게 구분되지 않은 시스템에서의 사용이 유용

- GitHub 자체의 서비스 특성상 배포의 개념이 없는 시스템으로 되어 있기때문에 이 flow가 유용

- hotfix와 가장 작은 기능을 구분하지 않는다.

 

3. GITHUB-FLOW

3-1. 브랜치 생성

GITHUB-FLOW 브랜치 생성

GITHUB-FLOW 전략은 기능 개발, 버그 픽스 등 어떤 이유로든 새로운 브랜치를 생성 하는 것으로 시작된다.

단, 이때 체계적인 분류 없이 브랜치 하나에 의존하게 되기 때문에 브랜치 이름을 통해 의도를 명확하게 드러내야한다.

 

- master 브랜치는 항상 최신 상태며, stable 상태로 product에 배포되는 브랜치이다. 이 브랜치에 대해서는 엄격한 role과 함께 사용된다.

- 새로운 브랜치는 항상 master 브랜치에서 만든다.

- Git-flow와는 다르게 feature 브랜치나 develop 브랜치가 존재하지 않는다.

 

3-2. 개발 & 커밋 & 푸쉬

개발을 진행하면서 커밋을 남긴다. 커밋 메시지를 최대한 상세하게 적어주는것이 중요하다.

 

- 커밋메시지를 명확하게 작성

- 원격지 브랜치로 수시로 push

- Git-flow와 상반되는 방식

- 항상 원격지에 자신이 하고 있는 일들을 올려 다른사람들도 확인 할 수 있도록 해준다.

- 이는 하드웨어 문제가 발생해 작업하던 부분이 없어지더라도, 원격지에 있는 소스를 받아서 작업 할 수 있도록 해준다.

 

3-3. PR(Pull Request) 생성

PR(Pull Request) 생성

피드백이나 도움이 필요 할 때, 그리고 merge 준비가 완료되었을 때는 pull request를 생성한다.

- pull request는 코드 리뷰를 도와주는 시스템

- 이것을 이용해 자신의 코드를 공유하고, 리뷰 받는다.

- merge 준비가 완료되었다면 master 브랜치로 반영을 요구한다.

 

3-4. 리뷰 & 토의

Pull Request가 master 브랜치 쪽에 합쳐진다면 곧장 라이브 서버에 배포되는 것과 다름 없으므로, 상세한 리뷰와 토의가 필요하다.

 

3-5. 테스트

테스트

리뷰와 토의가 끝났다면 해당 내용을 라이브 서버(혹은 테스트 환경)에 배포해본다.

배포시 문제가 발생한다면 곧장 master 브랜치의 내용을 다시 배포하여 초기화

 

3-6. 최종 Merge

최종 Merge

라이브 서버(혹은 테스트 환경)에 배포했음에도 문제가 발견되지 않았다면 그대로 master 브랜치에 푸시를 하고, 즉시 배포를 진행한다.

대부분의 github-flow에선 master 브랜치를 최신 브랜치라고 가정하기 때문에 배포 자동화 도구를 이용해서 Merge 즉시 배포 시킨다.

master로 merge 되고 push 되었을때는, 즉시 배포되어야한다.

 

4. GITHUB-FLOW vs GIT FLOW

- 1개월 이상의 긴 호흡으로 개발하여 주기적으로 배포, 테스트, HOTFIX 등 수행 할 수 있는 여력이 있다면 git-flow

- 수시로 릴리즈 되어야 할 필요가 있는 서비스를 지속적으로 테스트하고 배포하는 팀이라면 github-flow와 같은 간단한 work-flow가 적합하다.

 

참고 : https://inpa.tistory.com