[TIL] GIT-FLOW

Git에도 많이 활용되고 있는 방법론 같은 것이 있다고 한다. 그것이 바로 Git-flow, 한 번 알아보자

Git-flow

• Git이 활성화 되기 시작하던 때 쯤 Vincent Driessen이라는 사람이 블로그에 올린 내용이 퍼져 현재는 거의 표준과 같이 사용되고 있다고 한다

  • 즉, Git-flow는 기능이 아닌 방법론이며, 각자의 개발 환경에 따라 수정하고 변형해서 사용해야 함

• 브랜치 간의 엄격한 상호 규칙에 따라야하는 작업 흐름으로 개발 주기가 긴 프로젝트에 적합

운영 방식

• Git-flow는 총 5가지의 브랜치를 사용해서 운영을 함

  메인 브랜치

  

  • master : 기준이 되는 브랜치로 배포 가능한 상태만을 관리하는 브랜치
  • develop : 개발 브랜치로 이 브랜치를 기준으로 각자 작업한 기능을 Merge

  보조 브랜치

  

  • feature : 단위 기능을 개발하는 브랜치로 기능 개발 완료 시 develop 브랜치에 합침

    • 갈라져 나온 브랜치 : develop
    • 다시 merge할 브랜치 : develop
    • 브랜치 이름 규칙 : master, develop, release, hotfix를 제외

    

  • release : 배포를 위해 master 브랜치로 보내기 전 먼저 QA를 시행하기 위해 생성하는 브랜치

    • 배포 가능한 상태가 되면 masterㅂ 브랜치로 merge한 후 버전 태그를 추가

    • release 브랜치에서 발견된 버그의 수정사항은 develop 브랜치에도 merge를 수행해야 함

    • 갈라져 나온 브랜치 : develop

    • 다시 merge할 브랜치 : develop, master

    • 브랜치 이름 규칙 : release -*

    

  • hotfix : master 브랜치로 배포를 했는데, 버그가 생겼을 때 긴급하게 수정하는 브랜치

    • 갈라져 나온 브랜치 : master
    • 다시 merge할 브랜치 : develop, master
    • 브랜치 이름 규칙 : hotfix-

• 일단 master 브랜치에서 시작을 합니다.

• 그리고 develop 브랜치를 생성하고, 개발자들은 이 develop 브랜치에서 개발을 진행합니다.

• 개발을 진행하다가 회원가입, 장바구니 등의 기능 구현이 필요할 경우 A개발자는 develop 브랜치에서 feature 브랜치를 하나 생성해서 회원가입 기능을 구현하고 B개발자도 develop 브랜치에서 feature 브랜치를 하나 생성해서 장바구니 기능을 구현합니다.
  그 후 기능 구현이 완료된 feature 브랜치는 검토를 거쳐 다시 develop 브랜치에 합칩니다.(Merge)

• 이제 모든 기능이 완료되면 develop 브랜치를 release 브랜치로 만듭니다. 그리고 QA(품질검사)를 하면서 보완점을 보완하고 버그를 픽스합니다.

• 모든 것이 완료되면 이제 release 브랜치를 master 브랜치와 develop 브랜치로 보냅니다. master 브랜치에서 버전추가를 위해 태그를 하나 생성하고 배포를 합니다.

• 배포를 했는데 미처 발견하지 못한 버그가 있을 경우 hotfixes 브랜치를 만들어 긴급 수정 후 태그를 생성하고 바로 수정 배포를 합니다.

Github-flow

• Git-flow가 Github 환경에서는 사용하기 복잡하다고 판단되어 나오게 된 브랜칭 전략

  • master 브랜치의 역할이 정확하다면 나머지 브랜치들은 아무렇게나 되어도 상관이 없으며, Pull request를 사용하도록 권장
  • 수시로 배포가 발생하며, CI(지속적 통합)와 배포가 자동화 되어있는 프로젝트에 유용

  활용법

1. Master 브랜치는 언제나 배포가 가능

   • master 브랜치는 항상 최신 상태이며, 안정된 상태로 배포되는 브랜치

   • merge되기 전에 충분한 테스트가 있어야 함

2. Master에서 브랜치를 생성한다면 이름은 명확하게!

   • 브랜치는 항상 master 브랜치에서 생성
   • Git-flow와는 다르게 feature나 develop 브랜치가 존재 하지 않음
   • 새로운 기능을 추가 혹은 버그 해결을 위한 브랜치 이름은 상세하게
   • 또한, 커밋 메시지도 최대한 명확하고 상세하게 작성

3. remote 환경으로 수시로 push

   • 항상 remote repository에 자신이 하고 있는 일을 다른 사람이 확인할 수 있도록 해야함
   • 이를 통해, 작업하던 부분이 갑자기 상실되더라도, 소스를 받아서 작업이 가능

4. 피드백 혹은 merge 준비가 완료되었을 때에는 Pull request를 생성

   • Pull request를 통해 코드를 공유하여 리뷰를 받아서 완료 되면 master로 반영해줄 것을 요구

5. master로 merge되었을 때에는 즉시 배포

   • Github-flow의 핵심으로 merge가 될 경우 자동으로 배포가 되도록 설정

   Github Actions

   • Github에서 제공하는 Workflow 자동화 도구로, 테스트, 빌드, 배포등의 다양한 작업을 자동으로 실행할 수 있게 해줌

읽어보면 좋은 글:

https://woowabros.github.io/experience/2017/10/30/baemin-mobile-git-branch-strategy.html

출처 : https://ujuc.github.io/2015/12/16/git-flow-github-flow-gitlab-flow/