반응형
개요
git은 협업 툴이다 보니 협업을 잘하기 위해선 자연스럽게 의사소통이 원활하게 돌아가야 한다
다음과 같은 배경이라고 생각했을 때 어떤 경우가 좋을까
[배경]
나는 이제 막 회사에 입사한 신입이다.
원래는 사수가 되어줘야 할 전임자는 회사를 런친 상황이다.
이제 나에게 남은 건 깃 로그뿐인데..
상황 1.
깃 로그가 다음과 같다
- 지난주에 한 이미지 업로드 기능 에러 수정
- 자잘한 에러 수정
- 신규 기능 중간 저장
상황 2.
- fix : Admin단에 로고 업로드 기능, 파일 저장 경로 이슈 수정
- fix : 메인 페이지 접속 시 발생하는 콘솔 에러 수정
- feat : Admin단에 로고 업로드 기능에 대한 이미지 저장 기능 추가
사람마다 극한의 단순함을 추구하지 않는다면 대체로 상황 2가 나을 거라 본다.
정리
이제 분량 뻥튀기는 그만하고 핵심을 말하자면 아래와 같다
아래 내용은 다른 블로그에서 복사해 온 건데
그 블로그도 보니깐 다른 사이트에서 내용을 복사한 건지 토씨하나 안 틀리고 똑같더라
- 제목과 본문을 빈 행으로 구분한다.
- 제목은 50글자 이내로 제한한다.
- 제목의 첫 글자는 대문자로 작성한다.
- 제목 끝에는 마침표를 넣지 않는다.
- 제목은 명령문으로 사용하며 과거형을 사용하지 않는다.
- 본문의 각 행은 72글자 내로 제한한다.
- 어떻게 보다는 무엇과 왜를 설명한다.
읽어보면 가독성과 이렇게 바꾼 의도를 설명하는 것에 포커스를 두고 작성하면 될 것 같다
chatgpt도 그걸 학습해서인지 비슷하게 대답해 준다
Message 구조
git에서 제공하는 규칙은 없어도 개발자들끼리의 플랫폼에서 자기네 끼리 정해놓은 게 있더라
https://github.com/angular/angular/blob/main/CONTRIBUTING.md#type
새로운 Angular 9 규약에서는 chore가 삭제되고, build, ci, perf가 추가되었는데 그냥 넣었습니다
이걸 기준으로 메시지 구조는 다음과 같다
<type>(<scope>):<subject> -- 헤더
<BLANK LINE>
<body> -- 본문
<BLANK LINE>
<footer> -- 바닥글
구조 뜻
type |
|
scope (option) | 변경되는 구역으로 함수명(괄호까지 적어서 구분), 파일명(확장자 적어서 구분) 등 변경될 수 있는 모든 영역 |
subject | 명령문, 현재 시제로 마침표를 붙이지 않 |
body | 명령문, 현재 시제로 어떻게 바꾼지 보다는 바꾼 의도를 적기 |
footer | git issue를 사용하여 작업 할 경우 해결된 issue에 대해서 다음 처럼 표현 close: #이슈번호 표현 |
이걸 통해서 예시를 만들면 아래와 같다
git commit -m "fix : 메인 페이지 접속 시 발생하는 콘솔 에러 수정
기존에 메인 페이지에서 중앙 이미지 슬라이드를 불러오는 코드에서
이전에 넣어둔 더미 코드로 인해 발생하는 콘솔 에러 제거
close: #1254"
반응형
'Git > GitHub' 카테고리의 다른 글
[GitHub] 깃허브 이메일 공개/허용하기 (0) | 2023.12.07 |
---|---|
Git pull 또는 clone시 Username for, Password for 묻는 경우 (0) | 2022.12.27 |
[Ubuntu] Git ssh 등록 에러 Permission denied (publickey) (0) | 2022.10.29 |