[프로젝트 관리] 브랜치로 팀원들과 업무 나누기

브랜치란?

브랜치는 내가 만든 기능이 혹시 제대로 작동하지 못하는건 아닐까 ... 하는 불안한 마음이 그대로 반영되어있는 것이라고 생각합니다. "버그가 매우 많을지도 모르는 기능을 하나 만들어 볼게요!" 라는 생각을 가지고 코드를 그대로 복사해서 별도로 작업하기 위한 것입니다.

브랜치의 종류

브랜치는 대표적으로 5가지의 종류가 있습니다. 물론, 팀 내부적으로 규칙을 정한 다음, 몇가지 종류를 더 추가해서 사용할 수 있습니다.

master 브랜치

프로젝트의 생성과 동시에 만들어지는 브랜치이며, 실제 배포를 위한 브랜치입니다.

hotfix 브랜치

master 브랜치에서 치명적인 에러가 발생한 경우에 빠르게 패치하기 위해서 사용하는 브랜치입니다. develop 브랜치를 제외하고, 유일하게 master 브랜치에서 직접 뻗어나오는 브랜치입니다.

$ git checkout -b hotfix/기능이름

develop 브랜치

프로젝트의 생성과 동시에 master 브랜치로부터 뻗어나오는 개발을 위한 브랜치입니다.

$ git checkout -b develop

feature 브랜치

개발 되어야 할 기능 하나당 하나씩 만들어야 하는 브랜치 입니다. develop 브랜치에서 뻗어나오는 브랜치입니다.

$ git checkout -b feature/기능이름

release 브랜치

develop 브랜치에서 어느정도 개발이 완료되면 끊어주면서, 버전을 지정하고, master 브랜치에 배포를 하기 위한 브랜치 입니다.

$ git checkout -b release/버전

브랜치 작업 순서

1. 프로젝트를 생성합니다. (팀장)

2. develop 브랜치를 생성합니다. (팀장)

3. feature 브랜치를 생성해서 일을 합니다. (팀원)

4. feature 브랜치에 작업한 내용을 반영합니다. (팀원)

5. feature 브랜치를 develop 브랜치에 반영합니다. (팀장)

6. release 브랜치를 생성합니다. (팀장)

7. release 브랜치를 master 브랜치에 반영합니다. (팀장)

팀원들과 업무 나누기

브랜치 관리의 핵심은 feature 브랜치 라고 생각합니다. 너무 큰 단위로 작업을 나누다 보면 팀원들간의 작업한 부분의 충돌이 많아져서 개발하는 속도가 늦어지게 됩니다. 따라서, 웹 개발의 경우를 예로 들자면 아래와 같이 브랜치를 나누어 볼 수 있을 것 같습니다.

미리 해야하는 작업

데이터 타입 정의 (scheme/XXX)

동시에 가능한 작업

서버 API 개발 (feat/api/XXX)
프론트 API 더미 데이터 개발 (feat/dummy/XXX)
프론트 API 호출함수 개발 (feat/callback/XXX)
프론트 샘플 화면 개발 (feat/wireframe/XXX)
프론트 실제 화면 개발 (feat/view/XXX)

하지만, 이건 어디까지나 웹페이지를 개발하는 웹개발자의 이야기에 해댱하는 브랜치 입니다. 팀별로 각각의 브랜치 종류를 지정하고, 문서화를 해 둔다면, 조금 더 작은 단위의 작업으로 탄탄한 개발을 해 나갈 수 있지 않을까요?

참조링크

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

Gitflow Workflow | Atlassian Git Tutorial