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 branch
git-flow에 사용되는 브랜치는 총 5개 입니다. 🖐️
- main (= master)
- develop
- feature
- release
- hotfix
각 브랜치가 무슨 역할을 하는지는 나중에 차차 설명 드리고 저 5개 branch 이름 부터 기억해주세요 👀
최초 한번만 하면 되는 git flow 도구 설치
우선 페이지에 나와있는 대로 개발 환경에 맞게 명령어를 이용해 설치를 해주세요.
저는 macOS라서 아래 명령어로 설치했습니다.
brew install git-flow-avh
한번만 설치 해주시면 앞으로 로컬 기기 내 어느 프로젝트든 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 로컬에 가져옴
- git flow 도구 사용해서 init (초기화) 해줌
- 브랜치 명명규칙은 이미 등록 된 기본값을 따라줌, 하나하나 잘 보면서 엔터 누르기
- 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 브랜치를 바라본다.
- git flow 도구 사용해서 hotfix 브랜치 생성
- (( 버그 수정 침착하게 뚝딱뚝딱 ))
- (( 버저닝 작업 ))
- 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 명령어를 추가해 나열 해볼게요!
1. 👨👨👦 처음 프로젝트 셋팅부터 구현, 배포까지 하는 앱팀 flow (with. 명령어)
mkdir 앱_이름
orflutter 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/기능_작업_브랜치명
orgit flow feature publish 기능_작업_브랜치명
: 작업 완료 후 feature 브랜치를 push 해서 PR 올림- 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 명령어로 해결할 수도 있습니다.
2. 🧑🏻💻 기존 프로젝트에 합류 후 첫 feature를 구현하게 된 앱 개발자 flow (with. 명령어)
- 이미 기존 올라가 있는 git 공용 repository 에서 project 확인
git clone 원격_앱_저장소_URL
: 공용 repository에 올라 온 project 로컬에 가져옴git flow init
: git flow 도구 사용해서 init (초기화) 해줌- 브랜치 명명규칙은 이미 등록 된 기본값을 따라줌, 하나하나 잘 보면서 엔터 누르기
git checkout develop
: develop 브랜치 체크아웃git flow feature start 기능_작업_브랜치명
: 맡은 작업을 시작 하기 위해 git flow 도구 사용해서 feature 브랜치 생성- (( feature 폭풍 작업 ))
git push orgin feature/기능_작업_브랜치명
orgit flow feature publish 기능_작업_브랜치명
: 작업 완료 후 feature 브랜치를 push 해서 PR 올림- 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 명령어로 해결할 수도 있습니다.
3. 💀 프러덕션에 올라가있는 앱에서 버그를 발견한 앱 개발자 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 브랜치에 체크아웃하고 멈췄던 작업을 다시 한다.
4. 🦿 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 branch 역할
위 사례를 보고 어느정도 감을 잡으셨겠지만 git-flow에 사용되는 5개 브랜치의 역할을 요약하자면 다음과 같습니다.
- main (= master) branch : 가장 마지막 릴리즈 버전을 바라보고 있는, 이미 출시(배포) 된 브랜치
- develop branch : 다음 출시 버전을 개발하는 브랜치
- feature branch : 새 기능(feature) 개발하는 브랜치 : 버그를 수정 개발하는 브랜치
- release branch : 릴리즈 배포를 위한 브랜치 : 버저닝 작업과 Prod 환경 QA에서 나온 버그 수정
- hotfix branch : 배포된 릴리즈 버전에 문제가 있을 때 즉각 대응을 위한 브랜치 : 릴리즈 버전에 대응하는 문제 버그만 수정
어떤가요..? 이제 이해가 가셨나요? 😅
아직 끝이 아닙니다! cheatsheet 를 같이 보면서 따라가봅시다 !
🚩 git flow cheatsheet (init)
git flow init
- 나와있는 대로 프로젝트 내에서 git flow 도구를 사용한다는 명령어 입니다.
- 기기를 바꿨을 때나 새 프로젝트에 투입 되었을 때 모두 프로젝트 단위로 초기화가 필요합니다.
- 명령어를 하게 되면 branch name을 입력하게 되는데 기본 값으로 하는 것을 추천 드리기에 폭풍 엔터를 눌러주시면 됩니다.
🚩 git flow cheatsheet (feature)
git flow feature start MYFEATURE
- 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하는게 일반적입니다.
git flow feature finish MYFEATURE
- MYFEATURE에 작업하고 있는 기능(feature) 브랜치 이름을 적어주면 됩니다.
- finish 명령어 만으로 페이지에 적혀있는 액션을 간편하게 자동으로 수행해줍니다.
- develop 브랜치에 병합(merge)
- feature 브랜치를 삭제
- develop 브랜치에 자동으로 체크아웃
- 보통 기능(feature) 브랜치가 끝나 develop 브랜치에 머지가 되면 develop 브랜치 기반DEV 환경을 바라보고있는 빌드가 생성되고 QA를 시작합니다.
하지만? PR을 해야되서 feature 브랜치를 remote로 올려야 된다면?
git flow feature publish MYFEATURE
- git flow가 아닌 일반적인
git push origin feature/MYFEATURE
와도 동일합니다.
🚩 git flow cheatsheet (release)
git flow release start vX.X.X
- 페이지에 나와있는 명령어와 다르게 vX.X.X 에 현재 배포할 릴리즈 버전을 기입해주시면 됩니다.
- 위와 같은 명령어 입력 시 develop 브랜치 기반으로
release/vX.X.X
브랜치가 생기고 체크아웃 됩니다. - release 브랜치는 develop 브랜치(DEV 환경 QA)가 완벽히 끝났을 때 생성합니다.
- 완료된 feature 브랜치가 생겨날 때마다 (=develop 브랜치에 머지 될 때마다) DEV 환경 QA를 진행하고, QA로 인한 버그도 다 develop 브랜치 레벨에서 버그 수정을 합니다.
- develop 브랜치 + Dev 환경 = QA
- release 브랜치 + Prod 환경 = QA
- 릴리즈 브랜치 내에선 가능하다면 버저닝 같은 작업 위주로만 진행하고 배포할 준비를 합니다.
- 릴리즈 브랜치 생성 후 보통 Prod(Production)환경을 바라보고있는 빌드 생성 후 QA를 시작합니다.
- Prod 환경 QA로 인한 버그가 있다면 release 브랜치 내 에서 버그 수정을 합니다.
git flow release finish vX.X.X
- vX.X.X 에 현재 배포할 릴리즈 버전을 기입해주시면 됩니다.
- finish 명령어 만으로 페이지에 적혀있는 액션을 간편하게 자동으로 수행해줍니다.
- main(master) 브랜치에 병합(merge)
- 릴리즈 버전 태그 작성
- release 브랜치를 삭제
- main(master) 브랜치에 자동으로 체크아웃
- local에만 변동사항이 일어났으니, 이 모든사항을 태그와 함께 push를 해줍니다.
git push --tags
- 그리고 develop 브랜치에도 잊지 않고 꼭 checkout + merge + push 합니다.
git:(master)
git checkout develop
git:(develop)
git merge master
git:(develop)
git push origin develop
🚩 git flow cheatsheet (hotfix)
git flow hotfix start vX.X.X
- hotfix 브랜치는 이미 출시된 버전에 문제가 생겨 즉각! 대응을 할 때 생성합니다.
- 페이지에 나와있는 명령어에 [BASENAME]을 빼고 vX.X.X 에 현재 배포할 릴리즈 버전을 기입해주시면 됩니다.
- 위와 같은 명령어 입력 시 main 브랜치 기반으로
hotfix/vX.X.X
브랜치가 생기고 체크아웃 됩니다. - main 브랜치를 바라보고 있는 이유는 릴리즈 된 마지막 버전의 코드를 바라보고 있기 때문입니다.
- hotfix 브랜치 내에선 즉각 대응해야되는 문제 수정과 버저닝 작업만 작업합니다.
- hotfix 브랜치 기반 Prod 환경 QA를 진행 후 문제가 없다면 배포합니다.
git flow hotfix finish vX.X.X
- 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 브랜치 전략을 쉽게적용할 수 있겠죠?!
기술을 적용하는 데 여러분들이 소외받지 않도록 코르카 팀은 열심히 기술을 전파하도록 하겠습니다!
다음에 또 봐요 ~ 👋