우리 팀의 Git Flow 사용법
우리 팀은 개발을 이제 막 시작하는 단계입니다.
회의를 하며 팀 컨벤션을 정하던 도중, Git-Flow 도입에 대한 이야기가 나왔습니다.
전 대찬성이었습니다! 이런 방식으로 협업해보는 것도 하나의 경험이 될 수 있다고 생각했기 때문인데요.
이전에 사이드 프로젝트에서 살짝 Git-Flow의 맛을 본 적이 있는 터라, 팀원들과 공유하고 싶다고 생각했습니다.
그리고 아래는 저희 팀에서 사용하고 있는 Git-Flow 방식에 대한 이야기입니다.
저희 팀은 아래 그림처럼 크게 3가지 종류의 브랜치를 채택했습니다.
-
feature: 기능 하나를 개발하는 브랜치 (깃허브에 등록한 Issue 단위) -
develop: 가장 최신의 작업물을 담은 브랜치 -
master: 배포 버전 작업물을 담은 브랜치
❗️ 시중에 설명되는 Git-Flow 관련 자료들에는 위의 3가지 브랜치 외에도 release, hotfix 브랜치가 존재하는데, 현재 저희 팀의 개발 단계에서는 필요하지 않다고 판단해 제거했습니다.
저희 팀은 깃허브에 등록한 Issue 단위로 feature를 땁니다.
이해가 되시나요?
이슈를 생성했을 때 자동으로 붙는 이슈 번호가 바로 해당 이슈를 작업할 feature의 브랜치 번호가 되는 것입니다.
아래 실습을 통해 자세히 보여드리겠습니다.
처음 프로젝트를 만들었습니다. 브랜치는 master 브랜치 뿐입니다.
이 상태에서 develop 브랜치를 하나 더 만들어줍니다.
git checkout -b develop
그 다음, 해당 프로젝트를 깃허브 서버와 연결합니다.
이제 연결이 끝났습니다.
이 상태에서 Option + Shift + N을 누르면 앞서 등록한 첫 번째 이슈, 두 번째 이슈가 task로 뜨는 것을 보실 수 있습니다.
작업할 이슈를 더블클릭하면 아래와 같은 화면이 뜹니다.
먼저, 두 번째 이슈를 선택해보겠습니다.
여기서 두 가지 작업을 해야 합니다.
-
git-flow-2앞에feature/를 붙여주기.feature에 속하는 브랜치임을 알려주기 위해 붙입니다. feature라는 디렉토리 아래에 브랜치를 생성해주는 효과를 냅니다.
최종 브랜치명은
feature/git-flow-2또는 컨벤션에 따라 레포지토리명을 제외한feature/2와 같은 형태가 될 수 있습니다. 저희 팀은 후자와 같은 방식을 사용합니다. -
develop이 아닌,origin/develop선택하기최신 작업 상태가 있는
origin/develop브랜치로에서부터 feature 브랜치를 따야 합니다.
다음과 같이 변경했습니다.
자, 이제 작업을 합니다.
첫 번째 이슈도 위와 같이 만들어 작업을 합니다.
이렇게 동시에 두 작업이 진행되고 있습니다.
이제, feature/git-flow-2에서 작업한 것부터 develop 브랜치에 머지시켜 보겠습니다.
git push origin feature/git-flow-2
원격 저장소에 push한 후,
develop 브랜치로 PR을 보냅니다.
이렇게 보낸 PR을 팀원들이 Merge한다면,
그래프는 아래와 같은 형태가 됩니다.
이렇게 feature/2 (=feature/git-flow-2) 브랜치는 develop 브랜치에 머지 되었습니다!
feature/1에서도 PR을 날리기 전, 해야 할 작업이 있습니다. 바로,
git pull --rebase origin develop
입니다.
이렇게 하면 develop 브랜치의 최신 코드들을 pull하면서 feature/1의 base를 develop의 가장 최신 위치로 위치하게 됩니다.
이렇게 말입니다! 이 상태에서 feature/1 브랜치에서 보낸 PR이 develop 브랜치로 머지되면,
이런 형태가 됩니다! 아주 깔끔하죠? 🙂
이상으로 저희 팀의 Git-Flow 전략에 대한 이야기를 마치겠습니다.
참고