Git 브랜치 전략 - Git Flow
한 번에 끝내는 HTML, CSS JavaScript, TypeScript Part 2. Git을 활용한 버전관리
- Git 브랜치 전략 - Git Flow 개요
- Git 브랜치 전략 - Git Flow 예제
# Git 브랜치 전략 - Git Flow 개요
기본적으로 git 브랜치는 5종류의 branch를 운영하게 됩니다.
| main(master) | 기본/메인/제품 브랜치 |
| dev(develop) | 다음 제품 출시를 위해 여러 기능을 병합하는 브랜치 |
| feature/* | 각 기능 개발을 위한 브랜치 |
| release | 이번 제품 출시 직전 최종 테스트(QA)를 위한 브랜치 |
| hotfix | 제품에 버그가 확인되었을 때 긴급 수정을 위한 브랜치 |
## main(master)
- 프로젝트의 기본이되고, 하나의 웹사이트로 배포되는 제품을 의미합니다.
- 배포를 하게 되면 실제로 웹사이트가 사용자들에게 보여질 수 있는 상황이 됩니다.
## dev(develop)
- main(master) 브랜치를 만들고 나면 바로 dev(develop) 브랜치를 생성하게 됩니다.
- 제품 출시를 위해 여러 기능들을 개발 한 후, 하나의 branch로 병합해서 관리하는 용도의 개발용 branch 입니다.
## feature/*
- 여러 기능들을 하나의 branch에서 개발하는 것이 아니라, branch이름에서 앞에 feature 라는 이름 + 뒤에 기능 이름을 붙여서 각각의 branch로 운영합니다.
- 이렇게 각각의 기능의 branch들을 하나로 병합할 때 dev(develop)로 병합하게 됩니다.
## release
- dev(develop)에서 제품화 시킬 기본적인 개발이 끝났다면, release 라는 branch를 통해서 제품 출시 직전 최종 테스트(QA)를 진행합니다.
- 버그를 발견해서 수정을 하거나 누락된 내용을 추가할 수 있는 branch입니다.
- release branch에서 최종적인 테스트를 거쳐서 검수가 끝나면 main(master) branch로 병합하여 배포를 진행합니다.
## hotfix
배포 후 사용을 하면서 버그를 발견하게 되면 급하게 수정을 해야 할 것입니다.
하지만, 기존의 dev, feature, release 를 거쳐서 수정을 하게 되면 효율이 떨어지고 시간이 많이 걸릴 것입니다.
- 그래서 main(master) 에서 발견된 버그는 실제 사용 중 사용자와 가장 가깝게 발생한 버그이기 때문에 긴급하게 수정을 해야 합니다. 이 때는 hotfix branch를 통해서 긴급하게 수정하여 다시 main branch로 배포를 진행합니다.
## 마무리
이렇게 5종류의 branch를 통해서 프로젝트를 관리해 나가고 유지하고 보수할 수 있습니다.
## gitflow 그림 예시
아래 그림은 gitflow를 통해서 작업할 수 있는 각 commit들의 예시입니다.
# Git 브랜치 전략 - Git Flow 예제
실제로 VSCode에서 연습해보겠습니다.
## 최초 버전이 배포되는 과정
1. 빈 폴더에 main.js 파일을 만들고, git init 을 통해서 버전관리를 시작합니다.
git init
2. 먼저 dev 브랜치와 feature 브랜치를 생성하기 전에, 현재 초기화한 최초버전을 하나 만들어 줍니다.
git add .
git commit -m '프로젝트 생성'
3. dev 브랜치와 feature 브랜치를 만들어줍니다. --list 로 생성된 branch 목록을 확인할 수 있습니다.
git branch dev
git branch feature/A
git branch --list
4. 기능을 만들기 위해 feature/A 브랜치로 이동합니다. 그리고 A1.js 파일을 만들고 하나의 기능이라고 가정합니다.
git checkout feature/A
5. 만든 기능을 commit 하여 마무리합니다.
git add .
git commit -m 'A1'
6. 만든 기능을 dev로 병합하기 위해 dev branch로 이동하고 병합합니다.
git checkout dev
git merge feature/A
7. 이후에 feature/A 에 추가로 개발할 내용이 생겼다면, 다시 feature/A로 이동하여 작업합니다.
git checkout feature/A
8. 새로운 기능을 파생하여 개발하기 전, 우선 A1.js의 파일이름을 A2.js로 바꿔서 진행합니다. 파일 이름 수정사항을 commit 하여 마무리합니다.
git add .
git commit -m 'A2'
9. 새로운 파생 기능을 개발하기 위해 새로운 branch를 만들고 이동합니다.
git branch feature/B
git checkout feature/B
10. 새로운 B1.js 파일을 만들고 새로운 파생 기능이라고 가정합니다.
git add .
git commit -m 'B1'
11. B1에 추가적인 내용이 있을 수도 있습니다. 파일 이름을 B2.js로 바꾸고 새로운 commit을 생성합니다.
git add .
git commit -m 'B2'
12. 개발이 끝난 기능을 dev branch로 병합해줍니다.
git checkout dev
git merge feature/B
13. 여기까지 기능 개발이 모두 끝났다면 main branch로 배포하기 전에 먼저 release branch 를 거쳐야 합니다.
git branch release
git checkout release
git commit -m '1.0.0'
14. release에서 최종검수가 완료 되면 main branch로 병합하여 배포합니다.
git checkout main
git merge release
## dev branch 에서 정리할 내용이 추가로 생겼을 경우
1. dev branch 로 이동하여 d1.js 파일을 만듭니다.
git checkout dev
(d1.js 파일 생성)
git add .
git commit -m 'd1'
## feature/A branch에서 추가적인 업데이트가 진행될 경우
1. feature/A branch 로 이동한 후 업데이트가 되었다는 가정으로 파일이름을 A2에서 A3로 수정합니다.
git checkout feature/A
(A3.js로 파일 이름 수정)
git add .
git commit -m 'A3'
2. dev branch에 업데이트된 feature/A branch를 병합해줍니다.
git checkout dev
git merge feature/A
## 위 과정 후 다시 배포 진행
1. release branch로 병합해줍니다. release 버전도 업데이트 해줍니다.
git checkout release
git merge dev
git add .
git commit -m '1.1.0'
2. 배포를 진행합니다.
git checkout main
git merge release
## 배포 된 버전에서 버그를 발견한 경우
긴급하게 버그를 수정해야 하므로 hotfix 라는 branch에서 버그를 수정하고 다시 main branch로 병합합니다.
1. hotfix branch를 만들고 이동합니다.
git branch hofix/lowercase
git checkout hotfix/lowercase
2. 잘못된 부분을 수정합니다. (여기서는 d1.js 파일이름을 D2.js 로 수정합니다.)
git add .
git cmomit -m '버그 수정'
3. 수정된 버전으로 다시 main branch로 배포합니다.
git checkout main
git merge hotfix/lowercase
이렇게 main branch는 최신버전으로 바뀌었지만, 버전의 관리는 release branch에서 관리하고 있기 때문에 최신 버전으로 반영된 main branch의 내용을 역으로 release branch로 merge 해주어야 합니다.
4. main branch의 버전을 release branch로 병합합니다.
git checkout release
git merge main
git add .
git commit -m '1.1.1'