본문 바로가기
[TIL]내 머릿속의 코드

[TIL:2400301] Git commit 작성하는 법?!

by 졸린부엉이 2024. 3. 2.

나는 대체 적은 인원의 회사에서 일을 했었다.

6명? 10명? 이내의 스타트업? (최근 다녔던 '핀테크'회사는 30명 정도)

그래서 퍼블리셔는 대부분 1명 이여서 혼자서 작업 다~ 하였다.

 

그렇게 어찌저이 해서 commit을 하고 push를 하며 작업을해 나아갔다.

나는 그게 맞는 방법인줄 알고 작업을 했다

아무도 신경쓰지 않았고, 다들 그런씩의 commit을 하고 있어서 문제가 없다 생각했다.

 

하지만 공부를 하다보니...

잘못된게 한,두가지가 아니였다!

 

이 얼마나 다행인가 ㅠㅠㅠ 

이렇게 공부하여 틀린걸 고칠수 있는건 큰 기회이다!!

 

 

나의 문제점은...

// 예시)  commit messa 작성때
git commit -m "소개페이지 구축 작업"
git commit -m "메인페이지 디자인 수정"

// 예시) 간단한 수정 메세지
git commit -m "문구 수정"
git commit -m "컬러 수정"

 

혼자서 작업을 하다보니, 간단하게 쓰게 된것이다 ㅠㅠ 퍼블리셔 항상 혼자였기에, 개발자 분들을 딱히 신경을 쓰지 않고 맨 마지막의 완료된 브런치에서 가져가 작업하면 되니까 인가?? 그건 잘모르겠다,

 

 

 

이제 문제가 아니다. 생각이 달라졌다 

 

commit을 쪼개기를 해야한다는것은!!

내가 하는 작업을 정확히 알고, 작업의 순서를 생각하며, 작은 단계로 나누는 거다.

그렇게  commit의 제목만 보아도 무슨 작업 인지 유추가 가능하게 하는게 좋은 commit인거 같다 (예시1)

 

작업하는 순서와 작업 쪼개기를 어떻게 해야하는지 고민이 많을 거 같다.

그래서  간단하게 라도 작업계획서를 작성해서 잘게 쪼개고, 비슷한 작업을 묶어 commit을 연습할 생각이다

내 생각이 다 맞을 수도 없고, 틀릴수도 있지만.물어 보며 작업할꺼라, 조금씩이지만 나아질꺼라 생각한다

 

예시1)
나는 로그인 페이지를 만들어야한다.
'로그인 페이지에는, 로그인 기능, 비밀번호 찾는 기능, 아이디 찾는 기능, 팝업을 만들어야 한다'
라고 가정은 하자.

그러면 나의 순서는,
1. 로그인
2. 팝업
3. 아이디찾기
4. 비밀번호 찾기 

순서의 작업 처럼 나는 4번의 commit을 하며 , 메세지도 같은 가능의 제목으로 설명을 덧붙여서 작성할것이다.

 

 

 

아래 커밋을 할때는 규칙을 정리했다. 설명아래 예시도 있으니 확인 해보자.

유형(type): 제목 // header

본문            // body 필수 아님, header에서 설명이 가능하면 안적어도 됨

꼬리말          // footer

 

규칙

설명 )
[제목 : 1번째 줄]

- header 유형은 필수
- 제목은 첫글자 대문자이며 50자 이하로 요약 ( 첫째줄이 제목으로 처리, 나머지는 본문으로 처리 )
- 제목은 명령문으로 과거는 X
- 제목 끝은 마침표 X
- 두번째 줄을 비워둔다 (1번째 줄을 제목, 2번째 비우고, 3번째 본문내용)

[본문 : 3번째 줄 ~ ]
- 본문을 각행의 문자수는   72자  이내로 작성한다, 다음줄로 이행
- 단락 사이는 빈행으로 구분한다 (예시1)
- 글머리 기호공백 하나 넣고, 하이픈, 별표로 (예시2) (사용하는 방법은 다~ 다른수 있음)
- 관련 이슈가 있다면 링크를 걸어준다. (예시2)에 추가 정보

  예시1)
  
  commit 31336b35b4604f70150d0073d77dbf63b9bf7598
  Author: [removed]
  Date:   Wed Jun 6 22:45:25 2012 -0400

    Add CPU arch filter scheduler support // 유형:Add  || 제목:CPU arch..
								// 2번째 공백
    In a mixed environment of running different CPU architectures, // 72자 이내
    one would not want to run an ARM instance on a X86_64 host and // 72자 이내
    vice versa.
 								// 단락 구분 공백
    This scheduler filter option will prevent instances running
    on a host that it is not intended for.
예시2)

[이슈 수정]
Update new feature for user authentication // 유형:Update  || 제목:new feature for...

 - Implemented login and registration functionality // 머리글 하이픈
 - Updated user model to include additional fields
 - Fixed bug related to password encryption

Related to: #123 // 해당 커밋이 이슈 #123과 관련있다는 표시



[이슈해결시]
Refactor new feature for user authentication // 유형:Refactor  || 제목:new feature for...

- Implemented login and registration functionality
- Updated user model to include additional fields
- Fixed bug related to password encryption

Closes: #123 

/*
+ 추가정보
"Closes: #123" 또는 "Fixes: #123"와 같은 명령어를 커밋 메시지에 포함시키면, 
이 커밋이 이슈 #123을 해결하고 해당 이슈를 닫도록 지시할 수 있습니다. 
이 명령어를 포함시키면, 커밋이 머지될 때 해당 이슈가 자동으로 닫히게 됩니다.
*/

 

 

 

유형:Type

feat 새로운 기능에 대한 커밋
fix 버그 수정에 대한 커밋
build 빌드 관련 파일 수정 / 모듈 설치 또는 삭제에 대한 커밋
chore 그 외 자잘한 수정에 대한 커밋
ci ci 관련 설정 수정에 대한 커밋
docs 문서 수정에 대한 커밋
style 코드 스타일 혹은 포맷 등에 관한 커밋
refactor 코드 리팩토링에 대한 커밋
test 테스트 코드 수정에 대한 커밋
perf 성능 개선에 대한 커밋

 

 

 

 

 

 Last.  

commit의 작성방법을 보며, header만으로도 충분이 알아볼수 있게 쓰는게 제일 좋은 commit이다.
너무 길어도 안좋고, 짧아도 안좋고, 부가설명을 너무 안해도 안좋고. 적절히 규칙에 맞춰서 작성한다면 간결하고 정리된 commit을 작성 할 수 있을꺼같다.

commit을 찾아보며 제일 좋은 부분은 유형(type)이였다
type을 먼저 작성하여 제목을 다 읽지 않아도, 수정 건 인지, 추가 기능인지 눈이 확 띄어 어떤 commit인지 우선 인식하고 보는게 좋은거 같다

 

 

 

 


 

[참고]

https://velog.io/@chojs28/Git-%EC%BB%A4%EB%B0%8B-%EB%A9%94%EC%8B%9C%EC%A7%80-%EA%B7%9C%EC%B9%99

https://gist.github.com/luismts/495d982e8c5b1a0ced4a57cf3d93cf60