Github-flow에서 Git-flow로 변경됐지만 하나의 티켓을 처리하는 방법은 이전과 비슷합니다. 다만 티켓을 처리하는 개발자는 Github-flow를 하고 있을 때와는 다르게 관리되는 브랜치들이 늘어남에 따라 어느 브랜치에서 작업을 해야 하는지 항상 주의해야 합니다.
앞서 ‘작업을 할 때 지켜야 할 서로 간의 약속’에서 ‘하나의 티켓은 되도록 하나의 커밋으로 한다’라고 했습니다. 그래서 기능을 구현하기 전에 여러 개의 티켓으로 작업을 먼저 나누게 됩니다. 나눠진 작업 티켓 중 ‘로그인 레이아웃 생성’이라는 티켓이 있고 이 티켓을 처리한다고 가정하고 살펴보겠습니다.
upstream/feature-user 브랜치에서 작업 브랜치(bfm-100_login_layout)를 생성합니다.
http://woowabros.github.io/experience/2017/10/30/baemin-mobile-git-branch-strategy.html
티켓 처리하기
Github-flow에서 Git-flow로 변경됐지만 하나의 티켓을 처리하는 방법은 이전과 비슷합니다. 다만 티켓을 처리하는 개발자는 Github-flow를 하고 있을 때와는 다르게 관리되는 브랜치들이 늘어남에 따라 어느 브랜치에서 작업을 해야 하는지 항상 주의해야 합니다.
앞서 ‘작업을 할 때 지켜야 할 서로 간의 약속’에서 ‘하나의 티켓은 되도록 하나의 커밋으로 한다’라고 했습니다. 그래서 기능을 구현하기 전에 여러 개의 티켓으로 작업을 먼저 나누게 됩니다. 나눠진 작업 티켓 중 ‘로그인 레이아웃 생성’이라는 티켓이 있고 이 티켓을 처리한다고 가정하고 살펴보겠습니다.
upstream/feature-user 브랜치에서 작업 브랜치(bfm-100_login_layout)를 생성합니다.
작업 브랜치에서 소스코드를 수정합니다. (뚝딱뚝딱 :hammer:) 3.작업 브랜치에서 변경사항을 커밋합니다. (보통은 vi editor에서 커밋 메세지를 작성 함)
4.만약 커밋이 불필요하게 어려 개로 나뉘어져 있다면 squash를 합니다. (커밋 2개를 합쳐야 한다면)
6.작업 브랜치를 origin에 push합니다.
내식대로 이해
Feature Branch/jung-mh-Work-branch 만든다 커밋 여러개 하다가 Squash로 합치자(
rebase
이용) Feature 기준으로rebase
하자 Feature로 합처지는 PR을 합시다.별거아니구만