[협업 프로젝트] Git Flow, 커밋 컨벤션, Issues 프로젝트 적용하기

서론

Spring Boot를 이용한  RESTful Web Service를 개발 및 학습하는 과정 중

BE와 FE 협업 프로젝트를 함께 진행하는 것이

• 실제 개발 환경에서의 경험 (BE, FE 실제 현업과 유사한 개발환경)
• 커뮤니케이션 강화
• 효율적인 개발
• FE, BE 지식 공유
• 종합적인 시스템 이해

측면에서 장점을 가지고 있을 것이라고 생각하고

커뮤니티에서 BE, FE 협업 프로젝트를 확인하고 진행하게 되었다.

 

프로젝트의 형상관리 툴은 git으로 결정하였고, git으로 결정한 이유는 다음과 같다.

• 팀원 전체의 사용 경험 
• 분산 집중형 버전관리 및 개발 (Git - flow 전략)
• 커밋 컨벤션을 활용한 코드 메시지 구조 구체화
• Issue와 프로젝트를 통한 MVP 스프린트 통합 관리

 

여기서 우리는 형상관리를 더 효과적으로 다루기 위해 세 가지 role  

• 버전관리 및 개발(git flow 전략 및 규칙 설정)
• 코드 메시지 규칙 설정
• Issue와 프로젝트를 통한 MVP 스프린트 통합 관리

를 정하였고 이를 정리하며 복습하려고 한다.

 

Git-Flow 전략

Git-flow에는 5가지 종류의 브랜치가 존재하며,

항상 유지되는 메인 브랜치들(master, develop)과 일정 기간 동안만 유지되는 보조 브랜치들

(feature, release, hotfix)이 있다. 각 브랜치의 기능은 다음과 같다.

• master : 제품으로 출시될 수 있는 브랜치
• develop : 다음 출시 버전을 개발하는 브랜치
• feature : 기능을 개발하는 브랜치
• release : 이번 출시 버전을 준비하는 브랜치
• hotfix : 출시 버전에서 발생한 버그를 수정하는 브랜치

여기서 우리는 

• main - 최종본. main에 병합 후 배포하기
• dev - 버전 각 기능들 병합하는 버전관리 브랜치
• feature - 각 기능을 개발하는 브랜치
  • feature/대전제-#이슈넘버 
  • feature/mvp이슈-#이슈넘버

를 사용하여 작업을 할 때 지켜야 할 브랜치를 선정하였다.

 

이후 MVP 전략을 수용하여 주차 별 스프린트를 팀원들끼리 정리해서

각 기능을 개발하는 브랜치 생성 및 이슈화하여 feature 브랜치 네이밍 규칙을 결정하였다.

 

Git 커밋 컨벤션

기본적인 커밋 메시지 구조는 제목, 본문, 꼬리말 세 가지 파트로 나누고, 각 파트는 빈 줄을 두어 구분한다.

여기서 커밋에 대한 제목을  태그: 제목 형식으로 커밋 내용을 유의미하게 전달하기로 하였고,

본문(body)에 제목에 대한 내용을 상세히 작성하도록 정하였다.

그 예시는 다음과 같고

"feat: "회원 가입 기능 구현"

SMS, 이메일 중복확인 API 개발

제목과 바디의 규칙을 아래와 같이 정하였다. 

Commit Type
타입은 태그와 제목으로 구성되고, 태그는 영어로 쓰되 첫 문자는 대문자로 한다.

태그 : 제목의 형태이며, :뒤에만 space가 있음에 유의한다.

• feat : 새로운 기능 추가
• fix : 버그 수정
• docs : 문서 수정
• style : 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우
• refactor : 코드 리펙토링
• test : 테스트 코드, 리펙토링 테스트 코드 추가
• chore : 빌드 업무 수정, 패키지 매니저 수정

Body

본문은 다음의 규칙을 지킨다.

• 본문은 한 줄 당 72자 내로 작성
• 본문 내용은 양에 구애받지 않고 최대한 상세히 작성

 

Issues

팀 프로젝트 전 MVP 전략을 git에서 더 효과적으로 사용하기 위해 Issues와 project 탭을 이용하기로 하였다.

먼저 프로젝트의 기획, 작업, 개선 사항, 버그 수정, 새로 추가될 기능 등 모든 것을 이슈라고 칭하고 

스프린트 주차에 맞게 해야 할 기능들을 git 이슈화를 만들기로 하였다.

 

이를 깃허브 프로젝트 탭을 활용하여 프로젝트 진행사항을 한눈에 볼 수 있으며

이슈들을 하나의 작업(task)으로 나타내서 그 작업이 진행되었는지

팀원들과 보드 형태로 활용할 수 있다는 점이 큰 장점으로 적용되어 이를 팀 규칙으로 정하게 되었다.

이슈 제목

• MVP 기능 정리 제목을 따라간다.
  
  • [FEAT] 카카오 소셜 로그인을 구현한다. #1
  • [FEAT] 기능제목 또는 mvp 예시 #이슈넘버

타이틀 구조 예시▼

• Feat : 새로운 기능에 대한 커밋
• Fix : 버그 수정에 대한 커밋
• Chore : 그 외 자잘한 수정에 대한 커밋(기타 변경)
• Design: UI UX 디자인 구현에 대한 커밋
• Style : 코드 스타일 혹은 포맷 등에 관한 커밋
• Test : 테스트 코드 수정에 대한 커밋
• Refactor : 코드 리팩토링에 대한 커밋
• Docs : 문서 수정에 대한 커밋
• Ci : CI 관련 설정 수정에 대한 커밋
• Build : 빌드 관련 파일 수정에 대한 커밋

이슈 본문

## 📄 작업 대상
 - 관리자 A 구현한다.

## ✅ 작업 내용
 - [X] To do
 - [ ] To do
 - [ ] To do

## 📎 ETC ( 기타 참고사항)

labels

이슈 생성 예시

브랜치 네이밍

1. feature/oauth-kakao-api#1
   1. feature/(기능제목)-#이슈번호

• main : 프로젝트가 최종적으로 배포되는 중심 브랜치입니다.
• dev : 개발이 진행되는 브랜치입니다. dev 브랜치가 배포할 수준의 기능을 갖추면 main 브랜치로 머지됩니다.
• feature : 기능을 개발하는 브랜치입니다. develop 브랜치에서 파생되는 브랜치이며, dev 브랜치로 머지합니다.

pull request

1. 자신의 브랜치를 머지할 타깃 브랜치를 develop으로 바꿉니다.

2. PR 제목과 내용 Issue 번호 작성 후 ([FEAT] 초기 엔티티 설정과 더미네이터 세팅 #해당이슈넘버)

3. 작업내용 요약 및 이슈번호 close: #해당이슈넘버

4. reviewrs 설정 후 팀원 승인 이후 머지

Project

 

이렇게 git flow -> 컨벤션 ->issues , proeject로 관리하게 되면

 

팀원들과 작업 추적 및 관리, 할당, 우선순위 및 프로젝트 관리의 향상을 경험할 수 있고,

토론 및 의사소통 또한 원활하게 진행할 수 있다.