협업 전략

Gitlab Issue 및 kanban

Gitlab에서 Issue를 통해 작업 현황 및 내역 공유

issue - Boards에서 kanban과 같은 형식으로 Issue 생성 및 관리 가능

Issue발행

Issue를 통해 프로젝트 관련 문의와 진행 사항 공유 가능

Issue에서는

• Milestone
  • 진행 예정 목표 기입
  • 하나의 마일스톤은 여러 이슈를 가질 수 있다.
• Labels
  • 해당 Issue의 목적
  • 필요에 따라 Labels 생성 가능

등의 여러 특성을 활용해 사용 가능

Issue Template

이슈의 내용은 필요에 따라 사용 가능하며 해당 프로젝트의 메인 브런치에서

.gatlab/issue_templates

를 통해 미리 convention을 정의한 Template 작성이 가능하다.

issue_template

• issue_template.md

<!--
이슈 제목은 제목만 보고도 어떤 작업을 했는지 파악 할 수 있도록 명확하게 작성해주세요
-->

## 📍 작업 사항
<!-- 진행할 작업 목록을 작성해주세요 -->
<!-- 작업 내용을 이미지나 gif로 첨부해도 좋습니다 -->


## 👪 작업에 참여한 인원
<!-- 같이 작업에 참여한 인원이 있다면 멘션으로 태그해주세요 -->


## 🔗 참고자료
<!-- 디자인 시안 링크 또는 레퍼런스 등 참고할만한 자료 -->

• Inquiry_template.md

<!--
이슈 제목은 제목만 보고도 어떤 작업을 했는지 파악 할 수 있도록 명확하게 작성해주세요
-->

## 📍 질문 사항
<!-- 질문/문의 사항에 대해 작성합니다 -->



## 👪 With
<!-- 같이 논의하고싶은 대상을 태그해주세요 -->



## 🔗 참고자료
<!-- 디자인 시안 링크 또는 레퍼런스 등 참고할만한 자료 -->

다음과 같은 식으로 미리 코드를 정의해 둔 후

해당 Issue Template의 활용이 가능하다.

Git branch & Merge Request

branch

Git에서 branch를 분기할 때에는 해당 branch를 통해 적용할 내용에 맞추어서

feature/내용

과 같은 식으로 분기한다.

해당 내용으로 분기한 Branch를

feacher -> dev로 개발이 완료된 후에 Merge하면 된다.

merge request

merge request는 해당 작업이 완료된 후 진행한다.
작업 이후 conflict가 없다면 작업한 내역을 Dev branch로 적용하게 된다.

이 때에 다른 팀원들에게 Code Review 후 몇명 이상의 Approve가 있어야 merge가 활성화하게 조작하는 등의 설정이 가능하다.

merge request template

.github/merge_request_templates 위치에 request template를 위치시킬 수 있다.

• default.md

## 📍 주요 변경사항

<!-- 구현 내용 및 작업 했던 내역 -->
<!-- 작업 내용을 이미지나 gif로 첨부해도 좋습니다 -->

## 💡 중점적으로 봐주었으면 하는 부분

<!-- MR을 볼 때 주의깊게 봐야하거나 말하고 싶은 점 -->

## 🔗 참고자료

<!-- 디자인 시안 링크 또는 레퍼런스 등 참고할만한 자료 -->
<!-- 이슈 트래킹을 위해 이슈 링크를 걸 수 있습니다 -->

이슈 트래킹을 위해 위에서 생성한(혹은 따로 존재하는) 이슈 링크를 걸어줄 수 있다.

Commit Convention

개발을 할 때에 각각의 Branch에서 작성한 내용을 git에 push할 때에, commit convention을 통해 협업을 원할하게 해 줄수 있다.

Commit 메세지 구조

• Title(제목)
  • type
  • subject
• Body(본문)
• Footer(꼬밋말) -> optional

처럼 넣어줄 수 있다.

type

Type    description
----------------------------
Feat    새로운 기능 추가
Fix    버그 수정
Docs    문서 수정
Refactor    코드 리펙터링
Test    테스트 코드, 리펙토링 테스트 코드 추가
Chore    빌드 업무 수정, 패키지 매니저 설정
Rename    파일 혹은 폴더명 수정, 이동
Remove    파일 삭제
!HOTFIX    급하게 치명적인 버그 수정 진행
Design    디자인 변경
Style    코드 포맷 변경, 세미콜론 누락, 코드 수정이 없는 경우
Comment    필요한 주석 추가 및 변경

이런 식으로 어떠한 작업을 했는지를 표현해주는 Type이고, 이는 Gitmoji 등으로 대체 가능하다.

Subject

제목은 코드 변경 사항의 요약내용을 담는다.
제목을 작성할 때에는 아래의 규약을 적용한다.

1. 50자 이내로 작성한다.
2. 마침표, 특수기호 등을 사용하지 않는다.
3. 대문자로 시작하며 과거 시제가 아닌 동사원형을 사용한다.
4. 개조식 구문 사용하기(서술형X)

Body

본문은 실제 커밋한 내용에 대한 자세한 설명을 작성한다.
본문을 작성할 때에는 아래의 규약을 적용한다.

• 줄당 72자 내로 작성한다.
• 본문은 최대한 상세히 작성한다. 양이 많으면 많은대로 다 작성하면 된다.
• 무엇을, 왜 변경했는지를 설명한다.
  • 어떻게 변경했는지를 적을 필요는 없다.

footer

꼬리말은 반드시 작성할 필요는 없다.
이슈 트래커 ID를 작성한다.

작성 요령은 다음과 같다.

• 유형: #이슈번호 의 형식으로 작성한다.
• 여러 개의 이슈번호를 적을 때는 , 로 구분한다.
• 이슈 트래커의 유형은 다음 중 하나를 사용한다.
  • Fixes
    • 이슈 수정중(아직 해결되지 않음)
  • Resolves
    • 이슈 해결
  • Ref
    • 참고할 이슈가 있을 때 사용
  • Related to
    • 해당 커밋에 관련된 이슈변호(Fixes에 관련하여)

즉 꼬리말은 어떤 이슈인지, 어디와 관련된 것인지 파악하기 위해 작성하도록 한다.