Git Flow 팀단위 관리법
#
Find similar titles
- 최초 작성자
- 최근 업데이트
Structured data
- Category
- Programming
Git Flow 팀단위 관리 방법 #
목차 #
- 서론
- 대상
- 순서
- 장점과 단점
- 작성 예시
- 정리
- 참고문헌
서론 #
최근 다양한 프로젝트 개발 과정 중 많이 사용하는 형상 관리 도구에는 SVN과 깃이 있다. 그중에서 오늘은 깃에 대해서 살펴볼 것이다. 대부분 컴퓨터 공학 저학년 학생 혹은 처음 입문한 프로그래머라면 아마 처음 프로젝트를 진행할 확률이 높을 것이다. 이때는 굳이 깃, 깃허브, 깃랩을 사용하지 않는다. (아마 원격 저장용 정도만?) 하지만 고학년이 되어 팀 단위 프로잭트(ex: 해커톤)를 진행하다 보면 형상 관리의 중요성에 대해서 다시 한번 느끼며 어떻게 팀 단위로 프로젝트를 관리하는지 찾아보게 된다. 이 글을 보고 나면 팀 단위로 기본적인 관리를 어떻게 하는지 조금은 이해하고 넘어갈 수 있다고 생각한다. 마지막으로 프로젝트 시발점을 기준으로 글을 작성했으니 참고 바란다.
순서 #
- 우선 깃헙 아이디를 만들고 그 계정을 팀원들에게 공유한다.
- 인텔리제 기준으로 상단 탭에 Git에 들어가서 해당 아이디 계정 깃헙에서 발급한 Token으로 로그인하여 remote와 연결한다.
- 팀 리더가 git branch -u main, git branch -u develop, git branch -u hotfix 브랜치를 생성한다.
- 팀원들은 git fetch로 새롭게 생긴 브랜치를 업데이트 후 git checkout develop 브랜츠로 이동한다.
- 팀원들은 develop 브랜치에서 각자 분야에 맞는 브랜치를 develop 브랜치에서 파생시켜 새로운 브랜치를 만든다.(ex: (main에서 시작) git fetch -> git checkout develop -> git branch -u feature-frontend-001-main-page -> git checkout feature-frontend-001-main-page)
- 해당 브랜치에서 작업 후 git add . -> git commit -m "[feature] 메인 페이지 작성 #001" -> git push 혹은 git push origin feature-frontend-001-main-page 하여 변경된 코드를 푸쉬한다.
- 다시 develop 브랜치로 돌아와서 작업한 브랜치를 merge한다.(git checkout develop -> git pull -> git merge feature-frontend-001-main-page
- 이제 다음 이슈부터는 5번부터 7번까지 순서를 반복하면 된다.
장점과 단점 #
이러한 Git Flow는 단점보다는 많은 장점이 있다. 단점부터 설명하면 작은 변경 지점이 있어도 이 프로세스를 따르면 매우 귀찮음을 느낄 수 있다. 하지만 규칙 즉 룰은 항상 예상치 못한 상황을 대비하기 위해서 만들어졌다. 하나의 브랜치에 여러 사람이 pull, push를 하면 하나의 파일에 두 명 이상이 변경할 때 충돌이 나고 프로젝트가 커지고 사람이 많아지면 어디서 누가 손을 대서 충돌이 나는지 확인하기가 힘들다. 하지만 feature 단위, hotfix 단위(단어는 아래 참조 바람) 로 따로 브랜치를 파서 관리하면 실수가 있는 브랜치를 도려내기 쉽고(revert) 누가 실수했는지 쉽게 찾을 수 있어(ex: 로그인 아이디 입력 페이지 버그가 있는데 37번 feature 브랜치 만든 사람?) 대응이 빠르다. 따라서 처음은 '뭐 소규모인데 번거롭게 굳이 이걸 해야 해?'라며 넘어가려고 하겠지만(나도 한때는 그랬다) 습관이 되면 금방 브랜치 제작, 병합을 할 수 있으므로 크게 걱정하지 않아도 된다.
-
feature: 프론트앤드 기준으로 새로운 UI, 새로운 기능을 제작할 때 사용하는 branch이다.
-
hotfix: 서비스 릴리즈 후 버그 발견 시 혹은 QA 후 고쳐야 할 것을 따로 hotfix 브랜치로 빼서 고친 후 develop에 합친다.
-
main: main, master 두 개를 혼합해서 부른다. (원하는 것 사용해도 무방함)
-
release: 말 그대로 릴리즈를 위한 브랜치이다. develop부터 분기하며 어느 정도 프로젝트가 완성되면 릴리즈 전용 브랜치를 제작한다.
작성 예시 #
Feature 브랜치 관리 예시 #
아래 사진은 develop 브랜치에서 이름만 바뀐 브랜치이다.
보면 여러 가지 브랜치들이 하나의 브랜치에서 갈라져서 다시 하나로 합쳐지는 모습이다. 이는 순서 부분 4번부터 7번을 여러 사람이 반복하면 위와 같은 Git Flow 모양이 나오게 된다. 여기서 git commit -m 다음 메시지에 한국어로 버그 수정, 프로필, 회원가입 등 이 브랜치의 가장 큰 목적을 말하고 바로 다음 날짜를 보여준다. 그 후 상세하게 어는 부분이 변했는지 혹은 제작되었는지 적어주고 #000으로 이슈번호를 적어주며 메시지를 마무리한다.
Main 브랜치 관리 예시 #
다음은 main 브랜치를 살펴보자.
메인 브랜치는 Feature 브랜치보다 더 깔끔하다. 그 이유는 완전하게 작동되는 프로젝트 버전만 올리기 때문이다. (=판매 가능한, 서비스 가능한, 제출 가능한) 되도록 메인 브랜치는 관리자만 merge 및 revert 권한을 갖도록하자.
정리 #
Git Flow는 많은 개발자가 애를 먹을 정도로 매우 어렵다. 하지만 개발자 대부분이 쓰는 이유는 협업에 이만큼 효율적인 도구가 없기 때문이다. 학교 프로젝트나 사이드 프로젝트는 혼자 할 수 있지만 그 외 모든 개발은 다른 사람들과 협동해야 한다. 그만큼 소통과 업무 공유가 중요하니 처음 깃 플로우를 접하는 팀들에게 이 글이 많은 도움이 되었으면 좋겠다.
