[Git] 팀 프로젝트 Git 브랜치 전략 (기능 추가)

의미있는 단위로 브랜치를 생성, 관리하고, 가독성이 좋은 형태의 브랜치의 구조를 만들기 위해서 브랜치 관리 전략 중 Git-flow 에 대해서 알아보고, 프로젝트에 적용할 수 있는 방식을 고민해보았다.

 

Git-flow 에서 제시하는 branch 생성 방식은 아래와 같다.

 

master : 실제 배포 버전이 있는 브랜치, 실 서비스에 사용되는 제품을 의미한다.

hotfix : 배포 버전에서 발생하는 버그 중 긴급하게 수정이 이루어지는 브랜치

develop : 버전 업그레이드를 위해 기능 추가, 수정 사항이 반영되는 등의 개발이 이루어지는 브랜치

feature : 개발 단계 별 추가, 수정되는 기능 개발이 이루어지는 브랜치

release : 다음 배포 버전에 포함될 기능 개발이 끝난 후 QA 가 이루어지는 브랜치

 

 

 

흔히 프로젝트를 진행하면서 git branch 전략을 적용하자는 것에는 이견이 없다는 것을 알지만 단순히 개발자의 작업 영역을 나눈다던가, conflict 가 안나는 브랜치 병합만을 보며 브랜치 관리가 제대로 이루어지고 있다고 생각하는 것은 바람직하지 않다고 생각한다.

 

그보다는 제품 개발의 타임라인을 파악하고, 브랜치의 존재 의미를 살릴 수 있는 방법으로 브랜치를 관리하는 것이 옳다고 생각한다.

 

그러기 위해서는 브랜치를 나누는 것에서 그치는 것이 아닌 브랜치의 의미를 살릴 수 있는 병합 및 커밋 방식을 지향해야할 것이다.

 

Git-flow 적용

위에서 보여지는 그림과 동일한 형태의 branch 를 생성하기 위한 코드를 작성하였다.

 

git-flow 전략을 실천하기 위한 코드는 우아한 형제들 기술 불로그 를 참고하였다.

 

아직 확정난 것은 아니지만  당장의 제품 크기가 작은 우리 프로젝트를 고려하면 release 나 hotfix 와 같은 브랜치는 브랜치 전략이 익숙하지 않은 나를 포함한 팀원들에게 혼란을 가중시킬 것이라고 판단하여 실제 적용 단계에서는 master, develop, feature 브랜치를 관리할 예정이다.

 

또한 upstream repo 에서 fork 를 수행한 original repo 에 개인 작업을 진행하고, upstream repo PR 을 날리는 방식을 채택하려고 했으나, 역시 브랜치 관리 방식이 익숙치 않아 이를 고려하여 upstream repo 에서만 작업을 진행할 예정이다.

 

본 게시글에서 프로젝트 진행 간 사용되는 브랜치 관리 방식을 재고하기 위해 시나리오를 설정하고, 이에 따른 메뉴얼을 작성할 예정이다.

 

feature branch 관리

1. 다수의 인원이 하나의 feature branch 에 병합을 시도할 때는 병합 후 결과가 하나의 브랜치로 표현이 되어야한다.

- 제품의 입장에서는 하나의 기능이 최소단위라고 볼 수 있다. 따라서  커밋이 가장 많이 나오는 영역이라고 할 수 있고, 이 때 개발자 개개인의 병합 커밋 내역이 남는 것은 브랜치의 구조를 복잡하게 만든다고 생각한다.

 

따라서 rebase 기능을 통해 개별 feature branch 를 단순하게 관리한다.

 

[시나리오]

이번 개발 단계에서 user 기능을 추가할 예정이다.

psh, ryu 두 개발자가 본 기능을 개발하기로 배정이 되었고, 각자 동시에 개발을 시작하였다.

 

branch 현황

psh 

(현재 local branch) 명령어 순

0. (feature-user)$ git fetch upstream : 수정사항 확인, feature-user 브랜치의 가장 끝에서 추가적인 개발을 시작한다.

1. (feature-user)$ git checkout -b f_test_psh : 개발자의 local 브랜치 생성

2. 개발...

3. (f_test_psh)$ git commit -m "commit message" 혹은 gui 도구에서 커밋 수행

4. (f_test_psh)$ git pull --rebase upstream feature-user : rebase 작업을 통해 현재 작업 브랜치의 타임라인을 feature-user 브랜치 이후로 옮긴다.

5. git push upstream f_test_psh : upstream repo 에 브랜치를 반영하고, feature-user 에 PR 을 날린다.

 

단 PR 을 승인하는 과정에서 두 가지 선택(squash 제외)을 할 수 있는데

1. merge (no fast forward merge 방식?), 각 개발자의 커밋 이력이 rebase 된 형태로 이어진다.

2. rebase and merge, feature-user 브랜치가 개발자의 최종 커밋을 rebase 한 채로 merge 된다. -> 위 사진에서 보는 feature 브랜치 형태

 

우리 프로젝트에서는 2번을 사용하여 위 그림과 같이 브랜치 구조를 형성할 예정이다.

 

ryu

현재 psh 개발자가 먼저 개발을 마치고 feature-user 에 반영을 한 상태이고, ryu 개발자가 그 뒤에 반영할 예정이다.

 

위 psh 개발자와 단계별 수행 모습은 일치하겠지만 한 가지 다른점은, ryu 개발자는 4번 단계에서 실제로 rebase 가 일어나는 것을 확인할 수 있을 것이다.

git rebase

 

develop branch 관리

[시나리오]

feature-user 의 기능 개발이 모두 끝났다!

따라서 develop 브랜치에 기능을 반영하면 된다.

 

0. (some branch)$ git checkout develop

1. (develop)$ git fetch upstream

2. (develop)$ git merge --no-ff upstream/feature-user : 기능 개발 부분은 feature-user 브랜치가 fast-forward 할 지라도 병합 커밋을 남기겠다는 의미로, 기능 단위로 개발 이력을 관리하는 것은 개발 단계에서 중요한 부분이기 때문에(기능이 개발의 최소 단위이기 때문) 병합 기록을 남기도록 한다.

3. (develop)$ git push upstream develop

 

master branch 관리

사실 release, hotfix 브랜치가 없는 상황에서 master 브랜치는 remote 의 develop 브랜치를 PR 하여 병합하면 된다.

 

실제로도 그렇게 진행해볼 예정이고, MVP 가 나온 이후에 테스팅 환경에서 다른 브랜치가 필요하다고 판단되면, 브랜치를 더 추가하여 적용해보는 과정을 거치려고한다.

 

잘못된 정보가 있다면 댓글로 알려주시면 감사하겠습니다!!