Code.presso Java 웹 개발 트랙 체험단 활동 2주차에는, 지난 시간에 이어 매우 중요한 GitFlow에 대해 학습했다.
강의 제목은 "실무자가 알려주는 Git 활용한 프로젝트 관리"으로, 자세한 정보는 👇🏻아래👇🏻 링크를 통해 확인할 수 있다.
📌 실무자가 알려주는 Git 활용한 프로젝트 관리 - 강의 정보
✋🏻 포스팅 내 사용된 사진 파일들의 저작권은 모두 코드프레소에 있으며, 강의자료 공유 및 업로드는 불가능합니다.
🏷 Git 브랜치 활용 전략
소프트웨어는 지속적으로 변경된다.
소프트웨어에 대한 변경은 개발 진행중 또는 개발이 완료되어 사용중인 제품에서 발생하는 문제점을 해결하거나 개선하기 위해 발생할 수 있다.
이러한 변경점이 계속해서 생성되기 때문에 브랜치가 필요하다!
변경점을 관리하기 위한 가장 중요한 도구가 바로 브랜치이다😃
Git 을 활용한 브랜치 활용 방법은 개인/조직마다 다르지만,
이번 강의에서 학습한 브랜치 활용 방법은 Git-flow 라는 방법이다!
🏷 GitFlow 소개
📌 GitFlow 에 대해 이전에 다뤘던 포스팅이 있으니 참고하자!
Git-flow 는 어떠한 기능이 아니라, 서로간의 약속과 같은 방법론이다.
이 전략을 사용해 Git 을 더 효율적으로 사용할 수 있는 것이다!
정리하면, 소스 코드 형상/이력 관리를 효율적으로 하고 협업할 때 발생할 수 있는 문제점을 최소화할 수 있는 전략이 Git-flow 이다.
이 사진처럼 소스코드를 관리하자는 의미인데, 이 브랜치 전략에는 5가지의 브랜치가 사용된다.
- master branch
- develop branch
- feature branch
- release branch
- hotfix branch
✔️ master branch
master branch 는 실제 고객에게 릴리즈되는 브랜치로,
모든 변경사항들은 결국 master branch 로 최종 반영되어야 한다.
✔️ develop branch
develop branch 는 실제 개발의 중심이 되는 브랜치이다.
모든 기능이 추가되고, 버그가 수정되고 고객에게 배포 가능한 수준이 되면 develop 의 내용은 master 에 최종 반영해야 한다.
✔️ feature branch
feature branch 는 기능을 개발하는 브랜치이다.
develop 브랜치로 부터 분기되어 사용되고, 기능 개발이 완료되면 develop 브랜치로 머지 후 브랜치가 삭제된다.
✔️ release branch
release branch 는 배포를 준비(검증, 이슈 수정 등)하는 브랜치이다.
release 브랜치에서 기능 점검시 발견한 이슈에 대한 수정사항은 반드시 develop에 병합해야 한다.
배포 준비가 완료되면, 최종 master 로 병합하고 tag 를 명시해야 한다.
✔️ hotfix branch
hotfix branch 는 배포한 버전에서 긴급하게 수정이 필요한 장애 및 버그 발생 시 대응하는 브랜치이다.
hotfix 는 master 로부터 분기되며, 이슈가 수정되면 수정 사항은 master, develop 브랜치에 최종 반영되어야 한다.
🏷 GitFlow 실습
Git-flow 실습을 진행해보았다.
루트 디렉토리에 gitflow_test 라는 폴더를 만들었다.
1. 깃 브랜치 초기화
git flow init
➡️ 모두 default 옵션으로 초기화했다.
git branch 를 통해 브랜치를 조회해보면 두개의 브랜치가 생겼다.
이제부터 로그인 기능을 구현한다 가정하고 실습을 진행하겠다.
2. feature branch 생성
git flow feature start [개발할 기능명] 명령어를 통해 브랜치를 생성한다.
feature 브랜치를 생성하면 자동으로 체크아웃이 된다.
로그인 기능을 구현하는 LoginServiec.java 자바코드를 작성하고, 커밋을 만들었다.
git flow feature finish [개발 완료한 기능명]
기능 개발이 완료되었다고 가정하고 브랜치를 종료해보자.
브랜치를 종료하면, 자동으로 브랜치가 develop 브랜치로 바뀌었다.
깃 히스토리를 확인해보면 브랜치명이 모두 develop 브랜치로 통일되어 있는 것을 확인할 수 있다.
브랜치 조회 결과 또한 feature/login 브랜치는 삭제되어있다.
원활한 실습을 위해 develop 브랜치에 MainService.java 라는 새로운 파일을 만들고 Commit#2 를 생성했다.
깃 히스토리 확인!
3. release branch 생성
git flow release start [버전명]
develop 브랜치에 어느정도 개발이 완료됐다 가정하고 release 브랜치를 만들었다.
마찬가지로 생성과 동시에 체크아웃까지 되었다.
새로운 커밋 생성을 위해 MainService.java 를 수정하고 commit#3 을 생성하였다.
git flow release finish [버전명]
release 에서 모든 작업이 끝났다 가정하고, release 브랜치를 종료한다.
release 에 있는 커밋들을 master로 커밋한다는 머지 커밋이 발생한다.
태그에 대한 메시지도 입력한다.
release 브랜치 태그 1.0을 develop 브랜치로 병합한다는 또 한번의 머지 커밋이 발생한다.
기존의 release 브랜치가 삭제되고 develop 브랜치로 자동으로 체크아웃되었다.
현재까지의 히스토리이다.
4. hotfix branch 생성
git flow hotfix start [버전명]
긴급 이슈가 발생했다 가정하고 hotfix 브랜치를 생성했다.
생성과 동시에 hotfix 브랜치로 체크아웃되었다.
버그 수정을 한다 가정하고, 기존의 MainService.java 파일을 수정해 커밋을 하나 생성했다.
git flow hotfix finish [버전명]
hotfix 에서 버그 수정을 완료했다 가정하고, hotfix 브랜치를 종료했다.
머지 커밋이 발생했는데 이는 hotfix 브랜치에 있는 내용을 master 로 머지하겠다는 내용이다.
태그 메시지를 작성한다.
이전의 release 브랜치와 같이, hotfix 브랜치의 내용을 develop 브랜치로 머지하겠다는 또 하나의 머지 커밋이 발생한다.
기존의 hotfix 브랜치가 삭제되고 develop 브랜치로 자동으로 체크아웃되었다.
git branch 명령어를 통해 현재 브랜치 상황을 살펴보면, 생성했던 release, hotfix 브랜치가 사라지고 초기의 브랜치 2개만 남은 것을 확인할 수 있다😃👍🏻
이렇게 2주차 첫번째 강의인 "실무자가 알려주는 Git 활용한 프로젝트 관리" 도 끝이 났다!
코드프레소 홈페이지(https://www.codepresso.kr/)에는 오늘 포스팅한 GitFlow 관련 강의뿐만 아니라 다양한 강의들이 개설되어 있으니 모두 한번 씩 살펴보고 수강해보면 좋을 것 같다😃
