본문 바로가기
Programming/git & github & convention

Github Convention(실습)

by Finn# 2024. 11. 9.
728x90

Intro

실제 작업 순서를 참고해서 작성해보겠습니다.


Github Convention

- Branch : Naming Rule

- Commit Title/Message Style

- Issue Title/Message Style

- Pull Request Title/Message Style


Local : Branch - Commit Title/Message Style

 

Branch Naming Rule

Branch Nameing Rule은 우리가 생성한 Branch는 쉽게 생각해보면 분기된 작업 공간이랑 동치인데 이 공간의 이름을 '제목없음', '제목없음(1)'이런 식으로 적어놓으면 우리가 해당 작업 공간에 어떤 것을 했는지 나 또는 다른 사람이 이해할 수 있을까요? 아마 없을 겁니다..

 

다른 사람이 그걸 보나요?
우리가 해당 branch를 github 공간에 push하면 해당 branch 이름이 그대로 github 공간 상에 생성됩니다 !

 

그렇기 때문에 Branch에 우리가 어떤 내용을 기록할지 팀원들과 정해야합니다. '작업자/작업타입/일자' 다양한 format을 정해서 식별 가능하게 설정해봅시다. 그리고 이는 규칙이기 때문에 다음 branch를 생성하고 관리할 때도 꼭 지켜야겠죠??

 

# 브랜치 생성
git branch <새로운 브랜치>

# 브랜치 전환
git checkout <기존 브랜치>

# 브랜치 생성 및 전환
git checkout -b <새로운 브랜치>

 

Commit에도 Title/Message Style을 정의해야하는 이유

`git  log --oneline`  수행 시 Head만 보고 해당 Commit이 어떤 작업인지 알고 싶음

'git log' 수행 시 Body와 관련 Issue를 통해서 더 자세하게 확인해볼 수 있음 이런 style을 정의하고 준수하게 되면 commit을 식별할 수 있는 능력을 기를 수 있고 반드시 항상 염두해두고 작업해두면 버리는 시간들을 지킬 수 있음

git commit -m "

    Head : Title(50자 이내, 명령문으로 시작, 작성 후 개행)
    
    Body : 한줄당 72자 이내 작성, 개행
    Footer : See Also/ Closed # issueNo
    
    "

1. 브랜치 명명 규칙 (기본 템플릿)

브랜치 명명 규칙은 직접적인 템플릿 파일은 없지만, 문서로 안내할 수 있습니다:

# .github/CONTRIBUTING.md 파일에 추가

## 브랜치 명명 규칙
- `feature/기능명`: 새로운 기능 개발
- `bugfix/버그명`: 버그 수정
- `hotfix/핫픽스명`: 긴급 수정
- `release/버전`: 릴리스 준비
- `chore/작업명`: 기타 작업

 

2. 커밋 메시지 템플릿

# .gitmessage 파일 생성
[type]: 제목 (50자 이내)

# 본문 (선택 사항)
# 무엇을, 왜 변경했는지 자세히 설명

# 꼬리말 (선택 사항)
# Resolves: #이슈번호

# type 목록:
# feat: 새로운 기능
# fix: 버그 수정
# docs: 문서 변경
# style: 코드 포맷팅, 세미콜론 누락 등
# refactor: 코드 리팩토링
# test: 테스트 코드
# chore: 빌드 프로세스 또는 보조 도구 변경

 

두 템플릿을 git 작업 시 반영하는 코드(이건 팀원 모두의 컴퓨터에서 실행시켜야할 코드)

git config --local commit.template .gitmessage

 


Issue  Title/Message Style

Github 상에서 현재 배포된 버전에 어떤 작업을 할지 정의합니다. 이는 Massage Type에서 정했던 내용 처럼 어떤 Type의 Task를 수행할 지에 대해서 Issue Title에 명시해주고 관련 내용을 정의한 Convention Style에 맞게 작성해줍니다.

 

Issue 템플릿 설정

버그 리포트 템플릿:

# .github/ISSUE_TEMPLATE/bug_report.md
---
name: 버그 리포트
about: 버그를 신고하기 위한 템플릿
title: "[Bug]: "
labels: bug
assignees: ''
---

## 버그 설명
어떤 버그인지 명확하게 설명해주세요.

## 재현 방법
다음 단계를 통해 버그를 재현할 수 있습니다:
1. '...' 화면으로 이동
2. '...' 버튼 클릭
3. '...' 스크롤 다운
4. 에러 발생

## 예상 동작
무엇이 일어날 것으로 예상했는지 설명해주세요.

## 스크린샷
가능하다면 스크린샷을 추가해주세요.

## 환경 정보
 - OS: [예: iOS, Windows]
 - 브라우저: [예: Chrome, Safari]
 - 버전: [예: 22]

 

기능 요청 템플릿:

# .github/ISSUE_TEMPLATE/feature_request.md
---
name: 기능 요청
about: 새로운 기능 제안을 위한 템플릿
title: "[Feature]: "
labels: enhancement
assignees: ''
---

## 기능 요청이 특정 문제와 관련이 있나요?
어떤 문제 때문에 이 기능이 필요한지 설명해주세요.

## 원하는 해결책 설명
무엇이 구현되었으면 하는지 명확하게 설명해주세요.

## 대안 방법
고려한 대안적인 해결책이 있다면 설명해주세요.

## 추가 정보
기능 요청에 관한 다른 정보나 스크린샷을 추가해주세요.

Pull Request Title/Message Style 

Pull Request를 하게 되면 Github 상에서 Merge를 수행하게 됩니다. 우리가 특정 issue를 commit footer에 tag해주고 push하면 해당 issue page에 push했던 branch가 걸리게 되는데 해당 페이지 하단에 보면 merge에 대한 PR을 할거냐고 물어봅니다. 이때 우리는 무분별하게 PR을 보낼 것이아니라 Branch Merge 방식을 고려해서 관리자에게 변경사항에 대한 검토를 요청하고 변경해야한다면 PR을 승인해서 최종 배포 branch에 반영될 수 있게 됩니다. 

 

Pull Request 템플릿

# .github/pull_request_template.md
## 변경 사항 설명
이 PR에서 무엇을 변경했는지 설명해주세요.

## 관련 이슈
관련된 이슈 번호를 적어주세요.
Fixes #(이슈 번호)

## 변경 유형
- [ ] 새로운 기능 (breaking change 없는 새 기능)
- [ ] 버그 수정 (breaking change 없는 버그 수정)
- [ ] 문서 업데이트
- [ ] 리팩토링 (기능 변경 없는 코드 개선)
- [ ] 스타일 변경 (기능이나 로직에 영향 없는 변경)
- [ ] 테스트 추가/수정

## 체크리스트
- [ ] 내 코드는 프로젝트 스타일 가이드라인을 따릅니다
- [ ] 내 변경사항에 대한 테스트를 추가했습니다
- [ ] 모든 테스트가 로컬에서 통과합니다
- [ ] 필요한 문서를 업데이트했습니다

 

모든 템플릿 적용하기

  1. 저장소 루트에 .gitmessage 파일 생성
  2. .github 디렉토리를 만들고 그 안에 ISSUE_TEMPLATE 디렉토리 생성
  3. .github/ISSUE_TEMPLATE 안에 bug_report.md와 feature_request.md 파일 생성
  4. .github 디렉토리에 pull_request_template.md 파일 생성
  5. .github 디렉토리에 CONTRIBUTING.md 파일 생성 (선택 사항)

이렇게 하면 GitHub 저장소에 이슈와 PR을 작성할 때 자동으로 템플릿이 적용됩니다.

커밋 메시지 템플릿은 팀원들이 각자의 Local 설정해야 합니다.


Reference

 

인스타 주소 🎗

https://www.instagram.com/f.inn_sharp/

반응형