Git 브랜치 활용 - GitFlow

By pink_salt

WEB study/Git, GitLab

2022. 2. 1. 01:20

728x90

안녕하세요~ 항상 나아가는 개발자 pink_salt 핑솔입니다!

코드프레소 Java 웹 개발 체험단 활동을 하고 있습니다.

이번엔 git branch를 활용한 전략에 대해서 알아보는 시간을 갖겠습니다.

GitFlow라는 것에 대해 집중하겠습니다.

이번엔 '실무자가 알려주는 Git 활용한 프로젝트 관리'의 Git 브랜치의 활용 강의를 듣고 공부한 내용을 정리하여 포스팅을 진행하겠습니다.

branch가 필요한 이유?

브랜치가 왜 필요할까요?

소프트웨어는 지속적으로 변경됩니다. 소프트웨어에 대한 변경은 개발 진행 중에 또는 개발이 완료되어 사용 중인 제품에서 발생하는 문제점을 해결하거나 개선하기 위해 발생할 수 있습니다.

위의 사진처럼 master branch가 있고 release branch, feature branch 1,2,3... 등 여러 브랜치들이 생성되기도 병합되기도 합니다.

이렇게 Git을 이용한 브랜치 활용 방식은 개인/조직마다 다를 수 있습니다.

실제 사례로 어떻게 git을 활용하고 있는지 확인해보겠습니다.

https://github.com/tensorflow/tensorflow

GitHub - tensorflow/tensorflow: An Open Source Machine Learning Framework for Everyone

An Open Source Machine Learning Framework for Everyone - GitHub - tensorflow/tensorflow: An Open Source Machine Learning Framework for Everyone

github.com

45개의 branch가 있는 것을 확인할 수 있고 저 분홍색으로 표시한 45 branches를 누르게 되면

이렇게 Active branch와 Stale branches를 볼 수 있습니다.

git 프로젝트도 한번 보겠습니다.

active branch를 살펴보면

아주 간결하게 브랜치를 나눈 것을 확인할 수 있습니다.

이렇듯 프로젝트 별로 브랜치 활용이 다른 것을 예상할 수 있습니다.

브랜치 활용 전략

git을 이용한 브랜치 활용 방식은 개인/조직마다 다를 수 있습니다.
브랜치 활용 전략은 소스코드의 효율적인 관리를 위해 프로젝트의 모든 리스크를 최소화하는 방향으로 일관되고 생산적인 방식으로 조직에 맞게 프로세스화 시켜야합니다.

브랜치 활용 전략 모델

feature 별 branch
개발자별 branch
스프린트 주기별 branch (애자일 -> 스크럼 -> 스프린트)
사내 검증 단계별 branch
...
브랜치 활용 전략 모델(방법론) : GitFlow
https://nvie.com/posts/a-successful-git-branching-model/

A successful Git branching model

In this post I present a Git branching strategy for developing and releasing software as I’ve used it in many of my projects, and which has turned out to be very successful.

nvie.com

GitFlow가 잘 만들어진 프로세스라고 평가 받습니다.

기업에 따라 GitFlow를 똑같이 사용하는 것이 아니라 GitFlow를 기반으로 개선하거나 더하고 빼서 자신들의 로직에 맞게 활용하고 있습니다.

-> GitFlow 모델

GitFlow모델은 총 다섯개의 브랜치를 활용해서 변경점을 관리하는 모델입니다.

master branch
develop branch
feature branch
release branch
hotfix branch

GitFlow 모델 - master

실제 고객에게 릴리즈되는 브랜치입니다.(production)
모든 변경사항은 결국 master로 최종 반영되어야합니다.

GitFlow 모델 - develop

실제 개발의 중심이 되는 브랜치입니다.
모든 기능이 추가되고 버그가 수정되고 고객에게 배포 가능한 수준이 되면 develop의 내용은 master에 최종 반영이 됩니다.
다음 배포할 기능을 개발하는 브랜치입니다.

GitFlow 모델 - feature

기능 자체를 개발하는 브랜치입니다.
develop 브랜치로부터 분기되어 사용됩니다.
featrue 브랜치의 단위는 기능, 스프린트 주기 등이 있습니다.
기능 개발이 완료되거나 스프린트 주기가 종료되면 develop 브랜치로 내용을 merge 한 후 브랜치를 삭제합니다.

GitFlow 모델 - release

배포를 준비(검증, 이슈 수정 등)하는 브랜치입니다.
배포 가능한 상태가 되면 master브랜치로 병합됩니다.
release 브랜치에서 기능 점검 시 발견한 이슈에 대한 수정사항은 반드시 develop에 병합해야합니다.
배포 준비가 완료되면 최종 master로 병합하고 tag를 명시해야합니다.

GitFlow 모델 - hotfixs

배포한 버전에서 긴급하게 수정이 필요한 장애 및 버그 발생 시 대응하는 브랜치입니다.
hotfixs는 master로부터 분기되며, 이슈가 수정되면 수정 사항은 master, develop 브랜치에 최종 반영되어야합니다.

GitFlow 실습

Git Bash 실행 후에

git-flow --help

를 입력하면 모듈의 사용방법에 대한 간략한 설명을 볼 수 있습니다.

이번 실습에서 진행할 디렉토리는 root에 gitflow_test로 폴더를 생성하겠습니다.

GitFlow 브랜치 초기화

우리가 만든 gitflow_test 디렉토리에 브랜치를 초기화하겠습니다.

git flow init

모든 사항에 대해서 일단은 default로 진행하였습니다.

develop 브랜치가 보이는 것을 확인할 수 있습니다.

develop이란 브랜치가 생기고 master에서 checkout된 것을 확인할 수 있습니다.

그림으로 표현하면 이렇습니다.

GitFlow - 기능 개발

이번에는 기능을 개발한다고 가정하겠습니다.

git flow feature start [개발할 기능명]

login이라는 feature의 branch가 생긴 것을 볼 수 있고 checkout된 것도 볼 수 있습니다.

LoginService.java라는 파일을 만들어서 write code 1이라는 코드를 작성하였습니다.

(cat이라는 명령어는 파일의 내용을 보여주는 명령어입니다.)

git add를 통해 스테이징 영역에 추가하겠습니다.

그리고 커밋 메시지와 함께 커밋을 진행하였습니다.

이 상황을 그림으로 표현하면 이렇습니다.

GitFlow - 기능 개발 완료

기능 개발이 모두 완료되었다고 가정했을 경우를 보겠습니다.

git flow feature finish [개발한 기능명]

이 명령어를 입력하면 개발한 내용이 develop 브랜치에 merge됩니다.

(git log 명령어를 통해 develop 브랜치에 commit#1이 들어있는 것을 볼 수 있습니다.)

그리고 개발 완료된 login branch는 삭제됩니다.

그 후 develop 브랜치로 checkout된 것을 볼 수 있습니다.

이렇게 현재 develop으로 브랜치가 변경되고 feature login의 커밋 내용이 모두 develop에 들어간 것을 확인할 수 있습니다. 그리고 feature login 브랜치는 삭제된 것도 알 수 있습니다.

develop 브랜치에 코드 추가

develop브랜치에 MainService.java 파일을 만들어서 코드를 입력하였습니다.

스테이징 영역에 추가하고 commit 메시지와 함께 commit을 진행하였습니다.

그리고 git log --oneline 명령어로 commit진행상황을 보았습니다.

GitFlow - 릴리즈 시작

어느 정도 커밋을 쌓았으니 릴리즈 단계로 넘어가보겠습니다.

git flow release start [버전명]

develop브랜치에서 어느 정도 개발이 진행되면 release 브랜치를 생성해서 배포를 위한 검증을 시작합니다.

그러면 relase/1.0으로 생성되고 checkout된 것을 확인할 수 있습니다.

release/1.0브랜치에서 MainService.java 파일에 코드를 추가하고 스테이징 영역에 추가하겠습니다.

그리고 Commit#3~~ 메시지와 함께 커밋을 진행하였습니다.

GitFlow - 릴리즈 종료

이제 릴리즈 작업이 끝나고 종료된 작업을 진행해보겠습니다.

git flow release finish [버전명]

변경이 완료된 릴리즈 브랜치의 변경 내용들은 develop브랜치, master브랜치에 모두 병합되어야 합니다.

그리고 tag까지 달아야합니다.

master브랜치에 merge 커밋이 생성됩니다. 이 때 수정하지 않고 Esc + :wq를 통해서 바로 진행하였습니다.

그러면 바로 tag를 생성하라고 합니다.

이번에는 complete release 1.0메시지와 함께 태그를 만들겠습니다.

이 작업을 하면 이제 develop브랜치에 merge하라는 창이 나옵니다.

Esc + :wq를 통해서 default 메시지로 저장하였습니다.

그러면

release/1.0 브랜치는 master와 develop에 모두 merge되었습니다.
release/1.0 브랜치는 삭제 되었습니다.
release/1.0 브랜치가 master에 merger 될 때는 tag가 생성되었습니다.
지금 branch는 develop에 checkout 되었습니다.

tag는 git show 1.0을 통해 정보를 볼 수 있습니다.

GitFlow - 긴급 이슈 발생 시

hotfix 브랜치에 대한 내용입니다.

긴급한 이슈가 발생하였을 경우 master 브랜치에서 파생되는 브랜치 입니다.

merge가 되었을 때는 tag를 달아줘야합니다.

git flow hotfix start issue#1

hotfix/1.2.1로 브랜치가 이동하였습니다.

버그 수정을 한다고 가정하고 commit을 생성해보겠습니다.

MainService.java 파일에 코드를 추가하고

스테이징 영역 추가, commit 생성을 진행하였습니다.

그리고 이슈를 해결하고 끝내는 과정을 해보겠습니다.

git flow hotfix finish issue#1

그럼 첫번째 hotfix 브랜치를 master로 머지하겠다는 merge 커밋이 발생합니다.

그리고 master로 merge할 때 생성되는 태그 커밋이 발생합니다.

complete hotfix#1.2.1이라는 메시지와 함께 태그 커밋을 저장합니다.

그 후에는 1.2.1을 develop에 merge하겠다는 커밋이 발생합니다.

수정없이 진행합니다. (Esc + :wq)

이러면

hotfix브랜치는 삭제되고
master에 태그와 함께 merge되고
develop에 merge

된 것을 확인할 수 있습니다.

이렇게 gitFlow모델에서 중요한 다섯가지 브랜치에 대해서 실습과 공부를 진행하였습니다.

현업에서는 GitFlow을 통해 조직과 상황에 맞게 사용할 수 있었으면 좋겠습니다!

화이팅!

브랜치에 대해서 자세하게 알아보고 활용 전략인 GitFlow에 대해서도 잘 알아보았습니다.

git을 이용해 구현한 것을 잘 관리할 수 있도록 더욱 배우고 활용하는 방향으로 다함께 나아갑시다!

열심히 나아가는 개발자 핑솔이었습니다.

코드프레소 URL: https://www.codepresso.kr/

프리미엄 IT 교육 서비스 - 코드프레소

www.codepresso.kr