Git-Flow 전략으로 프로젝트 관리하기

지금까지 Git 브랜치를 활용하여 프로젝트를 관리해본 경험이 없었습니다. 개인 프로젝트의 경우 멋대로 main에 push를 했고, 팀 프로젝트의 경우에도 브랜치 전략을 사용하지 않고 관리했습니다. 그렇게 했음에도 큰 불편함이나 이슈가 없었던 건 어쩌면 그만큼 대단한 규모의 프로젝트가 아니었기 때문이 아닐까 생각이 드네요.

 

하지만 이제는 앞으로의 협업에서는 반드시 브랜치 전략을 사용하게 될 것입니다. 따라서 브랜치 전략에는 어떤 것들이 있나 살펴보고, Git-Flow 전략과 Github 전략에 대해 알아보려 합니다.

 

 

브랜치 전략

여러 개발자가 하나의 레포지토리를 효과적으로 활용하기 위한 워크플로우 입니다. 실제로 런칭되는 프로그램은 작은 이슈에도 민감하고 업데이트/유지보수가 계속해서 일어나면서 다양한 버전이 출시되기 때문에 프로젝트 관리를 보다 철저히 해야할 필요가 있습니다. 제가 지금껏 해온 것처럼 main 브랜치에 아무 코드나 때려 넣으면 안 되겠지요.

 

그래서 나타난 브랜치 전략은, 브랜치 생성에 대한 규칙을 만들어 협업하는 방법론입니다.

브랜치를 생성, 삭제, 병합해서 각 개발자들의 기능 구현을 관리하고 혼란을 줄여주는 역할을 하죠.

 

🎁 브랜치 배우기

 

 

 

Git-Flow 전략

많이들 알고 있을 Git-Flow 전략 도식화 입니다.

 

 

Git-Flow 예시

 

 

대표적으로 아래와 같은 다섯 개의 브랜치로 구분하여 작업합니다.

 

각 브랜치를 용도&범위로 나열하면 아래와 같습니다.

 

feature > develop > release > hotfix > master

 

master 브랜치가 최상단에 있고, 그 아래 hotfix, release, dev 브랜치가 있으며, dev 브랜치의 아래에 feature 브랜치가 존재합니다.

 

'최상단', '아래' 이런 용어들을 쓰는데다 도식화를 보면 어느 시점에 아래로 뻗어나 있어서 마치 폴더 구조처럼 main의 하위에 브랜치들이 존재한다고 생각할 수 있습니다. 하지만 그렇게 되어있진 않고요, 사실 브랜치라는 것 자체는 서로에게 귀속되지 않습니다. 그저 네이밍을 붙이고 정한 규칙대로 사용하다보니 하위, 상위의 개념이 생긴거죠.

 

그림을 보면 정말 "가지"처럼 하위의 하위에 생성되고 있지만 저건 개발 시점에 따라 브랜치를 생성하는 과정을 보여줄 뿐입니다. 다만 신경써야 할 부분은 브랜치를 생성할 때 현재 위치의 가장 최신 버전으로 만들어진다는 것 입니다. main 브랜치에서 새로운 브랜치를 만들면 해당 브랜치의 내용은 main 브랜치의 가장 최신 버전일테고, dev 브랜치에서 새로운 브랜치를 만들면 dev 브랜치의 가장 최신 버전의 코드가 담겨있습니다.

 

그러니 브랜치를 생성할 때 현재 위치를 늘 확인하고, 어떤 버전인지 확인하는 것은 습관처럼 지녀야 하는 필수 사항입니다.

 

이제 다시 각 브랜치의 역할에 대해 알아보겠습니다.

 

위 다섯 가지 중, master & develop 브랜치는 항시 유지되는 메인 브랜치이고

feature & release & hotfix 는 합병 되면 사라지는 보조 브랜치입니다.

 

이게 무슨 뜻이냐면, 브랜치라는 건 '00기능을 만드는 브랜치를 만들어야지~' 하고 만든 다음, 다 완성 되면 dev 브랜치와 내용을 합친 뒤 앞서 만든 00기능에 대한 브랜치는 삭제하게 됩니다. 대표적으로 feature 브랜치가 그런 용도이죠.

 

그런데 이와 달리 master 브랜치와 dev 브랜치는 늘 유지하고 삭제되지 않는 브랜치 입니다. 완성본을 담는 브랜치이기 때문이라고 유추할 수 있겠죠?

 

각 브랜치의 역할을 알고나면 금방 이해가 됩니다.

 

 

• master : 라이브 서버에 제품으로 출시되는 브랜치. 배포 가능한 상태만을 관리한다.
• develop : 다음 출시 버전을 대비하여 개발하는 브랜치. 통합 브랜치의 역할을 하고 평소 이 브랜치 기반으로 개발한다.
• feature : 추가 기능 개발 브랜치. develop 브랜치에 병합 된다.
• release : 다음 버전 출시를 준비하는 브랜치. develop 브랜치를 release로 옮긴 후 배포를 위한 최종적인 버그 수정을 하 master 브랜치로 병합 된다.
• hotfix : master 브랜치에서 발생한 버그를 수정하는 브랜치.

 

master와 develope 을 제외한 브랜치에서 담당하는 기능들은 다 완성하고 나면 dev에 합치고 없애도 되는 것들 뿐입니다.

 

이렇게 관리하면 모든 개발자가 각각 담당한 기능들을 제일 완벽한 상태에서 병합하고 테스트할 수 있겠지요.

 

그렇다면 브랜치 네이밍은 꼭 저렇게 작성해야 할까요? 

 

많은 개발자들이 사용하는 "전략"이기 때문에 모두가 규칙을 따르듯 통일해야 혼선이 없겠죠.

 

가장 중요한 master, develop, release-*, hotfix-* 제외한 브랜치는 자유롭게 이름 설정이 가능합니다. 나머지 기능 개발에 대한 브랜치는 어차피 기능을 개발하고 나면 지워지기 마련이니 프로젝트의 특성에 따라 가시성 좋게 정하면 되겠습니다.

 

마지막으로 총 정리하자면,

 

develop 브랜치에는 기존에 잘 작동하는 개발 코드가 담겨있고

보조 브랜치는 새로 변경될 개발 코드를 분리하고 각각 보존하는 역할을 합니다.

각각의 기능을 다 완성할 때까지 유지하고, 완성되면 develop 브랜치로 합병합니다.

 

✘ 보조 브랜치는 보통 개발자 레포지토리에만 있는 브랜치이며, origin에는 push 하지 않습니다!!! 절대로!!! ✘

 

🎁 브랜치 전략이란

🎁 Git-Flow 튜토리얼

🎁 브랜치 전략 정리(위 튜토리얼 번역)

 

 

 

간단한 예시

1.  기능 구현 및 배포

main → develop 생성 → feature 생성 → develop+feature 병합 → main+develop 병합 → feature 삭제

git checkout main // HEAD가 main을 가리킨다.(main에서 작업)
git checkout -b develop // main 브랜치에서 develop 브랜치를 생성하고 HEAD로 develop을 가리킨다.
git checkout -b feature_branch // develop에서 feature 브랜치를 생성하고 HEAD로 feature를 가리킨다.
# work happens on feature branch // feature 브랜치에서 기능을 구현한다.
git checkout develop // HEAD가 develop 브랜치를 가리킨다.
git merge feature_branch // develop 브랜치와 feature_branch 브랜치를 합병한다.
git checkout main // HEAD가 main을 가리킨다.
git merge develop // main 브랜치와 develop 브랜치를 합병한다.
git branch -d feature_branch // feature_branch를 삭제한다.

실제 프로젝트에서는 브랜치를 로컬에서 합병하지 않고 feature 브랜치를 push 하여 PR 요청을 합니다.

(PR 요청 과정)

 

2. Hotfix 수정 및 배포

git checkout main
git checkout -b hotfix_branch
# work is done commits are added to the hotfix_branch
git checkout develop
git merge hotfix_branch
git checkout main
git merge hotfix_branch

 

 

 

---

브랜치며, Git-Flow전략이며 불과 몇년 전까지만 해도 전혀 이해가 되지 않고 복잡하게 느껴지기만 했는데 실제로 몇번 협업을 하고나니 드디어 천천히 이해가 되네요. 그때는 저 간단한 도식화도 알아보지 못 하고 '대체 이게 뭐야?' 라고만 생각했었는데 신기하네요. 이런 전략이 존재하는 것도 너무 편리하고 좋은 것 같습니다. 앞으로 손에 익히는 연습을 해서 협업에서 깃 관련 실수를 하는 일은 절대 없었으면 좋겠습니다.