본문 바로가기

공부 정리/Git

Git Flow 사용해보기

728x90
반응형

*개요

sourcetree를 공부해보면서 깃 플로우 전략을 손쉽게 버튼클릭으로 이용할 수 있다는 것을 알게되었습니다. 많은 회사들이 깃플로우 전략을 사용하는 것으로 아는데, 혼자서만 git을 사용해보는 것이 아니라, 나중에 협업할 때 git을 자 사용하기 위해서 기능 사용들을 정리해보았습니다.

 

github repository에서 git의 default branch인 main을 master로 변경합니다. 이 때, github에서 친절하게 local repository에서 default branch를 변경하는 방법을 제공합니다. ( 그냥 main으로 해도 무방합니다 )

 

 

 

git clone <원격 repository>로 Github 저장소를 local git에 clone합니다.

 

 

git flow init으로 git flow 를 시작합니다. 항목에는 master, develop, feature, release, hotfix, support가 있으며, 각각은 이름을 수정할 수 있습니다.

 

 

 

git flow 시작에 따라서, master와 develop branch만 존재합니다. 이는 local repository에만 생성되었기 때문에, origin repository에 develop branch를 등록하기 위해서 push 합니다.

 

 

 

원격 저장소에서 branch 리스트를 보면, develop이 추가되어있습니다.

 

 

이제 본격적으로 기능구현을 시작합니다. 기능구현은 feature를 사용합니다. login 기능을 만들예정이므로 아래와 같이 시작합니다. 이제 branch는 master, develop뿐만 아니라 feature/login이 추가되었습니다.

 

 

local repository에 추가된 branch를 원격 repository에도 추가하도록 push합니다.

 

 

이제 원격 repository에도 feature/login이 추가되었습니다.

 

 

login 기능구현을 짧게 예시로 만들어봅니다. 단순히 txt파일에 login finished로 마치 login 구현이 끝난 것처럼 상황을 만들었습니다. 기능을 만들었으니, Pull Request를 통해 승인을 받아야 합니다. 따라서 원격 repository에 push를 합니다.

 

 

Github에 접속하면, push를 했던 feature/login branch를 pull request 하라는 업데이트 문구가 만들어집니다.

 

 

이와 동시에, 다른 사람은 회원가입 기능을 만든다고 가정해보겠습니다. 새로운 feature를 start합니다. local repository에만 생성된 branch이기 때문에 원격 repository에도 등록하기 위해 push해야 합니다.

 

 

Github에 와서 확인해보니 feature/register라는 branch가 추가되어있습니다.

 

 

다시 login 기능으로 돌아와서, Pull Request를 진행합니다. [compare]는 local repository에서 pull request를 요청한 branch이고 [base]는 원격 repository에서 pull request를 요청받은 branch입니다. 제목과 내용을 적고 Create pull request를 합니다.

 

 

일반적으로 pull request는 develop에 요청을 하기 때문에 왜 master에 하는지 의문이 들 수 있습니다. 이는 다양한 전략을 가져가는 방법 중 하나인데, 당연히 master에서 바로 merge하지 않습니다. approve를 하고, merge하지 않은 상태에서 close를 할 예정입니다. Review changes에서 Approve를 선택하고 리뷰를 남깁니다

 

 

리뷰가 완료되면, pull request를 날린 사용자는 merge하지 않고 close를 합니다.

 

 

또한 close이후 바로 delete branch를 하면 branch 목록에서 바로 사라집니다

 

 

이제 로그인 기능 구현이 모두 끝나고 승인을 받았습니다. 따라서 승인을 받았다면, branch를 종료하면 됩니다. 종료가 되면, local repository에는 feature/login branch가 사라지고, 해당 내용이 develop에 merge가 됩니다. 또한 현재 branch가 feature/login이 삭제되었으므로 develop으로 이동합니다.

 

 

branch 리스트를 확인해보니, feature/login이 제거되었습니다.

 

 

local repository에서만 삭제된게 아니라 origin repository에서도 feature/login은 삭제됩니다.

 

 

열심히 회원가입을 만들고 있던 개발자는 login 구현이 끝나서 feature finish가 되었다는 소식을 들었습니다. develop은 자동으로 merge를 안내하지만, 다른 feature들은 해당 내용을 알지 못합니다. 따라서, 작업도중에 register 기능을 만들고 있던 개발자는 수동으로 최신 develop을 merge합니다.

 

 

merge를 한다는 메시지를 작성합니다.

 

 

그 결과 다음과 같이 변경사항이 나옵니다.

 

 

이제 register 작업을 지속하고 commit과 함께 작업을 끝냅니다.

 

 

login 기능이 구현된 것을 기반으로 배포를 한다고 가정합니다. 이제 release를 사용할 차례입니다.

 

 

release에서는 bug가 발생했다고 생각하고 버그 수정을 하며, release가 완료되었다는 작업을 합니다.

 

 

local repository에서 했던 작업을 origin repository에 push합니다. 현재, release와 feature/register의 2개가 push됩니다.

 

 

origin repository에는 다음과 같이 pull request를 안내하는 알림이 뜹니다.

 

 

release를 반영해야 하기 떄문에 release/0.1.0을 master에 pull request를 요청합니다.

 

 

pull request 목록에 가면 다음과 같이 초록색 아이콘을 가진 게시글로 나옵니다.

 

 

리뷰가 완료되면 반영해도 좋다는 표현으로 Approve를 합니다.

 

 

리뷰가 끝났다면, 이제 Close with comment로 종료하면 됩니다

 

 

pull request로 코드리뷰를 받았으니 local repository에서 release를 종료합니다

 

 

release를 종료하면 크게 2가지 반영이 안내됩니다. 1번은 master이고 2번은 develop입니다. 1번을 master에 merge하기 위한 메시지를 먼저 작성합니다

 

 

태그 정보를 적어줍니다

 

 

태그 정보를 가지고 develop에도 merge를 합니다

 

 

현재 local repository에만 반영이 되어있기 때문에 origin repository에도 반영을 하기 위해 push합니다.

 

 

그런데, 새로 생성한 0.1.0 태그 정보가 origin repository에는 나오지 않습니다.

 

 

태그 정보도 다음과 같이 push를 한다고 명시해주어야 합니다

 

 

이제 origin repository에 Tags 정보가 나옵니다.

 

 

이제 feature/register 기능을 모두 종료합니다. origin repository에 push 합니다.

 

 

 

역시나 pull request를 날렸다면, 리뷰를 통해 Approve를 확인받습니다.

 

 

코드리뷰가 끝나면, Close with comment로 pull request를 닫아주고 branch를 삭제합니다.

 

 

branch가 삭제되었으니, local repository에서 feature register를 끝냅니다.

 

 

feature를 종료하면 다음과 같이 자동으로 develop에서 merge를 하며, 메시지를 입력합니다

 

 

현재 develop에서 merge한 내용은 local repository에만 적용되어있기 때문에 꼭꼭 origin repository에 push해야 합니다.

 

 

이제 register 기능이 추가된 develop을 배포하고 싶습니다. 그래서 release를 새로 0.2.0으로 생성하고 origin repository에 push합니다.

 

 

마찬가지로 Approve를 확인받습니다.

 

 

이후 Close with comment로 종료하고 branch를 삭제합니다

 

 

release를 finish하고 master, develop에 반영하기 전에 문제가 발생했습니다. 현재 배포된 버전은 0.1.0으로 hotfix가 필요한 상황입니다. 새로운 hotfix를 생성합니다.

 

 

로그인 기능에 오류가 있기 때문에 수정을 하고 pull request를 날리겠습니다.

 

 

pull request 목록에 올라간 hotfix 리스트입니다

 

 

모든 코드리뷰가 끝났다면, 다시 local repository로 돌어와서 hotfix를 끝냅니다.

 

 

hotfix도 마찬가지로 master와 develop에서 각각 merge하도록 안내합니다

 

 

hotfix는 버그수정이기 때문에 맨 마지막에 있는 0을 1로 수정하여 0.1.1로 태그를 만듭니다

 

 

마지막으로 develop에서 merge합니다

 

 

release 0.2.0을 배포하기 위해서 pull request를 끝내 둔 상태인데, 새로운 hotfix 수정이 있었기 때문에 꼭 develop을 merge해야 합니다.

 

 

merge 한다는 메세지를 작성합니다

 

 

현재 local repository에서 merge를 하며 수정사항이 생겼습니다. 바로 origin repository에 반영합니다

 

 

Relase 0.2.0에 오기까지 수행한 commit 과정을 확인할 수 있습니다.

 

 

pull request가 끝났다면, local repository에서 release를 finish합니다.

 

 

release는 위에서 한번 했던것과 마찬가지로 master와 develop에서 merge를 진행합니다. hotfix도 release와 같은 순서로 진행되었습니다.

 

 

새로운 버전인 0.2.0으로 태그를 만듭니다.

 

 

마지막으로 develop에서 merge합니다

 

 

다음과 같이 release 0.2.0이 finish가 끝났습니다.

 

 

이제 local repository에만 반영된 사항을 origin repository에도 push합니다. 이 때 새로운 태그버전이 생성되었으므로 태그버전도 같이 push하는 것을 잊지 않습니다.

 

 

그렇다면 origin repository에 정상적으로 최신의 release 0.2.0이 반영이 되었고 배포를 하면 됩니다.

728x90
반응형