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

Project/협업프로젝트

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

COBI-98 2023. 10. 2. 01:46

서론

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

이슈 생성 예시

브랜치 네이밍

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로 관리하게 되면

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

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