Corca Medium 아카이브

실무에서 사용되는 git flow 도구 사용법. App개발에서 쓰이는 git flow 브랜칭 전략

Git Flow 대해 얼마나 아시나요?

🧙‍♂️ : “그거 그냥 뭐.. master, develop, feature, release, hotfix 브랜치 나눠서 작업 하는거 아닌가요”

🧙‍♂️ : “뭐 .. 당연히 아시겠지만 릴리즈 된 버전에 버그 생기면 hotfix 브랜치로 따서 작업하시고 버전업 해주세 요 ..“ 🧙‍♂️ : “develop 브랜치에서 작업하실 때 꼭 feature 브랜치 따주시구요 ..”

라고 바로 나오는 익숙한 개발자가 있는 반면에

👶 : “아..! 이론은 아는데.. 잘 사용해본 적이 없어요..!”

👶 : “feature 브랜치는 따봤는데.. hotfix 브랜치 경험은 없어요..!”

등 협업할 기회가 적어서 기회조차 못 가져 본 주니어 개발자 분들도 몇몇 계실 것 같아요.

저는 그 git도 어느정도 쓸 줄 알고 하지만 git flow는 제대로 사용해보지 않은 분들을 위해 실무에선 정말 어 떻게 사용하는지 A-Z로 친절하게 가이드 해드리고자 몇자 정리해보겠습니다.

브랜칭 전략으로 흐름만 이해한다면 수동으로 단순히 git 명령어 만으로 진행할 수 있지만, 저는 danielkummer(Daniel Kummer)가 만든 git flow 도구를 이용해 어떻게 git flow를 어떤 상황에 사용하는지 설명드리겠습니다. 도구를 이용하다보면 자연스럽게 git flow흐름도 이해하실 수 있으실거예요!

오늘 사용할 도구 git flow 🔧 https://danielkummer.github.io/git-flow-cheatsheet/index.ko_KR.html 위 링크에 함께 접속해서 따라와주시면 됩니다.

🖐 git-flow에 사용되는 브랜치는 총 5개 입니다.

• main (= master)
• develop
• feature
• release
• hotfix

👀 각 브랜치가 무슨 역할을 하는지는 나중에 차차 설명 드리고 저 5개 branch 이름 부터 기억해주세요

최초 한번만 하면 되는 git flow 도구 설치 우선 페이지에 나와있는 대로 개발 환경에 맞게 명령어를 이용해 설치를 해주세요.

저는 macOS라서 아래 명령어로 설치했습니다.

한번만 설치 해주시면 앞으로 로컬 기기 내 어느 프로젝트든 git flow를 적용시킬 수 있답니다.

flow 요약 🏄 그럼 이제 사용자 케이스 별로 flow 순으로 요약해서 기입해볼게요

최대한 git, git-flow 명령어보단 말로 풀어서 써보겠습니다.

👪 처음 프로젝트 셋팅부터 구현 배포까지 하는 앱팀 case1. ,

• 팀 리더가 new project 생성
• 팀 리더가 git 공용 repository에 올림
• 나머지 팀원들은 공용 repository에 올라 온 project 로컬에 가져옴
• 전 팀원 git flow 도구 사용해서 init (초기화) 해줌
• 폭풍 엔터로 브랜치 명명규칙은 기본값을 따라줌
• 모든 팀원 로컬 환경에서 처음에 main 브랜치 뿐만 있었는데 develop 브랜치가 로컬에 생겨남
• 각자 맡은 작업을 시작 하기 위해 git flow 도구 사용해서 feature 브랜치 생성
• (( feature 폭풍 작업 ))
• 작업 완료 후 feature 브랜치를 push 해서 PR 올림
• PR 타이틀, 설명 등 작성 후 리뷰어 팀원들 등록
• PR 승인 되면 Squash and Merge 버튼을 통해 압축 된 하나의 커밋으로 develop에 머지한다.
• 그리고 기존 feature 브랜치는 삭제해준다.
• 또 다른 feature 작업을 위해 가장 마지막으로 업데이트 된 develop 브랜치를 pull 한다.
• (( 7~13번 무한 반복 ))
• 어느정도 팀이 원하는 작업을 다 완료 해서 릴리즈 배포할 때가 됐다면 릴리즈를 담당 할 한명을 정한다.
• 현 버전 릴리즈 담당 1명 / 나머지는 그 다음 버전 릴리즈를 위한 feature 무한 작업
• 릴리즈 담당자는 git flow 도구 사용해서 release 브랜치 생성
• (( 버저닝 작업 ))
• release 브랜치 기반으로 배포 파일을 만든다.
• 배포 한다. = 심사 요청 한다.
• 심사 요청 후 이상이 있다면? 릴리즈 브랜치 내 에서 수정해준다.

• 심사를 모두 무사히 통과해 정상적으로 배포 완료까지 해준다.
• git flow 도구 사용해서 release 브랜치 finish 해준다.
• 릴리즈 브랜치 이름으로 태그도 추가한다.
• git flow 도구로 인해 자동으로 릴리즈 브랜치는 삭제되며, main에 체크아웃된다.
• main 브랜치 + 버저닝 태그와 함께 푸시한다.
• develop 브랜치에 체크아웃하고 main 브랜치 내용을 백머지 한다.
• develop 브랜치 푸시한다.
• (( 7~28번 무한 반복 ))

🧑🏻‍💻 기존 프로젝트에 합류 후 첫 를 구현하게 된 앱 개발자 case2. feature

• 이미 기존 올라가 있는 git 공용 repository 에서 project 확인
• 공용 repository에 올라 온 project 로컬에 가져옴
• 브랜치 명명규칙은 이미 등록 된 기본값을 따라줌, 하나하나 잘 보면서 엔터 누르기
• develop 브랜치 체크아웃
• 맡은 작업을 시작 하기 위해 git flow 도구 사용해서 feature 브랜치 생성
• (( feature 폭풍 작업 ))
• 작업 완료 후 feature 브랜치를 push 해서 PR 올림
• PR 타이틀, 설명 등 작성 후 리뷰어 팀원들 등록
• PR 승인 되면 Squash and Merge 버튼을 통해 압축 된 하나의 커밋으로 develop에 머지한다.
• 그리고 기존 feature 브랜치는 삭제해준다.
• 또 다른 feature 작업을 위해 가장 마지막으로 업데이트 된 develop 브랜치를 pull 한다.
• (( 7~12번 무한 반복 ))

💀 프러덕션에 올라가있는 앱에서 버그를 발견한 앱 개발자 case3.

(( 내 로컬 프로젝트에 git flow init(초기화)가 되어있는 가정 ))

• 호들짝 놀래며 자책한다.
• 참담한 현 상황을 슬랙 채널을 통해 슬픈 소식을 침착하게 알린다.
• 기존 작업하고 있던 걸 중단 한다.
• main 브랜치로 체크아웃을 한다.
• pull 받아서 최신 main 브랜치를 바라본다.
• (( 버그 수정 침착하게 뚝딱뚝딱 ))
• (( 버저닝 작업 ))
• hotfix 브랜치 기반으로 배포 파일을 만든다.
• 배포 한다. = 심사 요청 한다.
• 심사 요청 후 이상이 있다면? 릴리즈 브랜치 내 에서 수정해준다.
• 심사를 모두 무사히 통과해 정상적으로 배포 완료까지 해준다.
• git flow 도구 사용해서 hotfix 브랜치 finish 해준다.
• hotfix 브랜치 이름으로 태그도 추가한다.
• git flow 도구로 인해 자동으로 hotfix 브랜치에 했던 작업을 main 브랜치와 develop 브랜치에 머지를 해

주고 develop 브랜치로 체크아웃 해준다.

• develop 브랜치 최종사항을 버저닝 태그와 함께 푸시한다.
• main 브랜치도 체크아웃해서 푸시한다.
• develop 브랜치에 체크아웃하고 main 브랜치 내용을 백머지 한다.
• develop 브랜치 푸시한다.
• 다시 develop 브랜치에 체크아웃하고 멈췄던 작업을 다시 한다.

🦿 를 해야하는 앱 서비스팀 case4. QA

• 팀은 “새 기능 작업”과 “bugfix 해야하는 작업”을 우선순위와 함께 나열한다.
• 플래닝 미팅을 갖고 이번 스프린트 내에서만 할 수 있는 작업만 가져간다.
• 새 기능 작업을 위해 feature 브랜치를 생성하고 작업하고 PR하고 QA한다.
• bugfix 작업또한 feature 브랜치를 생성하고 작업하고 PR하고 QA한다.
• dev 환경 QA는 develop 브랜치에 feature 브랜치가 머지 되었을 때 항시 한다.
• dev 환경 QA에서 나온 버그들도 feature 브랜치를 생성하고 작업하고 PR하고 QA한다.
• develop 브랜치에는 버그가 없는 기능이 완성 된 당장이라도 출시가 가능한 상태로 유지한다. (진행중인

작업이 머지되거나 불안전한 작업이 머지되지 않도록 한다.)

• 릴리즈를 앞둔 시점에 충분히 dev환경 QA가 이뤄지고 문제가 없는걸 확인한다.
• 현 버전 릴리즈 담당 1명 / 나머지는 그 다음 버전 릴리즈를 위한 feature 무한 작업
• 릴리즈 담당자는 git flow 도구 사용해서 release 브랜치 생성
• 나머지는 그 다음 버전 릴리즈를 위한 feature 무한 작업
• (( 버저닝 작업 ))
• release 브랜치 기반으로 배포 파일을 만든다.
• prod 환경 QA를 진행한다.
• prod 환경 QA에서 나온 소소한 버그들은 release 브랜치내 에서 작업하고 또 QA한다.
• 버저닝 작업과 prod환경 QA가 무사히 끝났다면 배포 준비를 한다.
• 배포 한다. = 심사 요청 한다.
• 심사 요청 후 이상이 있다면? 릴리즈 브랜치 내 에서 수정해준다.
• 심사를 모두 무사히 통과해 정상적으로 배포 완료까지 해준다.
• git flow 도구 사용해서 release 브랜치 finish 해준다.
• 릴리즈 브랜치 이름으로 태그도 추가한다.
• git flow 도구로 인해 자동으로 릴리즈 브랜치는 삭제되며, main에 체크아웃된다.
• main 브랜치 + 버저닝 태그와 함께 푸시한다.
• develop 브랜치에 체크아웃하고 main 브랜치 내용을 백머지 한다.
• develop 브랜치 푸시한다.

그러면 이제는 위에서 봤던 flow를 그대로 앞에 git명령어 또는 git flow 명령어를 추가해 나열 해볼게요!

• 👪 처음 프로젝트 셋팅부터 구현, 배포까지 하는 앱팀 flow (with. 명령어)
• mkdir 앱_이름 or flutter create 앱_이름 : 팀 리더가 new project 생성
• git init git remote add origin 원격_앱_저장소_URL git push origin main : 팀 리더가 git 공용 repository에

올림

• git clone 원격_앱_저장소_URL : 나머지 팀원들은 공용 repository에 올라 온 project 로컬에 가져옴
• git flow init : 전 팀원 git flow 도구 사용해서 init (초기화) 해줌
• 폭풍 엔터로 브랜치 명명규칙은 기본값을 따라줌
• 모든 팀원 로컬 환경에서 처음에 main 브랜치 뿐만 있었는데 develop 브랜치가 로컬에 생겨남
• git flow feature start 기능_작업_브랜치명 :각자 맡은 작업을 시작 하기 위해 git flow 도구 사용해서 feature

브랜치 생성

• (( feature 폭풍 작업 ))
• git push orgin feature/기능_작업_브랜치명 or git flow feature publish 기능_작업_브랜치명 : 작업 완료 후
• PR 타이틀, 설명 등 작성 후 리뷰어 팀원들 등록
• git checkout develop git merge --squash 기능_작업_브랜치명 : PR 승인 되면 Squash and Merge 버튼을 통해

압축 된 하나의 커밋으로 develop에 머지한다.

• git branch -d 기능_작업_브랜치명 : 그리고 기존 feature 브랜치는 삭제해준다.
• git pull origin develop : 또 다른 feature 작업을 위해 가장 마지막으로 업데이트 된 develop 브랜치를

pull 한다.

• (( 7~13번 무한 반복 ))
• 어느정도 팀이 원하는 작업을 다 완료 해서 릴리즈 배포할 때가 됐다면 릴리즈를 담당 할 한명을 정한다.
• 현 버전 릴리즈 담당 1명 / 나머지는 그 다음 버전 릴리즈를 위한 feature 무한 작업
• git flow release start v1.0.0 : 릴리즈 담당자는 git flow 도구 사용해서 1.0.0 버전의 release 브랜치 생

성

• (( 버저닝 작업 ))
• release 브랜치 기반으로 배포 파일을 만든다.
• 배포 한다. = 심사 요청 한다.
• 심사 요청 후 이상이 있다면? 릴리즈 브랜치 내 에서 수정해준다.
• 심사를 모두 무사히 통과해 정상적으로 배포 완료까지 해준다.
• git flow release finish 'v1.0.0’ : git flow 도구 사용해서 release 브랜치 finish 해준다.

• v1.0.0 : 릴리즈 브랜치 이름으로 태그도 추가한다.
• git flow 도구로 인해 자동으로 릴리즈 브랜치는 삭제되며, main에 체크아웃된다.
• git push --tags : main 브랜치 + 버저닝 태그와 함께 푸시한다.
• git checkout develop git merge main : develop 브랜치에 체크아웃하고 main 브랜치 내용을 백머지 한

다.

• git push origin develop : develop 브랜치 푸시한다.
• (( 7~28번 무한 반복 ))

참고사항

• 11,12번은 글에 나와있는 대로 git 명령어로 해도 되고 원격 저장소 PR 소통하는 웹 페이지 화면으로 똑같은

동작을 수행해도 됩니다.

• 그리고 11,12 대신해 git flow feature finish 기능_작업_브랜치명 git flow 명령어로 해결할 수도 있습니다.
• 🧑🏻‍💻 기존 프로젝트에 합류 후 첫 feature를 구현하게 된 앱 개발자 flow (with. 명령어)
• 이미 기존 올라가 있는 git 공용 repository 에서 project 확인
• git clone 원격_앱_저장소_URL : 공용 repository에 올라 온 project 로컬에 가져옴
• git flow init : git flow 도구 사용해서 init (초기화) 해줌
• 브랜치 명명규칙은 이미 등록 된 기본값을 따라줌, 하나하나 잘 보면서 엔터 누르기
• git flow feature start 기능_작업_브랜치명 : 맡은 작업을 시작 하기 위해 git flow 도구 사용해서 feature 브랜

치 생성

• (( feature 폭풍 작업 ))
• git push orgin feature/기능_작업_브랜치명 or git flow feature publish 기능_작업_브랜치명 : 작업 완료 후
• PR 타이틀, 설명 등 작성 후 리뷰어 팀원들 등록
• git checkout develop git merge --squash 기능_작업_브랜치명 : PR 승인 되면 Squash and Merge 버튼을 통해

압축 된 하나의 커밋으로 develop에 머지한다.

• git branch -d 기능_작업_브랜치명 : 그리고 기존 feature 브랜치는 삭제해준다.
• git pull origin develop : 또 다른 feature 작업을 위해 가장 마지막으로 업데이트 된 develop 브랜치를

pull 한다.

• (( 7~12번 무한 반복 ))

참고사항

• 10,11번은 글에 나와있는 대로 git 명령어로 해도 되고 원격 저장소 PR 소통하는 웹 페이지 화면으로 똑같은

동작을 수행해도 됩니다.

• 그리고 11,12 대신해 git flow feature finish 기능_작업_브랜치명 git flow 명령어로 해결할 수도 있습니다.
• 💀 프러덕션에 올라가있는 앱에서 버그를 발견한 앱 개발자 flow (with. 명령어)
• ㅠㅠ : 호들짝 놀래며 자책한다.
• 참담한 현 상황을 슬랙 채널을 통해 슬픈 소식을 침착하게 알린다.
• 기존 작업하고 있던 걸 중단 한다.
• git checkout main : main 브랜치로 체크아웃을 한다.
• git pull origin main : pull 받아서 최신 main 브랜치를 바라본다.
• git flow hotfix start v1.0.1_버그_이름 : git flow 도구 사용해서 hotfix 브랜치 생성
• (( 버그 수정 침착하게 뚝딱뚝딱 ))
• (( 버저닝 작업 ))
• hotfix 브랜치 기반으로 배포 파일을 만든다.
• 배포 한다. = 심사 요청 한다.
• 심사 요청 후 이상이 있다면? 릴리즈 브랜치 내 에서 수정해준다.
• 심사를 모두 무사히 통과해 정상적으로 배포 완료까지 해준다.
• git flow hotfix finish 'v1.0.1_버그_이름’ : git flow 도구 사용해서 hotfix 브랜치 finish 해준다.
• v1.0.1_버그_이름 : hotfix 브랜치 이름으로 태그도 추가한다.
• git flow 도구로 인해 자동으로 hotfix 브랜치에 했던 작업을 main 브랜치와 develop 브랜치에 머지를 해

주고 develop 브랜치로 체크아웃 해준다.

• git push origin develop --tags : develop 브랜치 최종사항을 버저닝 태그와 함께 푸시한다.
• git checkout main git push origin main --tags : main 브랜치도 체크아웃해서 푸시한다.
• git checkout develop git merge main : develop 브랜치에 체크아웃하고 main 브랜치 내용을 백머지 한

다.

• git push origin develop : develop 브랜치 푸시한다.
• git checkout develop : 다시 develop 브랜치에 체크아웃하고 멈췄던 작업을 다시 한다.
• 🦿 QA를 해야하는 앱 서비스팀 flow (with. 명령어)

• 팀은 “새 기능 작업”과 “bugfix 해야하는 작업”을 우선순위와 함께 나열한다.
• 플래닝 미팅을 갖고 이번 스프린트 내에서만 할 수 있는 작업만 가져간다.
• git flow feature start 기능_작업_브랜치명 git flow feature finish 기능_작업_브랜치명 : 새 기능 작업을 위해

feature 브랜치를 생성하고 작업하고 PR하고 QA한다.

• git flow feature start 버그_작업_브랜치명 git flow feature finish 버그_작업_브랜치명 : bugfix 작업또한

feature 브랜치를 생성하고 작업하고 PR하고 QA한다.

• dev 환경 QA는 develop 브랜치에 feature 브랜치가 머지 되었을 때 항시 한다.
• dev 환경 QA에서 나온 버그들도 feature 브랜치를 생성하고 작업하고 PR하고 QA한다.
• develop 브랜치에는 버그가 없는 기능이 완성 된 당장이라도 출시가 가능한 상태로 유지한다. (진행중인

작업이 머지되거나 불안전한 작업이 머지되지 않도록 한다.)

• 릴리즈를 앞둔 시점에 충분히 dev환경 QA가 이뤄지고 문제가 없는걸 확인한다.
• 현 버전 릴리즈 담당 1명 / 나머지는 그 다음 버전 릴리즈를 위한 feature 무한 작업
• git flow release start vX.X.X : 릴리즈 담당자는 git flow 도구 사용해서 release 브랜치 생성
• 나머지는 그 다음 버전 릴리즈를 위한 feature 무한 작업
• (( 버저닝 작업 ))
• release 브랜치 기반으로 배포 파일을 만든다.
• prod 환경 QA를 진행한다.
• prod 환경 QA에서 나온 소소한 버그들은 release 브랜치내 에서 작업하고 또 QA한다.
• 버저닝 작업과 prod환경 QA가 무사히 끝났다면 배포 준비를 한다.
• 배포 한다. = 심사 요청 한다.
• 심사 요청 후 이상이 있다면? 릴리즈 브랜치 내 에서 수정해준다.
• 심사를 모두 무사히 통과해 정상적으로 배포 완료까지 해준다.
• git flow release finish 'vX.X.X’ : git flow 도구 사용해서 release 브랜치 finish 해준다.
• vX.X.X : 릴리즈 브랜치 이름으로 태그도 추가한다.
• git flow 도구로 인해 자동으로 릴리즈 브랜치는 삭제되며, main에 체크아웃된다.
• git push --tags : main 브랜치 + 버저닝 태그와 함께 푸시한다.
• git checkout develop git merge main : develop 브랜치에 체크아웃하고 main 브랜치 내용을 백머지 한

다.

• git push origin develop : develop 브랜치 푸시한다.

자! 그러면 이제 각 브랜치 별로 어떤 역할을 하는지 이제 감이 오셨나요?

위 사례를 보고 어느정도 감을 잡으셨겠지만 git-flow에 사용되는 5개 브랜치의 역할을 요약하자면 다음과 같 습니다.

가장 마지막 릴리즈 버전을 바라보고 있는 이미 출시 배포 된 브랜치

• main (= master) branch : , ( )

다음 출시 버전을 개발하는 브랜치

• develop branch :

새 기능 개발하는 브랜치

• feature branch : (feature) : 버그를 수정 개발하는 브랜치

릴리즈 배포를 위한 브랜치

• release branch : : 버저닝 작업과 Prod 환경 QA에서 나온 버그 수정

배포된 릴리즈 버전에 문제가 있을 때 즉각 대응을 위한 브랜치

• hotfix branch : : 릴리즈 버전에 대응하는

문제 버그만 수정 😅 어떤가요..? 이제 이해가 가셨나요?

아직 끝이 아닙니다! cheatsheet 를 같이 보면서 따라가봅시다 !

init 나와있는 대로 프로젝트 내에서 git flow 도구를 사용한다는 명령어 입니다.

기기를 바꿨을 때나 새 프로젝트에 투입 되었을 때 모두 프로젝트 단위로 초기화가 필요합니다.

명령어를 하게 되면 branch name을 입력하게 되는데 기본 값으로 하는 것을 추천 드리기에 폭풍 엔터를 눌러주시면 됩니다.

feature start MYFEATURE에 기능(feature) 브랜치 이름을 적어주면 됩니다.

보통은 jira를 사용하고 있다면, jira issue 번호와 함께 기능을 요약해서 적는 경우가 있습니다.

ex. ADCIO-000_new-feature 하이픈으로 구분을 둘지 언더바로 구분을 둘지는 팀끼리 소통해서 컨벤션을 정하면 됩니다.

ex. new-feature-name ex. new_feature_name 위와 같은 명령어 입력 시 develop 브랜치 기반 인 feature/MYFEATURE 브랜치 이름으로 생기고 체크아웃 됩니다.

기능(feature) 브랜치는 두번째 별표에 적혀있듯이 가능하다면 개발자 local 환경에서만 존재합니다.

PR을 위해 remote로 push 해두었다면, remote 환경에선 delete하는게 일반적입니다.

feature finish MYFEATURE에 작업하고 있는 기능(feature) 브랜치 이름을 적어주면 됩니다.

finish 명령어 만으로 페이지에 적혀있는 액션을 간편하게 자동으로 수행해줍니다.

• develop 브랜치에 병합(merge)
• feature 브랜치를 삭제
• develop 브랜치에 자동으로 체크아웃

보통 기능(feature) 브랜치가 끝나 develop 브랜치에 머지가 되면 develop 브랜치 기반DEV 환경을 바라 보고있는 빌드가 생성되고 QA를 시작합니다.

하지만 을해야되서 브랜치를 로올려야된다면

feature publish git flow가 아닌 일반적인 git push origin feature/MYFEATURE 와도 동일합니다.

release start 페이지에 나와있는 명령어와 다르게 vX.X.X 에 현재 배포할 릴리즈 버전을 기입해주시면 됩니다.

위와 같은 명령어 입력 시 develop 브랜치 기반으로 release/vX.X.X 브랜치가 생기고 체크아웃 됩니다.

release 브랜치는 develop 브랜치(DEV 환경 QA)가 완벽히 끝났을 때 생성합니다.

완료된 feature 브랜치가 생겨날 때마다 (=develop 브랜치에 머지 될 때마다) DEV 환경 QA를 진행하고, QA로 인한 버그도 다 develop 브랜치 레벨에서 버그 수정을 합니다.

릴리즈 브랜치 내에선 가능하다면 버저닝 같은 작업 위주로만 진행하고 배포할 준비를 합니다.

릴리즈 브랜치 생성 후 보통 Prod(Production)환경을 바라보고있는 빌드 생성 후 QA를 시작합니다.

Prod 환경 QA로 인한 버그가 있다면 release 브랜치 내 에서 버그 수정을 합니다.

release finish vX.X.X 에 현재 배포할 릴리즈 버전을 기입해주시면 됩니다.

finish 명령어 만으로 페이지에 적혀있는 액션을 간편하게 자동으로 수행해줍니다.

• main(master) 브랜치에 병합(merge)
• 릴리즈 버전 태그 작성
• release 브랜치를 삭제
• main(master) 브랜치에 자동으로 체크아웃

local에만 변동사항이 일어났으니, 이 모든사항을 태그와 함께 push를 해줍니다. git push --tags 그리고 develop 브랜치에도 잊지 않고 꼭 checkout + merge + push 합니다.

git:(master) git:(develop) git:(develop)

hotfix start hotfix 브랜치는 이미 출시된 버전에 문제가 생겨 즉각! 대응을 할 때 생성합니다.

페이지에 나와있는 명령어에 [BASENAME]을 빼고 vX.X.X 에 현재 배포할 릴리즈 버전을 기입해주시면 됩니다.

위와 같은 명령어 입력 시 main 브랜치 기반으로 hotfix/vX.X.X 브랜치가 생기고 체크아웃 됩니다.

main 브랜치를 바라보고 있는 이유는 릴리즈 된 마지막 버전의 코드를 바라보고 있기 때문입니다.

hotfix 브랜치 내에선 즉각 대응해야되는 문제 수정과 버저닝 작업만 작업합니다.

hotfix 브랜치 기반 Prod 환경 QA를 진행 후 문제가 없다면 배포합니다.

vX.X.X 에 현재 배포할 릴리즈 버전을 기입해주시면 됩니다.

finish 명령어 만으로 페이지에 적혀있는 액션을 간편하게 자동으로 수행해줍니다.

• main(master)와 develop 브랜치에 병합(merge) : 지금 이미지엔 develop 브랜치에 머지하다가 충돌

(conflict)나서 수정 필요하다고 하는 중

• 릴리즈 버전 태그 작성
• main(master) 브랜치에 자동으로 체크아웃

local에만 변동사항이 일어났으니, 이 모든사항을 태그와 함께 push를 해줍니다. git push --tags 그리고 develop,master 브랜치에도 잊지 않고 push 합니다.

이제 에대한상황과설명은끝입니다

branch !

아래 이미지 보시다 싶이 내가 쓰고자 하는 기능 + start/finish 등 쉽게 명령어 기반으로 움직이고 있어요

feature, release, hotfix가 어느 상황에 쓰이고 어떤 액션을 담는 브랜치인지 알아내셨다면 쉬운 명령어로 git flow 브랜치 전략 기반하에 서비스를 움직일 수 있을 거예요.

이제 여러분 팀들도 git flow 브랜치 전략을 쉽게적용할 수 있겠죠?!

기술을 적용하는 데 여러분들이 소외받지 않도록 코르카 팀은 열심히 기술을 전파하도록 하겠습니다!

👋 다음에 또 봐요 ~

기술 발전의 혜택을 모두가 누리게 하여 인류 문명의 발전에 기여하는 코르카