![[Git] Git flow 정리 및 실습](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FF8C33%2FbtrtmUybfsW%2FhfN58c9Dj3lJTNJjG40BE1%2Fimg.png)
Git flow 개념에 대한 정리는 Vicent Driessen의 글로부터 하게되었다.
https://nvie.com/posts/a-successful-git-branching-model/
들어가기전에
학교에서 프로젝트를 진행할때 git을 교수님이 쓰라고 하셔서 써본 기억이 있다.
평소에 repo를 그냥 code 저장소로 사용하기만 했었기 때문에 협력 툴로써 git은 처음 사용하는 거였다.
대부분의 코딩 팀플이 그러듯 해당 과정에서 branch의 의미는 무색해졌고 결국에는 4명이 모두 main에서 작업하는 경이로운 프로젝트가 되었었다.
당시에 이 글만 읽고 진행했어도 더 좋은 git관리를 했을 텐데 아쉬움이 느껴진다.
탈중앙화와 중앙화를 동시에
프로젝트로 작업하다보면 프로젝트 내에 각자의 역할이 존재한다. 그렇다고 모두가 같은 파일로 이를 진행할 수는 없을 것이다. 하지만 git을 사용하면 각자의 로컬 저장소에서 코드를 수정, 실험 할 수 있다. 그냥 branch를 따서 하거나 fork를 해서 사용하면 될 것이다. 이렇듯 git을 사용하면 탈중앙화된 코딩 환경을 조성할 수 있다. 하지만 결국에는 코드를 합쳐야하기 때문에 pull과 push를 진행할것이다. 따라서 프로젝트의 소스 코드는 중앙화가 될 것이다.
그럼 어떻게 branch를 조성하고 프로젝트를 진행해야 효율적인 프로젝트 관리가 될까?
먼저 전체적인 개요는 아래와 같다.
Main branch
전체적인 프로젝트의 소스코드를 담당하는 브랜치들로 프로젝트가 생기고 항상 유지되는 브랜치들 이다.
크게 2가지 브랜치가 존재한다.
- master
배포 하기 바로 전 단계의 브랜치로 최종 검토, 리뷰 등이 완성된 코드들이 모여있다. 프로젝트의 배포 코드들이 이에 해당한다.
- develop
master 브랜치는 배포 가능한 코드들이 모여있어야 한다. 그렇다고 여러 branch가 바로 master 브랜치로 merge한다고 항상 코드가 안정적일까? 그러면 참 좋겠다.. 하지만 우리는 merge를 하고 안정화 작업을 해야한다. 따라서 master branch에서 처음 시작지점에 새롭게 branch를 따서 전체적인 개발과정을 진행하는 브랜치를 develop 브랜치라고 하고 대부분의 개발은 이 브랜치에서 진행된다.
Supporting branch
이제 그럼 그냥 develop 브랜치에서 코딩을 하면되겠다! 라고 생각 할 수도 있다. develop 브랜치는 여러 기능들이 합쳐졌을 때 이를 시험하는 브랜치이다. 따라서 우리가 실제로 코딩을 진행할 브랜치들이 존재해야하는데 이들을 Supporting branch라고 이야기한다.
Supporting branch에는 크게 3가지의 브랜치가 존재한다.
- Feature branches
- Release branches
- Hotfix branches
각각의 branch들은 잠시 만들어졌다가 없어지기 때문에 이들이 수행하고 있는 작업에 따라 branch이름이 정해진다.
[Feature branch]
프로젝트 내에 어떤 기능이 추가어야 할때, 즉 에자일보드에서 티켓이 추가되었을때 생성되는 브랜치로 develop branch로 부터 파생되어진다.
이러한 브랜치는 프로젝트 내에 기능이 개발되는 동안 유지되었다가 기획자가 필요없는 기능이라 하면 버려지거나 아니면 결국에 최종적으로 develop 브랜치에 합쳐질 수 있다.
💡 Branch 이름
[feature/기능요약] ex) feature/login
[Release branch]
배포를 위한 브랜치로 주로 버그 수정이나 문서 정리등의 업무를 진행하는 branch이다. 여기서 중요한것은 해당 브랜치에서는 많은 기능을 추가하거나 고치지 않는다는 것이다.
단순히 배포를 위한 branch이기 때문에 그러한 기능들은 애초에 feature branch에서 추가되고 develop에 넘어온 상태에 develop에서 안정화 까지 끝난 상태를 가정하고 분기한다.
develop에서 안정화가 된 코드에서 버전 관리와 관련된 내용만 수정되고 나면 이를 master branch와 merge 시켜 최종 배포 코드를 완성 시킨다.
💡 Branch 이름
[release-*] ex) release-1.0
[Hot fix branches]
배포를 한다고 해도 버그가 없을 순 없다. 서비스가 진행됨에 따라 여러 문제 상황이 발생할 수 있기 때문이다. 따라서 배포 버전에서 버그를 수정하는 branch를 만들게 되는데 이를 hotfixes 브랜치라고 한다.
hot fix로 고쳐진 master 브랜치의 코드는 develop branch에서 수정중인 코드보다 버전이 높기 때문에 이를 따라가기 위해서는 hot fix branch는 develop branch에도 적용이 되어야한다.
💡 Branch 이름
[hotfix-*] ex) hotfix-1.0.1
전체적인 흐름도를 만들어보면 다음과 같이 표현할 수 있을 것이다.
[실습]
해당 프로젝트는 자바를 이용한 난수 계산기를 만들기 위한 실습으로 현재 코드는 다음과 같이 되어있다고 가정하고 source tree에서는 다음과 같이 표시되어있다.
[1. 사칙연산 추가를 위한 feature branch 생성 ]
계산 기능을 추가해야한다고 가정하고 다음 4개의 feature브랜치를 생성한다.
해당과정에서 필요한 쉘 명령어는 아래와 같다.
git checkout -b feature/[사칙연산] develop
[2. 기능 개발 및 테스트]
충돌을 해결하는 과정을 경험하기 위해 일부로 충돌을 일으키는 상황을 만들어보았다.
이후 각 브랜치에서 내용을 커밋해보면 소스트리에서 다음과 같이 나오는 것을 볼 수 있다.
이후 해당 기능들에 대해 각 branch에서 기능에 대한 Test를 진행했다.
[3. 커밋 메세지 정리 ]
각 branch에서 기능을 개발하다보니 여러 커밋 메세지가 생겼다. 이를 모두 develop 브랜치에 옮기게 되면 develop 브랜치에 commit 이력은 매우 복잡하게 될 것이다. 따라서 각 브랜치에서 커밋 메시지를 정리하는 과정을 거쳤다.
git rebase -i HEAD~squash할 갯수
다음 쉘 명령어를 통해 커밋 메세지를 합칠 수 있다.
commit 메세지를 정리할 브랜치에서 해당 명령어를 실행하면 왼쪽과 같은 창을 만나게 되는데 이를 오른쪽 처럼 수정하면 commit이 합쳐진다.
이 과정을 아까 복잡했던 커밋 메세지들이 정리되는 것을 볼 수 있다.
[4. develop 브랜치로 merge 진행하기 ]
먼저 feature/add 브랜치를 develop과 합치자
그 다음 feature/add를 지우자
다음 feature/sub와 merge를 진행하면 같은 파일을 수정하였기에 충돌이 일어나고 다음과 같이 브랜치와 코드가 바뀌게 된다.
충돌 나는 부분을 수정하고 add와 commit을 진행하면 다음과 같이 소스트리가 정리되는 것을 볼 수 있다.
[4. 배포 버전 만들기 ]
develop 브랜치에서 release-1.0브랜치를 만들고 Release Note를 만들어 commit을 해보자.
[5. Master 브랜치와 합치기 ]
이렇게 우리의 계산기가 v0.0에서 v1.0으로 업그레이드 되었다.
근데 문제가 생겼다.
자릿수가 너무 길어서 화면에 글씨가 깨진다는 연락이 들어왔다.
하는 수 없이 우리는 빠르게 현재 배포된 버전에서 생성되는 난수를 10의 자리 아래로 고정해야한다.
[6. Hot Fix branch로 master branch 수정하기 ]
먼저 hotfix-1.0.1 branch를 만들고 해당 브랜치에서 오른쪽 사진과 같이 코드를 수정하고 master 브랜치와 병합을 진행했다.
한편...
어떤 개발자가 v1.0에서 사용자한테 숫자를 받아 이를 처리하는 메소드를 만들고 아래와 같이 develop branch에 병합을 진행했다고 하자.
아직 hotfix branch로 고친 부분이 develop에 반영이 되지 않은채로 개발자가 코드 기능 추가를 하여 develop 브랜치는 v1.0으로 진행하고 있고 현재 배포된 버전은 1.0.1이 된 불상사가 일어났다.
따라서 hotfix branch의 수정부분은 develop branch에도 아래와 같이 반영을 해야하는 것이다.
'개발 > Git' 카테고리의 다른 글
| [git] reflog : 선배의 커밋을 날렸을 때(git reset --hard복구 방법) (1) | 2024.04.04 |
|---|