그동안 프로젝트들을 진행하다 보면 시간에 쫓겨 로그들을 제대로 남기지 않고 진행하는 경우가 많았다.
그렇게 어찌저찌 프로젝트를 진행하다 가끔 과거의 기록들이 필요한 경우들이 생기게 되고,
아래와 같은 커밋 로그를 확인할때마다 정말 답이 안나온다..
1. README
README는 말그대로 프로젝트를 위해 꼭 읽어보라는 문서이며,
프로젝트를 볼때 가장 먼저 읽어보게되는 글이다.
이러한 README작성을 좀 더 꼼꼼히 진행하자.
2. commit
내가생각하기에 커밋은 프로젝트 관리에서 가장 중요한 요소중 하나다.
커밋 관리가 제대로 되어야지 해당 프로젝트가 어떻게 진행이 되고있는지가 보인다.
이런 커밋에 몇가지 규칙을 정하여 커밋을 관리하고자 한다.
2.1 Commit Message 템플릿
# 제목, 본문, 바닥글간 공백 한줄씩 주세요.
# #으로 시작하는 줄은 커밋으로 올라가지 않습니다.
########제목##########
# [커밋 유형]:[subject](#id)
## 커밋 유형
### FEAT : 새로운 기능의 추가
### FIX: 버그 수정
### DOCS: 문서 수정
### STYLE: 스타일 관련 기능(코드 포맷팅, 세미콜론 누락, 코드 자체의 변경이 없는 경우)
### REFACTOR: 코드 리펙토링
### TEST: 테스트 코트, 리펙토링 테스트 코드 추가
### CHORE: 빌드 업무 수정, 패키지 매니저 수정(ex .gitignore 수정 같은 경우)
### CICD: DevOps관련 기능 수정
########본문##########
## 본문은 작성되면 좋지만 필수는 아닙니다!
## 본문은 진행된 내용을 잘 알아볼 수 있도록 작성해 주세요.
## ~~추가, ~~제거 등 추상적인 말은 지양
## 참고할만한 커밋이 있다면 해당 커밋의 해시태그 7자리를 같이 써주세요
## ex) b1dbf65 : Food 도메인의 멤버 이름 변경 food_name => foodName
########바닥글##########
## 바닥글은 참조할만한 이슈, PR, 커밋등을 추가하는 용도로 사용해 주세요
## ex) 만약 16번, 18번 이슈 관련된 커밋이라면
## ref: #16, #18
## 만약 이슈가 해결되었다면 다음과 같이 작성해 주세요
## ex) 20번 이슈가 해결되었을때
## close #20커밋의 제목은 크게 유형, 제목, 레퍼런스id로 이루어진다
유형의 경우 해당 커밋이 어떤 커밋인지 가장 잘 나타낼 수 있는 간단한 단어로 명시한다.
제목의 경우 너무 길지도 짧지도 않은 해당 커밋을 잘 표현해줄 수 있는 한문장으로 명시한다.
레퍼런스 id의 경우 해당 커밋이 어떠한 이슈 또는 PR등을 참조하는지를 명시한다.
본문의 경우 해당 커밋이 어떤 작업을 행했는지를 보여주는 곳이다.
너무 추상적인 말들은 지양하며 나중에 보더라도 어떠한 작업이 진행되었는지 알 수 있게 한다.
바닥글은 참조할 사항들이 있을때 작성한다.
어떠한 이슈들을 참조하거나, 해당 이슈를 닫을때 사용한다.
2.2 git commit 템플릿 적용
git config commit.template .github/GIT_COMMIT_TEMPLATE.md템플릿을 적용하는 방법들은 다양하며 위 명령은 프로젝트 디렉토리 내에 템플릿을 적용하는 명령이다.
만약 시스템 전체에 적용하고자 한다면 --global 옵션과, 템플릿의 절대 경로를 지정해주면 된다.
git config --global commit.template {Template Absolute Path}
2.3 commit message example
실제 커밋 메시지의 예시다.
# 제목, 본문, 바닥글간 공백 한줄씩 주세요.
# #으로 시작하는 줄은 커밋으로 올라가지 않습니다.
########제목##########
FEAT : #25 개발용 api 컨트롤러 제작
########본문##########
개발용 api는 실제 api의 URL에 -dev를 붙여 사용합니다.
ex) 음식 데이터 가져오기 api
URL : /food/get-food-list
개발용 URL : /food/get-food-list-dev
########바닥글##########
ref: #25
# 제목 작성 요령
# [커밋 유형] : [#id] [subject]
## 커밋 유형
### FEAT : 새로운 기능의 추가
### FIX: 버그 수정
### DOCS: 문서 수정
### STYLE: 스타일 관련 기능(코드 포맷팅, 세미콜론 누락, 코드 자체의 변경이 없는 경우)
### REFACTOR: 코드 리펙토링
### TEST: 테스트 코트, 리펙토링 테스트 코드 추가
### CHORE: 빌드 업무 수정, 패키지 매니저 수정(ex .gitignore 수정 같은 경우)
### CICD: DevOps관련 기능 수정
# 본문 작성 요령
## 본문은 진행된 내용을 잘 알아볼 수 있도록 작성해 주세요.
## ~~추가, ~~제거 등 추상적인 말은 지양
## 참고할만한 커밋이 있다면 해당 커밋의 해시태그 7자리를 같이 써주세요
## ex) b1dbf65 : Food 도메인의 멤버 이름 변경 food_name => foodName
# 바닥글 작성 요령
## 바닥글은 참조할만한 이슈, PR, 커밋등을 추가하는 용도로 사용해 주세요
## ex) 만약 16번, 18번 이슈 관련된 커밋이라면
## ref: #16, #18
## 만약 이슈가 해결되었다면 다음과 같이 작성해 주세요
## ex) 20번 이슈가 해결되었을때
## close #20
2.3.1 결과화면
FEAT : #25 개발용 api 컨트롤러 제작
개발용 api는 실제 api의 URL에 -dev를 붙여 사용합니다.
ex) 음식 데이터 가져오기 api
URL : /food/get-food-list
개발용 URL : /food/get-food-list-dev
ref: #25
3. issue
이슈를 관리하기 위한 이슈 템플릿이다.
이슈 템플릿은 master 브랜치에서 .github/ISSUE_TEMPLATE 디렉토리를 만들어 해당 디렉토리에 md 파일로 저장한다.
샘플 템플릿 (bug_report, custom, feature_request)는 프로젝트 setting에서 생성할 수 있다.
3.1 labels
깃헙 이슈에는 사용할 수 있는 라벨들이 있다.
이 라벨들은 issue -> labels에서 확인할 수 있다.
나는 우선 두개의 라벨만 사용하고자 한다. 아직은 다른 라벨의 필요성을 느끼지 못해 추가로 필요한 라벨이 있다면 향후 추가하는것으로..
3.2 feature.md
기능에 관한 이슈 템플릿이다.
---
name: Feature Template
about: Describe new feature to implements
title: '💡Feature '
labels: 'feature'
assignees: ''
---
# Describe
- 구현할 기능 설명
# Progress
- [ ] Todo
- [ ] Todo
- [ ] Todo우선은 간단하게 구현할 기능에 대한 설명과, 해당 구현의 진행상황을 표시하는 템플릿으로 작성했다.
추가로 기본 labels를 feature로 설정한다.
3.3 bug.md
버그에 관한 이슈템플릿이다.
---
name: Bug report
about: Create a report to help us improve
title: '🐞Bug Report'
labels: 'bug'
assignees: ''
---
# Describe
- 버그에 대한 설명
# Scenario
- 버그가 일어나는 시나리오 설명
# Solution
- 버그픽스에 대한 설명버그 리포트 템플릿 또한 간단하게 버그를 설명하는 Describe, 버그가 일어나게 된 경위를 명시하는 Scenario, 버그 픽스를 설명할 Solution으로 이루어진다.
3.3 issue example
4. Pull Request
PR은 내가 이러이러한 일을 했으니 내가 한 일을 받아들여주세요~~ 를 요청하는 문서다.
이러한 PR에도 일정한 템플릿을 적용하여 통일성을 주고자 한다.
PR 템플릿은 프로젝트 마스터 브랜치의 .github/PULL_REQUEST_TEMPLATE.md 파일로 저장하면 적용된다.
4.1 Pull Request 템플릿
# Describe
# Author
# Issue Reference
# Review list
- [ ] Todo
- [ ] Todo
4.2 Example
