Git Flow

오늘은 Trello 만들기라는 새로운 팀프로젝트를 시작하며 프로젝트에 대한 설계를 진행했다. 그 중에서 깃 협업 전략으로 Git-flow 전략을 채택했다.

Git Flow란?

Git Flow란, 깃에서 제공하는 강력한 브랜칭 기능을 활용한 변경이력 관리 전략

다시 말해, Git으로 형상관리를 할때 브랜치를 효율적으로 관리하기 위해 사용하는 브랜치 관리 전략(Branch management strategy)이다.

Git Flow가 필요한 이유

프로젝트 규모가 작거나 혼자서 개발을 할 경우에는 branch도 필요 없이 혼자 main에서 작업한 뒤 배포해도 상관없다.
그러나 프로젝트의 규모가 커지고 팀원과 작업 할 경우 conflict를 해결해야 하는 상황이 생기며, 이슈가 발생했을 때 개발한 코드를 다시 되돌리고 등의 여러 불편함이 있다.
Git Flow는 이런 불편함을 최소화하고 효율적으로 협업하기 위해 생겨난 전략인 것이다.

그 중에서 배달의민족 우아한형제들은 어떤 전략을 사용하고 있는지 확인하며 공부했다.

Git Repository 구성

이전에 내가 포스팅 했던 내용과 같은 전략을 사용하고 있다. 그러나 아래 내용을 확인해보면 나오지만, 작업하는 사람의 이름으로 branch를 만드는 것이 아니라 기능에 따라 branch 이름을 정한다. 누구나 알아보기 쉽다는 장점이 있다.

Git branch 종류

항상 유지되는 메인 브랜치들(master, develop)과 일정 기간 동안만 유지되는 보조 브랜치들(feature, release, hotfix).

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

Git Flow 전략

작업 약속

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

예시

티켓 중 ‘로그인 레이아웃 생성’이라는 티켓이 있고 이 티켓을 처리한다고 가정하고 살펴보겠습니다.

1. upstream/feature-user 브랜치에서 작업 브랜치(bfm-100_login_layout)를 생성합니다.
   (feature-user)]$ git fetch upstream
(feature-user)]$ git checkout -b bfm-100_login_layout –track upstream/feature-user

2. 작업 브랜치에서 소스코드를 수정합니다. (뚝딱뚝딱 :hammer:)

3. 작업 브랜치에서 변경사항을 커밋합니다. (보통은 vi editor에서 커밋 메세지를 작성 함)
   (bfm-100_login_layout)]$ git commit -m "BFM-100 로그인 화면 레이아웃 생성"

4. 만약 커밋이 불필요하게 어려 개로 나뉘어져 있다면 squash를 합니다. (커밋 2개를 합쳐야 한다면)
   (bfm-100_login_layout)]$ git rebase -i HEAD~2

5. 작업 브랜치를 upstream/feature-user에 rebase합니다.
   (bfm-100_login_layout)]$ git pull –rebase upstream feature-user

6. 작업 브랜치를 origin에 push합니다.
   (bfm-100_login_layout)]$ git push origin bfm-100_login_layout

7. Github에서 bfm-100_login_layout 브랜치를 feature-user에 merge하는 Pull Request를 생성합니다.

8. 같은 feature를 개발하는 동료에게 리뷰 승인을 받은 후 자신의 Pull Request를 merge합니다. 만약 혼자 feature를 개발한다면 1~2명의 동료에게 리뷰 승인을 받은 후 Pull Request를 merge합니다.

위의 절차에서 4, 5번의 작업을 수행하는 이유는 커밋 그래프를 단순하게 가져가고 의미 있는 커밋들로 관리하기 위해서입니다.

rebase 주의사항

1) Rebase는 히스토리를 지운다. 이로인해 Conflict가 날수도 있고, 데이터의 유실이 일어날 수 있다.

2) 다른사람이 그 Branch에서 작업중일 수도 있기 때문에 공개된 (다른사람들이 접근할 수도있는) Branch에서 Rebase하면 안된다.

이번 팀프로젝트에서는 Git Flow 전략을 사용하며 익숙해지는 시간이 되길 바란다.

<출처>

• "우린 Git-flow를 사용하고 있어요", 우아한기술블로그
• "Git의 Merge와 Rebase의 차이", sweet_sumin.log
• "Git Flow란, 깃 브랜치 전략", 푸르고 개발 블로그