[GIT] Git Flow | Github Flow 전략

Git Flow 개념

• git flow 전략이란 여러 개발자가 하나의 저장소를 사용하는 환경에서 저장소를 효과적으로 활용하기 위한 work-flow다.
• 브랜치 생성에 규칙을 만들어서 협업을 유연하게 하는 방법론을 말한다.

브랜치 종류

• master : 기준이 되는 브랜치로 제품을 배포하는 브랜치 | 실제 운영 환경
• develop : 개발 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 Merge
• feature : 단위 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop 브랜치에 Merge
• release : 배포를 위해 master 브랜치로 보내기 전에 먼저 QA(품질검사)를 하기위한 브랜치
• hotfix : master 브랜치로 배포를 했는데 버그가 생겼을 떄 긴급 수정하는 브랜치

git flow 과정

• master 브랜치에서 develop 브랜치를 분기
• 개발자들은 develop 브랜치에 자유롭게 커밋
• 추가로 기능 구현이 있는 경우 develop 브랜치에서 feature-* 브랜치를 분기한다.
  • 예를 들어 현재 프로젝트에서 카테고리 기능을 추가하려면 feature/cateogry 브랜치를 dev브랜치로부터 만듦
• 배포를 준비하기 위해 develop 브랜치에서 release-* 브랜치를 분기
• relase 브랜치에서 테스트를 진행하면서 발생하는 버그 수정은 release-* 브랜치에 직접 반영합니다.
• 테스트가 완료되면 release 브랜치를 master와 develop에 merge합니다.

여기서 주의해야 할 점은 master에 추가된 작업 내용이 있다면 반드시 dev 브랜치에도 merge 하여 sync를 맞춰줘야 한다.

그 이유는 다음과 같다

• Dev = Master + @ 여야 한다.
• 하지만 Dev != Master + @ 인 상황에서 누군가 Dev에서 신규 feature 브랜치를 딴다면 코드가 매우 꼬이게 된다.
• 하지만 hotfix가 있을 땐 master에 바로 merge하게 된다.
• 이땐 dev 브랜치에 master를 merge 후 모든 feature 브랜치가 dev 브랜치를 merge해야한다.

 

 

 

 

 

github flow

• Git-flow가 Github에서 사용하기에는 복잡하다고 나온 브랜치 전략이다.
• hotfix 브랜치나 feature 브랜치를 구분하지 않는다. 다만 우선순위가 다를 뿐
• 수시로 배포가 일어나며, CI와 배포가 자동화되어있는 프로젝트에 유용

 

Topic 브랜치

새로운 기능을 개발할 때에는 Topic 브랜치를 Main 브랜치로부터 생성한다. Git Flow의 Feature 브랜치와 동일한 역할을 한다. 또한 별도로 Hotfix 브랜치를 관리하지 않으며, 버그 수정도 Topic 브랜치에서 진행한다.

 

Topic 브랜치의 커밋은 기능이 완성되지 않았더라도 꾸준히 Push 한다. 노트북 분실, 작업 컴퓨터의 고장등의 위험으로 코드가 유실되는 것을 막아준다. 이것보다 더 중요한 이유는 꾸준히 Push 함으로써 구성원 모두가 끊임없이 커뮤니케이션 할 수 있게 해준다.

 

개발이 완료됐다면 PR을 통해 토론을 하고 코드리뷰를 받는다. 토론과 리뷰가 끝났다면 다른 사람들의 동의를 얻고 Main 브랜치에 자신의 topic을 merge한다. 

 

Github Flow는 하루에 변경사항을 작은 단위로 신속하고 자주 병합/배포 할 수 있는 구조로, 진정한 의미의 CI/CD를 실천하기 적합한 브랜치 전략인 것 같다.

사용법

1. master 브랜치는 어떤 때든 배포가 가능하다
   • master 브랜치는 항상 최신 상태며, stable 상태로 product에 배포되는 브랜치
   • 이 브랜치에 대해서는 엄격한 role과 함께 사용한다
   • merge하기 전에 충분히 테스트를 해야한다. 테스트는 로컬에서 하는 것이 아니라 브랜치를 push 하고 Jenkins로 테스트 한다
2. master에서 새로운일을 시작하기 위해 브랜치를 만든다면, 이름을 명확히 작성해야 한다.
   • 브랜치는 항상 master 브랜치에서 만든다
   • Git-flow와는 다르게 feature 브랜치나 develop 브랜치가 존재하지 않음
   • 새로운 기능을 추가하거나, 버그를 해결하기 위한 브랜치 이름은 자세하게 어떤 일을 하고 있는지에 대해서 작성해주도록 하자
   • 커밋메시지를 명확하게 작성하자
3. 원격지 브랜치로 수시로 push 하자
   • 항상 원격지에 자신이 하고 있는 일들을 올려 다른 사람들도 확인할 수 있도록 해준다
   • 이는 하드웨어에 문제가 발생해 작업하던 부분이 없어지더라도, 원격지에 있는 소스를 받아서 작업할 수 있도록 해준다
4. 피드백이나 도움이 필요할 때, 그리고 merge 준비가 완료되었을 때는 pull request를 생성한다
   • pull request는 코드 리뷰를 도와주는 시스템
   • 이것을 이용해 자신의 코드를 공유하고, 리뷰받자
   • merge 준비가 완료되었다면 master 브랜치로 반영을 요구하자
5. 기능에 대한 리뷰와 논의가 끝난 후 master로 merge한다
   • 곧장 product로 반영이될 기능이므로, 이해관계가 연결된 사람들과 충분한 논의 이후 반영하도록 한다
   • 물론 CI도 통과해야 함
6. master로 merge되고 push 되었을 때는, 즉시 배포되어야한다
   • GitHub-flow의 핵심이다
   • master로 merge가 일어나면 자동으로 배포가 되도록 설정해놓는다