흐름을 이해해보자! Git-flow

2958 단어 gitgit


이 글의 목적?

이번 글의 주제인 Git-flow도 역시 예전에 다루었던 내용이다. Git-flow를 이용하면 협업을 하면서 소스 코드 이력 관리할 수 있다는 말에 정리해보았던 내용이지만 실제로 응용하지 않았었다.

지금도 혼자서 회사의 서버에 대한 모든 업무를 혼자 담당하고 있기 때문에 굳이 이 전략을 쓰지 않아도 되지만, 추후에 함께 일할 동료들과 협업하기 위해서 사용해야겠다고 판단했다.

Vincent Driessen 브랜칭 모델!

Vincent Driessen 브랜칭 모델에는 5개의 브랜치(master, develop, feature, release, hotfix)가 사용된다.

출처: https://nvie.com/posts/a-successful-git-branching-model/

1. master 브랜치

정식 배포되는 안정적인 버전의 소스코드가 관리되는 브랜치다. 따라서 배포해도 될 만큼 안정성이 충분히 검증된 코드들만이 병합되어야 한다. 이 브랜치에는 지난 배포판 버전의 소스코드를 따라가기 위해 태그들이 추가되어 있다. 이 태그를 통해 각 릴리즈 버전의 소스코드를 빠르게 확인할 수 있다.

2. develop 브랜치

새로운 기능, 버그 수정, 성능 개선 코드들이 검증이 완료되고 PR 요청을 거치게 되면 develop 브랜치에 병합된다.

개발자는 feature 브랜치에서 소스 코드를 수정 후 develop 브랜치로 PR 요청을 하고, 다른 사람이 기능을 검토한 후 최종적으로 develop 브랜치에 병합한다. 새로운 기능을 위한 feature 브랜치는 이 브랜치로 부터 파생된다.

3. feature 브랜치

새로운 기능 개발이나 버그 수정을 위한 일련의 코드 수정이 이루어지는 브랜치다. 이 브랜치에서 개발자 혼자 작업할 수 있고, 특정 기능 개발을 위한 여러명의 개발자들이 공동으로 작업할 수도 있다. 여기서 작업된 내용은 최종적으로 PR을 거쳐 develop 브랜치에 병합된다.

feature 브랜치의 명명 규칙은 codingsight 사이트에서 확인할 수 있다. 하지만 개인적으로는 기능에 대한 이름을 뒤에 붙이는 편이 좋은 것 같다. 조금 더 구분을 짓는다면 기능 앞에 개발중인 사람의 이름을 작성하는 것도 방법이 될 것 같다.

feature/login
feature/kevin-login

4. release 브랜치

이 브랜치는 develop 브랜치를 기반으로 생성된다. 다음 릴리즈에 포함되어야 하는 기능들과 버그 픽스들이 확정된 다음 생성된다. 주로 QA 테스트는 release 브랜치를 기준으로 진행된다. 이 과정에서 발견된 버그 수정 사항들은 release 브랜치와 develop 브랜치에 적용되며, 그 밖에 메이저 기능들이 중간에 추가되지 않는다.

테스트 이후 release 브랜치의 코드가 안정적이면 master 브랜치에 병합되고 release에 해당하는 태그가 생성된다. release 브랜치가 생성된 이후 반영된 수정사항들은 develop 브랜치에도 반영된다.

5. hotfix 브랜치

정기적인 릴리즈 이외에 긴급하게 수행되어야 할 버그 수정을 반영하기 위해 생성되는 브랜치다. 다음 릴리즈 프로세스를 기다릴 수 없을 정도로 긴급한 패치가 바로 반영되어야 하는 경우 이 브랜치를 사용한다.

master 브랜치를 기반으로 생성이되며, 생성된 hotfix 브랜치에 긴급한 패치들이 반영된다. 이후 hotfix 브랜치에 병합되고 태그가 생성이 된다. 동일하게 수정 사항은 develop 브랜치에도 병합되어 긴급 수정 사항이 이후 릴리즈에 반영되도록 한다.

Git-flow의 단점?

방성범님의 글을 보면 Git-flow의 단점에 대해 확인할 수 있다. 나도 이 글을 읽고나서는 공감이 되기도 했지만, 익숙해지는 중이라서 그런지 단점보다는 장점들이 더 많이 보이는 것 같다.

GUI 툴을 활용하자!

이 글에서 가장 중요한 것은 Git-flow 명령어를 숙지하는 것 보다 각 브랜치별 사용 용도와 흐름이라고 생각한다. 이에 대한 증거로, 나는 아직까지 Git-flow를 사용하기 위한 명령어를 제대로 숙지하지 않고 이 전략을 잘 사용(?)하고 있다. 명령어를 몰라도 GUI 툴( GitKraken 🐙)에서 제공해주는 Git-flow 기능으로 손쉽게 사용할 수 있기 때문이다.

처음에 나도 혼자서 버벅거리고 당황스러운 부분도 있었지만, 매번 명령어를 기입하고 외우지 않아도 된다는 점에서 GUI 툴은 정말 강력한 것 같다.

이 글의 레퍼런스

좋은 웹페이지 즐겨찾기