개요
최근 면접에서 ‘혹시 Git을 사용할 때 어떤 브랜치 전략을 사용하고 있어요?’라는 질문을 받았다. 사실 이 말을 듣고서 말문이 막힐 뻔했다. 실제로 브랜치가 무엇이고 어떻게 사용하는지는 알고 있었지만 팀플에서나, 아니면 개인 프로젝트를 할 때 브랜치를 쓰는 일이 거의 없었기 때문이다.
있었다고 해봤자 뭔가 다른 팀원이 내 커밋을 반영할 때 이후 오류가 날까 두려워 간이 브랜치를 사용한 적이 있었던 것 같다. 그리고 그 밖에 기능별로 간단히 브랜치를 나눴다던가 하는 아주 기초적인 조작으로밖에 브랜치를 운영해보지 않았다.
면접에서는 저는 기능별로 브랜치를 사용하고 있다. 라는 두루뭉실한 대답만을 했을 뿐, 내가 실제로 그것을 어떻게 사용했는지에 대해서는 잘 말하지 못했다.
면접을 보고 난 뒤 면접관님이 나에게 ‘Git 브랜치 전략 중 Git Flow에 대해서 공부하는 게 좋을 거 같다.’라고 조언을 해주어서 면접이 끝난 다음 바로 찾아보았다.
이 글은 그 시간에서 좀 한참 뒤?(라고 말해봤자 2주 전이지만)이지만 기록해 놓는 것이 중요할 것 같아 적어두기로 하였다.
GIT FLOW는?
GIT FLOW는 실제로 현업에서 자주 사용되고 있는 전략인 것 같다. GIT FLOW는 Vincent Driessen이 구상한 Git 브랜치 모델이다.
GIT FLOW는 실제로 5가지의 브랜치로 나눠서 프로젝트를 관리한다.
- feature 브랜치(들) : 개발자들이 실제로 프로젝트를 진행하며 프로젝트의 각 부분의 기능 구현을 할 때 사용하는 브랜치다. 프로젝트를 제작할 때는 프로젝트에 포함되어야 하는 여러 가지 기능을 구현해야 하기 때문에 각 기능 별로 feature 브랜치를 나누어서 각 기능 전담 개발자가 해당 브랜치에서 개발을 시작한다.
- develop 브랜치: 각 기능에 대한 개발이 완료되었을 경우 해당 기능이 develop 브랜치에 merge된다. 그렇기 때문에 개발자는 feature 브랜치(들)에서 기능 구현을 완료하고 develop 브랜치에 merge 하여 기능을 구현할 때마다 feature 브랜치를 제거한다.
- release 브랜치(들): develop 브랜치에서 모아놓은 프로젝트 기능들을 다시 release 브랜치(들)에서 가져와 테스트를 시작한다. 이 과정에서 여러 가지 버그를 마주하게 될 수도 있다. 그리고 이러한 버그들을 고친 뒤 다시 develop 브랜치에 merge한다.
- master 브랜치: 사용자에게 서비스가 제공되고 있는 프로젝트 파일이 보관되어 있는 브랜치. 그러므로 실사용 중인 애플리케이션에서 문제가 생겼을 경우 master 브랜치에서 해당 오류를 확인한다.
- hotfixes 브랜치(들): master 브랜치에서 오류가 생길 경우 그 오류를 해결하기 위해서 만들어지는 브랜치(들). hotfixes 브랜치(들)에서 master 브랜치의 오류를 해결하면 master 브랜치와 develop 브랜치로 동시에 merge를 진행하여 hotfixes 브랜치(들)에서 해결된 내용이 빠르게 반영될 수 있도록 한다.
여기서 다른 branch 전략에 관한 내용을 쉽게 이해할 수 있지만 hotfixes 브랜치의 merge 전략에 의아함을 가질 수도 있을 것이다.
‘hotfixes 브랜치에서 문제를 해결했다고 하더라도 바로 master 브랜치로 merge를 보내도 괜찮을까?’
하지만 이러한 질문의 답은 해당 버그가 hotfix 버그라는 데에 초점을 맞추면 된다. 만약 develop 브랜치에만 해당 내용을 보냈을 경우에는 다시 release 브랜치(들)에서 테스트를 하고 검증을 거쳐야 경우 master 브랜치에 올려질 수 있을 것이다.
유저가 실시간으로 문제를 겪고 있음에도 불구하고 말이다!(특히 송금 문제라면 어떨까?)
그래서 일단 master 브랜치에 merge를 하여 급한 불을 끈 다음 차후 테스트를 거쳐 hotfix 버그에 대한 탄탄한 준비를 갖춘다고 보면 되겠다.
물론 해당 전략은 상황에 따라 달라지므로 스스로 판단하여 좋은 브랜치 전략을 운영하는 것이 좋을 것 같다.
이렇게 Git Flow 전략에 대해서 간단하게 알아보았다. 개념만 알면 정말 쉬운 내용이다.
하지만 실전에서 이를 어떻게 활용할 것인가?
실전
실전에서는 그럼 브랜치를 만들기 위해서 git branch develop 같은 명령어를 일일이 입력해야 하고 merge 명령어도 일일이 입력해야 하니까 정말 귀찮을 수 있겠다라는 생각이 든다.
다행히 git flow를 편하게 운용할 수 있게 하기 위한 git flow 도구를 제공한다.
도구는 다음 링크에서 다운 받을 수 있다.
그렇기 때문에 본인은 간단하게 해당 툴을 활용하여 로컬 실습을 진행해 보겠다.
일단 먼저 나의 컴퓨터는 M1 맥북을 사용하고 있기에 homebrew 설치 도구를 활용하여 git flow 도구를 설치하였다.
설치가 끝나고 git flow를 실습할 디렉토리를 따로 만든 뒤(본인은 git_flow 폴더에서 진행하였다.) 다음과 같은 명령어를 입력한다.
git flow init
그럼 feature, bugfix, develop 같은 기본 브랜치의 이름을 정할 수 있다.
해당 브랜치의 이름을 수정하지 않는 것이 git flow 운영의 적합하다고 하여 수정하지 않고 진행하였다.
만약 git branch 명령어를 사용해 보면 당황할 수 있을 것이다.
‘아니 아까 브랜치 이름을 다정했고 그러니까 그걸 바탕으로 브랜치가 5개 이상 생성되어야 하는 것이 아닐까?’ 라고 생각할 수 있지만, 당황하지 말자. 일단 git flow의 브랜치는 기본적으로 develop에서 시작하고 거기서 차차 release, master 브랜치로 발전해 나가는 것이다.
그러므로 초반에는 develop 브랜치로 시작하다가 master 브랜치로 나아가는 모습을 보여줄 예정이다.
그렇기 위해 일단 vi 명령어로 간단한 텍스트 입력 파일을 생성하였다.
그리고 해당 develop 브랜치에 커밋하여 초기 값을 생성하자.
이제 본격적인 feature 브랜치를 사용해 보자.
git flow 도구를 사용하면 좋은 점은 git을 사용하는 사용자가 일일이 feature, release 같은 여러 브랜치들을 만들고 각 브랜치 마다 해당되는 큰 줄기에 merge를 해줄 필요가 없다는 것이다.
이 모든 과정을 git flow는 한 줄의 명령어로 이루어 낼 수 있게 구현되었다.
feature 브랜치를 생성하고 싶다면 다음과 같은 명령어를 입력하면 된다.
git flow feature start 생성하고 싶은 브랜치 이름(여기서는 ~~닉값을 위해~~ 기능의 이름을 넣는 것을 추천)
그럼 놀랍게도 feature/MYFEATURE 브랜치가 생기면서 자동으로 해당 브랜치로 이동하는 것을 볼 수 있다.
자 이제 MYFEATURE 브랜치에서 test 파일에 대한 수정을 가한다.
그리고 develop 브랜치와 마찬가지로 커밋을 한다.
자 나는 MYFEATURE에 대한 기능 구현을 완료했다. 이제 병합을 해보자.
병합도 아까와 똑같이 한 줄의 명령어만 입력하면 git_flow에서 병합 및 기존 feature 브랜치 삭제를 같이 해준다.
git flow feature finish 브랜치 이름
그럼 자동으로 머지가 되어 develop 브랜치에서 아까 전 MYFEATURE 브랜치에서 쓴 결과를 볼 수 있을 것이다.
이제 기능 구현을 완료했다고 가정하고 release 브랜치로 옮겨 테스트를 진행하고 버그를 수정해 보자!
이러한 기능 또한 git flow가 제공해 준다.
git flow release start 생성하고 싶은 브랜치 이름(보통 버전 표시를 한다. 1.0)
RELEASE 뒤에 있는 develop 명령어는 무시하자.
그럼 release 브랜치가 내가 원하는 이름으로 생성되면서 자동으로 해당 브랜치로 전환된 것을 볼 수 있다.
이제 release 브랜치에서 버그가 발견되었고 test 파일에 추가적인 정보를 작성 후 커밋하였다고 가정해 보자. 이때까지의 git log는 다음과 같다.
그리고 버그를 고쳤으니, 이제는 해당 release 브랜치를 master와 develop 브랜치에 반영해 줄 것이다.
마찬가지로 해당 명령어를 입력하면 쉽게 고칠 수 있다.
git flow release finish 브랜치 이름
그럼 master 브랜치와 develop 브랜치에 merge 된 것을 볼 수 있다.
좋다 master 브랜치와 develop 브랜치에 변경된 내용이 적용되었고 이제 master 브랜치는 변경된 내용을 바탕으로 서비스를 시작한다. 하지만 갑작스러운 문제가 발생해 hotfix에 돌입해야 한다.
해당 명령어를 사용하여 간단히 hotfix 브랜치를 생성하고 버그를 고친 다음 커밋하자.
git flow hotfix start 생성하고 싶은 브랜치 이름
수정을 통해서 버그를 고쳤고 이제 그 내용을 master와 develop 브랜치에 반영할 차례다.(develop 브랜치에도 반영을 해야 한다는 사실을 꼭 기억하자.)
이것 또한 아까랑 비슷하게 입력하여 자동으로 master와 develop 브랜치에 merge 할 수 있다.
git flow hotfix finish 브랜치 이름
성공적으로 master와 develop 브랜치에 hotfix 브랜치에 내용이 적용된 것을 확인할 수 있다.
이때까지 한 것들을 Git kraken을 활용하여 간단하게 살펴보자.
내가 merge 명령어를 입력하지 않았음에도 git flow 도구가 자동으로 merge 및 브랜치 삭제를 한 것을 알 수 있다.
결론
git flow는 소프트웨어 관리 방법으로 정말 좋은 시스템이다.
하지만 현대적인 소프트웨어에 적용하는 것은 적합할까?
가령 웹 개발을 한다고 했을 경우에, 저런 식으로 복잡하게 브랜치를 운영할 필요가 있을까? 라고 생각할 수도 있을 것이다.
나는 물론 해둬서 전혀 나쁠 것이 없다고 생각한다.
하지만 이러한 방식이 너무 복잡하다고 생각하고 merge 할 때 많은 충돌이 일어날 것이라고 생각, 또한 한다.
그래서 이러한 웹 개발에 맞는 git 관리 방식이 있는데 그것이 바로 github flow 방식이다.
그것에 대해서는 나중에 다룰 수 있다면 다루고 싶다.
틀린 점이 있다면 바로 말씀해주시면 감사하겠습니다.
