이전 Post를 통해 Git-flow에 대한 간략히 설명하였고, Branch 전략을 수립해 보았습니다.
이번 Post에서는 수립한 Branch 전략으로 어떻게 업무가 수행 되는지 사례를 바탕으로 설명드리겠습니다.
이 글에서는 Git의 다양한 개념과 명령어가 자주 사용되었기 때문에 Git에 대해 잘 모르시거나, 글을 읽는 중간 중간 알고 싶은 Git의 개념이 있다면 아래 링크를 방문해 보세요.
사전 학습 자료 : 누구나 쉽게 이해할 수 있는 Git입문
1. Git Flow 설치
Git-flow 기반으로 Branch 전략을 수립했기 때문에 우선 Git-flow를 설치해야 한다.
이미 설치되어 있다면 다음 장으로 바로 넘어가시면 됩니다.
Git-flow CLI 설치 방법
VSCode의 extension을 설치하여 사용할 수 도 있는데 이렇게만 사용하실 분들은 바로 VSCode extension 설치 방법으로 바로 넘어가시면 됩니다.
Github에서 해당 링크 클릭
자신의 OS에 맞는 링크를 클릭하여 설명하는데로 설치를 진행하면 됩니다.
제 OS가 윈도우이기 때문에 윈도우 설치 방법에 대해서는 자세하게 설명드리겠습니다.
윈도우에 Git-flow 설치
-
먼저, Git 설치 되어 있어야 합니다.
Git 설치는 여기를 클릭하시면 됩니다. -
그런 다음 윈도우 Gitflow 설치 안내 페이지로 이동
-
페이지를 스크롤하여 아래로 내리면 Git for Windows (previously MSysGit)가 있다.
-
안내하고 있는 라이브러리 3개(util-linux package, libintl, libiconv)의 binaries zip 파일을 모두 다운로드 한다.
-
다운로드한 세개의 zip 파일을 압축을 풀고,
util-linux-ng-2.14.1-bin/bin/getopt.exe,
libiconv-1.9.2-1-bin/bin/libiconv2.dll,
libintl-0.14.4-bin/bin/libintl3.dll
파일을 설치된 Git의 bin 디렉토리에 Copy합니다. -
설치가 완료되었으면, 윈도우 CMD 또는 powershell을 관리자 권한으로 실행시킵니다.
-
실행 창에 아래 Command를 입력하여 gitflow를 clone 합니다.
git clone --recursive https://github.com/nvie/gitflow.git- clone 된 gitflow 디렉토리로 이동
cd gitflow- git-flow를 Git에 설치
contrib\msysgit-install.cmd "[path to git installed folder]"위 명령어를 실행하면 git-flow와 관련된 파일들이 Git의 bin 디렉토리에 설치되는것을 확인 할 수 있다.
이렇게 했더니 저같은 경우에는 Git에 명령어를 날릴때마다 다음과 같은 에러가 발생했을 했습니다. 조치하는 방법은 아래 링크를 클릭하시면 됩니다.
fatal: credential-cache unavailable; no unix socket support
Git no unix socket support warnning 조치방법
VSCode에 Git-flow 설치
extention탭에서 gitflow 검색하여 설치하면 끝!
2. 기본 Branch 생성
git flow를 이용한 Branch 생성 (Collaborator Role)
git flow로 master, develop, feature, hotfix, release, support branch를 생성할 수 있습니다.
예시를 위해 Yona에 react-nexjs-ts라는 repository를 생성했습니다.
- git clone을 실행하고 해당 디렉토리로 이동합니다.
git clone https://계정@yona.ssc.co.kr/boiler-plate/react-nextjs-ts
cd react-nextjs-ts- git flow init을 이용해 기본 Branch 생성
git flow init
feature, bugfix, release, hotfix, support Branch 명을 입력하라고 나오고 Tag Version, Hooks directory를 입력하라고 나옵니다.
저 같은 경우는 그냥 무조건 엔터 엔터 치고, Tag Version만 1.0을 입력했습니다.
-
생성된 Branch 확인
생성한 Branch 중 develop이 기본 Branch로 선택 되어 있는 것을 확인 할 수 있다. -
remote repository에 Branch를 push한다.
현재 브랜치들은 local repository에만 존재하기 때문에 origin에 반영해 줘야 합니다.git push origin --all
push 명령을 입력하고, Yona에서 확인해 보면 develop Branch가 추가가 된것을 확인할 수 있다.
현재 branch는 master와 develop 브랜치만 보이며, 둘은 동기화 되어 있는 상태입니다.
이렇게 생성된 branch들은 checkout 명령어로 전환이 가능합니다.
git checkout [Branch명]기본적인 셋팅은 완료 되었습니다.
이제 Sprint 기간 동안 develop Branch와 feature Branch가 어떻게 관리 되는지 살펴보겠습니다.
3. Sprint 진행
Feature Branch 생성(개발팀 Role)
스프린트 기간 중 자신이 만들어야 하는 기능 구현을 위해 기능별 Feature Branch를 만듭니다.
// feature Branch 생성 후 생성된 feature branch로 checkout git flow feature start [feature Branch명]
git flow를 이용하면, feature branch는 develop branch를 대상으로 생성됩니다.
이렇게 feature branch를 생성(시작)했다면 바로 origin에 push합니다.
다른 개발자들도 feature Branch가 생성되었음을 알아야 하잖아요?
// feature push git push origin feature/config
이제 feature Branch에서 개발을 진행합니다.
개발을 진행하면서 수시로 commit과 push를 수행합니다.
commit과 push 명령은 다들 잘 알고 있기 때문에 생략 합니다.
Feature Branch 종료(개발팀 Role)
개발 완료 및 단위 테스트가 완료 되면, Yona에서 Collaborator(책임자)에게 코드 주고받기로 Pull Request(Merge Request)를 요청 합니다.
Pull Request(Merge Request) : branch를 Merge해도 되는지를 물어보는 프로세스
Yona에 접속해서 아래 이미지의 순서대로 확인 하시고, 코드보내기를 누르면 Pull Request가 등록됩니다.
Collaborator(책임자)는 코드 리뷰 진행 후 이상이 없을 경우 개발자에게 Merge를 요청합니다.
물론 화면에서 보이는것과 같이 Yona에서 코드병합을 눌러도 되지만, git flow의 feature branch finish 명령을
이용하면, Merge와 branch삭제가 편리하기 때문에 Yona를 사용하지 않고, 개발자가 직접 Merge 하도록 하겠습니다.
이제 Feature branch 작업자는 git flow 명령어로 feature branch를 삭제 할 수 있습니다.
// feature Branch 종료 git flow feature finish [Branch명]
finish 명령이 완료되면 feature branch가 develop branch에 Merge되고,
로컬과 remote 모두 feature Branch가 삭제 됩니다.
다른 featrue Branch로 개발중이던 팀원들은 develop branch가 변경되었기 때문에
develop branch를 origin에서 pull 받아 동기화 처리하고, 작업 중인 feature branch에
merge 명령을 입력해 소스를 Merge하거나 rebase를 통해 branch의 base를 재설정 합니다.
=> 나중에 가서 한꺼번에 merge했을때 conflict가 발생하는 것을 방지 하기 위함 입니다.
// develop branch pull git checkout develop git pull
Branch Merge
// develop branch와 feature branch 소스 병합
git checkout feature/[branch명]
git merge --no-ff develop
또는 Branch Rebase
// develop rebase
git checkout feature/[branch명]
git rebase develop
이렇게 Sprint 기간 동안 feature Branch와 develop Branch가 변경과 Merge를 반복하며 Backlog를 완료해 갑니다.
4. QA 활동
QA 시작
Release Branch 생성(Collaborator Role)
개발된 feature 중 운영에 배포해야 할 사항이 존재한다면, release branch를 생성합니다.
release branch는 Tag(버전 번호) 형태로 branch를 생성합니다.
git flow release start <tag>// release branch 생성 git flow release start 1.1.0 // release branch origin push git push origin release/1.1.0
release branch는 Tag Base로 만들어지기 때문에 기존 버전번호의 Tag가 남아있을 경우 생성되지 않습니다.
이때에는 Tag를 삭제하고 생성하면됩니다.
이제 release branch가 생성되었기 때문에 QA서버에서 테스트가 진행됩니다.
버그 수정
Release Branch commit/push(개발팀 Role)
QA중 버그 또는 수정사항이 발견하게 되면 release branch에서 코드를 수정하고 commit과 push를 진행합니다.
bugfix branch는 별도로 관리하지 않습니다.
QA 완료
Release Branch 종료(Collaborator Role)
QA가 완료되고 운영에 배포할 수준이 되었다면, Release branch를 종료합니다.
git flow release finish <tag>// master로 이동하고 remote local의 master repository 동기화 git checkout master git pull // release branch 종료 git flow release finish 1.1.0
변경사항 origin에 반영
=> 이때 follow-tags를 옵션 처리 합니다.(커밋과 태그 전체를 동시에 푸시)
=> 운영 문제 발생시 Tag 단위로 reset을 수행할 것이기 때문에 follow-tags를 붙여줍니다.
// local 변경 사항 origin에 반영 git push origin --all --follow-tags
release가 finish되면, release branch의 변경사항이 master에 Merge 되고,
master의 변경사항이 develop branch에 Merge됩니다.
물론, release branch 자체는 삭제되고, release Tag(번호)만 git에 남겨집니다.
Feature Branch Merge/Rebase(개발팀 Role)
다른 featrue Branch로 개발중이던 팀원들은 develop branch가 변경되었기 때문에
develop branch를 origin에서 pull 받아 동기화 처리하고, 작업 중인 feature branch에
merge 명령을 입력해 소스를 Merge하거나 rebase를 통해 branch의 base를 재설정 합니다.
// develop branch pull git checkout develop git pull
Branch Merge
// develop branch와 feature branch 소스 병합
git checkout feature/[branch명]
git merge --no-ff develop
또는 Branch Rebase
// develop rebase
git checkout feature/[branch명]
git rebase develop
5. 운영 관리
운영 배포
master Branch 배포(QA, Collaborator Role)
jenkins를 이용해 Git master의 Tag를 기준으로 master branch를 운영에 배포 합니다.
이제 부터는 운영에 버그가 발견되었을때 hotfix branch를 이용하여 처리 하는 방법에 대해 설명 드리겠습니다.
운영 버그 수정
hotfix Branch 생성(개발팀 Role)
hotfix branch는 master branch에서 branch를 생성합니다.
hotfix도 Tag Base이기 때문에 버전 번호를 입력합니다.
버전은 minor 번호를 증가시켜 올립니다.
//release가 1.1.0이었으니까 1.1.1로
git flow hotfix start 1.1.1자동으로 Branch가 Switch됩니다. hotfix가 생성됐음을 모두에게 알려야 하기 때문에 바로 push를 수행합니다.
git push origin hotfix/1.1.1
버그 수정 후 commit과 push를 수행합니다.
코드리뷰 요청(개발팀 Role)
feature와 마찬가지로 Yona에 pull request를 등록합니다.
배포는 hotfix -> master로 머지됩니다.
코드리뷰 (Collaborator Role)
Collaborator(책임자)는 코드 리뷰 진행 후 이상이 없을 경우 개발자에게 Merge를 요청합니다.
Pull Request가 승인되면 개발자는 hotfix branch를 종료시킵니다.
hotfix branch 종료 (개발팀 Role)
개발자는 hotfix branch를 master,와 develop에 머지합니다.
hotfix finish 할때는 반드시 master로 branch를 이동시킨 후 명령어를 입력합니다.
// master로 branch 이동 git checkout master // hotfix 종료 git flow hotfix finish 1.1.1 // 태그와 commit 정보 origin 변경 사항 반영 git push origin --all --follow-tags
feature Branch Merge/Rebase(개발팀 Role)
다른 hotfix Branch가 develop branch와 master branch로 머지되었기 때문에
작업 중인 feature branch에 merge 명령을 입력해 소스를
Merge하거나 rebase를 통해 branch의 base를 재설정 합니다.
// develop branch pull git checkout develop git pull
Branch Merge
// develop branch와 feature branch 소스 병합
git checkout feature/[branch명]
git merge --no-ff develop
또는 Branch Rebase
// develop rebase
git checkout feature/[branch명]
git rebase develop
여기 까지 기본적인 개발 프로세스와 버그 조치 프로세스의 branch 운영 방식을 소개했습니다.
물론, 개발 진행 중에 이렇게 단순하게 branch가 운영되지는 않을 것입니다.
Conflict가 발생할 수도 있고, Merge가 어려운 상황도 있을 수 있습니다.
운영 긴급 패치를 위해 현재 개발 중인 소스와는 다르게 hotfix에 적용 해야 하고,
cherry-pick, reset, revert를 사용해 코드를 관리해야 하는 어려움이 있을 수 있습니다.
어떻게 처음부터 잘 할 수 있겠어요?
서비스의 안정적인 운영과 개발자들의 기술 향상 및 소스코드 품질 확보를 위한 방안이니
서로 성장할 수 있는 동반 성장의 계기로 삼았으면 합니다.
아래는 개발 팀이 업무 수행간 가져야 할 소스코드관리 원칙입니다.
6. 소스 코드 관리 원칙
- 신규 기능 / 기능 개선 작업 진행 시 Feature branch를 기능별로 무조건 생성한다.
- develop branch에 Merge한 Feature branch는 삭제한다.
- Commit/Push 1일 1회 이상 무조건 수행
- Develop Merge는 코드 리뷰 완료 후 진행
=> Pull request(Merge Request) 요청 후 승인 된 경우 머지 진행 - Merge 전에 테스트하고, Merge 후 테스트한다.
- 개발 진행 시 관련 Jira이슈가 존재하지 않을 경우, 팀 리딩을 담당하는 주체에게 이슈 생성하고, 이 이슈번호를 featrue branch의 Name으로 생성한다.
- 커밋 메시지는 반드시 자세히...
