카테고리 없음

git-flow

규몽 2020. 11. 25. 21:00

오늘 협업 프로젝트 git 설정을 했다.

branch에 대해 수박겉핥기 지식이었던 나는 엄청 헤매었지만 이제 어느정도 알게되었다.

 

정리하자면 우선 git-flow에 대한 구성으론 Repository는 Upsteam Repository, Origin Repository, Local Repository 이렇게 3부분으로 구성되고 Upstream 리포짓은 개발자들이 공유하는 저장소로 최신 소스코드가 저장되어있는 원격 저장소다. Origin Repository는 업스트림을 포크한 원격 개인저장소고 Local은 말그대로 내 컴퓨터 로컬에 있는 저장소다.

 

 

작업방식은 Local 리포짓에서 작업을 완료한 후 작업 브랜치를 origin 리포짓에 push 한다. 그리고 github에서 origin 리포짓에 푸시한 브랜치를 업스트림 리포짓으로 머지하는 pull Request를 생섯하고 코드리뷰를 거친 후 merge 한다. 새로운 작업을 할때는 Local 리포짓에서 업스트림 리포짓을 pull한다. 

 

이러한 방식은모두가 공유하고 있는 리포짓에서 뭘 막 할순없으니 포크한 리포짓을 두면 이것 저것 해볼 수 있어서다.

 

작업하면서 지켜야할 서로간의 약속

  • 작업을 시작하기 전에 JIRA 티켓을 생성한다.
  • 하나의 티켓은 되도록 하나의 커밋으로 한다.
  • 커밋 그래프는 최대한 단순하게 가져간다.
  • 서로 공유하는 브랜치의 커밋 그래프는 함부로 변경하지 않는다.
  • 리뷰어에게 꼭 리뷰를 받는다.
  • 자신의 Pull Request는 스스로 merge 한다.

Git-flow 작업 전략

git-flow에는 5가지 종류의 브랜치가 존재한다. 항상 유지되는 메인 브랜치(master,develop)과 일정 기간 동안만 유지되는 브랜치들(feature, release, hotfix)가 있다.

 

  • master : 제품으로 출시될 수 있는 브랜치
  • develop : 다음 출시 버전을 개발하는 브랜치
  • feature : 기능을 개발하는 브랜치
  • release : 이번 출시 버전을 준비하는 브랜치
  • hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치 

 

일반적인 개발 흐름으로 살펴보겠습니다.
처음에는 master와 develop 브랜치가 존재합니다. 물론 develop 브랜치는 master에서부터 시작된 브랜치입니다. develop 브랜치에서는 상시로 버그를 수정한 커밋들이 추가됩니다. 새로운 기능 추가 작업이 있는 경우 develop 브랜치에서 feature 브랜치를 생성합니다. feature 브랜치는 언제나 develop 브랜치에서부터 시작하게 됩니다. 기능 추가 작업이 완료되었다면 feature 브랜치는 develop 브랜치로 merge 됩니다. develop에 이번 버전에 포함되는 모든 기능이 merge 되었다면 QA를 하기 위해 develop 브랜치에서부터 release 브랜치를 생성합니다. QA를 진행하면서 발생한 버그들은 release 브랜치에 수정됩니다. QA를 무사히 통과했다면 release 브랜치를 master와 develop 브랜치로 merge 합니다. 마지막으로 출시된 master 브랜치에서 버전 태그를 추가합니다.

 

 

여기까지가 기술 블로그를 참고하여 작성한 글이고 실제로 내가 협업하는 프로젝트에서는

master에서 시작된 develop 브랜치 에서 이제 기능을 개발할 때 feature 브랜치를 생성한다. ex) feature/login

그런다음 기능을 완료한뒤 push origin feature/login을 해준다.

그다음 pull request 요청을 한 뒤 리뷰어가 보고 커밋을 남기고 반영되면 머지를 한다. 이런식으로 작업을 한다!

 

참고링크 : 우아한 형제들 기술 블로그