Notice

Recent Posts

Recent Comments

Link

« 2024/04 »
일	월	화	수	목	금	토
	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30

Tags more

Archives

Today

Total

관리 메뉴

xtring.dev

[Git] 규칙적인 Commit 메세지로 개발팀 협업하기👾 본문

for Dev./Git | Github

[Git] 규칙적인 Commit 메세지로 개발팀 협업하기👾

xtring 2021. 6. 28. 10:37

규칙적인 Commit 메세지로 개발팀 협업하기 👾

TL;DR
개발자들은 Github를 통해 git에 대한 활동을 확인할 수 있습니다. 코드의 최신화 유지와 문제 원인 발견, 신규 기능 추가에 대한 branch 분리 전략 등을 통해 코드를 관리합니다.

$ <type>(<scope>): <subject> -- 헤더
<BLANK LINE> -- 빈 줄
<body> -- 본문
<BLANK LINE> -- 빈 줄
<footer> -- 바닥 글

Github commit 메세지 규칙을 만들자!

Git을 통해 코드를 유지하는 경우 커밋 메세지를 통해 해당 commit의 작업 내용을 입력하게 됩니다. 그렇다면 규칙이 없는 상태에서 여러 개발자가 동시에 커밋 메세지를 작성하면 어떻게 될까요?

modify: 시군구 전체 값 선택된 경우 지역 전체로 표시하기
update
merge: dev brench
Modify: 관심지역 편집 레이아웃 수정
code change

위에서 살펴본 커밋 메세지는 컨벤션이 없는 경우 입니다. 같은 동작에 대한 메세지 기록인데도 불구하고 누구는 대문자로 또는 엑션 단어를 적어주지 않거나 메세지 내용을 구체적으로 작성하지 않는 경우로 메세지의 형태는 가지 각색입니다. 이 처럼 일관성이 없는 메세지 내용은 각 커밋의 위치에서 어떤 작업을 했는지 명확하게 알아 볼 수 없거나 시각적 통일성을 떨어뜨려 커밋 히스토리를 파악하는데 어려움을 줄 수 있습니다.😂 그리고 추후에 원하는 작업 내용을 추적하거나 각 커밋에서 어떤 내용이 이루어져있는지 쉽고 명확하게 파악하기 어렵습니다. 그래서 우리는 팀에서 커밋 메세지를 일관성있는 규칙으로 작성하는 방법을 알아야 합니다.

일관성 있는 커밋 메세지 규칙을 만들면 아래와 같은 이점을 얻을 수 있습니다.

과거 코드에 대한 코드 추적
이슈 사항 처리 상황
팀원들과의 커뮤니테이션

좋은 커밋 메세지를 작성하기 위한 규칙들

한 눈에 커밋 메세지를 알아보기 위해서 중요한 것 중 하나는 네이밍(naming)을 명시적이고 규칙적으로 작성해주는 것입니다. 그리고 해당 커밋에 대한 내용을 잘 작성해준다면 코드를 일일히 분석하지 않아도 해당 커밋의 내용을 알아볼 수 있습니다. 그렇다면 좋은 commit 메세지를 작성하기 위한 규칙과 구조를 알아보겠습니다.

커밋 메세지의 7가지 규칙

제목과 본문을 빈 행으로 구분합니다.
제목을 50글자 이내로 제한합니다.
제목의 첫 글자는 대문자로 작성합니다.
제목의 끝에는 마침표를 넣지 않습니다.
제목은 명령문으로! 과거형을 사용하지 않습니다.
본문의 각 행은 72글자 내로 제한합니다.
어떻게 보다는 무엇과 왜를 설명합니다.

커밋 메세지 구조

$ <type>(<scope>): <subject>    -- 헤더
  <BLANK LINE>                  -- 빈 줄
  <body>                        -- 본문
  <BLANK LINE>                  -- 빈 줄
  <footer>                      -- 바닥 글

<type>은 해당 commit의 성격을 나타내며 아래 중 하나여야 합니다.

feat : 새로운 기능에 대한 커밋
fix : build 빌드 관련 파일 수정에 대한 커밋
build : 빌드 관련 파일 수정에 대한 커밋
chore : 그 외 자잘한 수정에 대한 커밋(rlxk qusrud)
ci : CI 관련 설정 수정에 대한 커밋
docs : 문서 수정에 대한 커밋
style : 코드 스타일 혹은 포맷 등에 관한 커밋
refactor : 코드 리팩토링에 대한 커밋
test : 테스트 코드 수정에 대한 커밋

<body>는 본문으로 헤더에서 생략한 상세한 내용을 작성합니다. 헤더로 충분한 표현이 가능하다면 생략이 가능합니다.

<footer>는 바닥글로 어떤 이슈에서 왔는지와 같은 참조 정보를 추가하는 용도로 사용합니다.

예를 들어 특정 이슈를 참조하기 위해서 close #321와 같이 사용하면 됩니다. 그리고 이는 main 브랜치로 푸쉬될 때 닫기(close) 됩니다. 해결(이슈 해결 시 사용)/관련(해당 commit에 관련된 이슈 번호)/참고(참고할 이슈가 있는 경우 사용)의 타입을 사용할 수 있습니다.

커밋 메세지 예시

Feat: 관심지역 알림 ON/OFF 기능 추가(#123)

시군구의 알림을 각각 ON/OFF 할 수 있도록 기능을 추가함
 - opnion0055: 구분 코드

해결: close #123

결론

커밋 메세지를 잘 작성하는 것은 협업에서 기본적인 습관입니다. 내가 다른 사람의 작업 내용을 한눈에 파악할 수 없다는 것을 알고 있다면 다른 사람 역시 내가 작성한 커밋에 대한 내용을 파악하기 어렵다는 것을 인지해야합니다. 팀에서 함께 위와 같은 컨벤션으로 일할 수 있다면 히스토리를 파악하고 코드 리뷰도 짧은 시간 내에 해결할 수 있을 것 같습니다!

📗 Ref.

https://junhyunny.github.io/information/github/git-commit-message-rule/

Github commit 메세지 규칙

junhyunny.github.io

https://beomseok95.tistory.com/328

[Git] 좋은 커밋 메세지 작성하기위한 규칙들

좋은 커밋 메시지 작성하기 위한 규칙들 코드를 작성하면서 어려운것들중 하나는 이름을 어떻게 짓는지에 대한 고민 바로`Naming` 일 것입니다. 클래스, 함수, 변수 등등 많은 이름을 고민하지

beomseok95.tistory.com

💥 연관 포스트 바로가기

2021.07.11 - [for Dev./Git] - [Git] 이미 commit한 메세지 수정하기📍 - 바로 이전/그 전/리모트 commit

[Git] 이미 commit한 메세지 수정하기📍 - 바로 이전/그 전/리모트 commit

이미 commit한 메세지 수정하기 Git 사용 중 commit를 할 때는 꼭 메시지를 입력하게 됩니다. 때때로 오타를 입력하거나 commit한 후에 메시지를 수정하고 싶은 경우가 있을 때가 있습니다. 세가지

xtring-dev.tistory.com

2021.07.10 - [for Dev./Git] - [Git] Git branch 톺아보기 - 🎋 branch를 확인/생성/삭제

[Git] Git branch 톺아보기 - 🎋 branch를 확인/생성/삭제

Git branch 톺아보기 - 🎋 branch를 확인/생성/삭제 keyword : git branch, git checkout branch란? Git을 통해 코드 형상관리하는 팀은 동시에 하나의 저장소(repository)를 바라보고 작업하게 됩니다. 하나의..

xtring-dev.tistory.com

저작자표시 변경금지

'for Dev. > Git | Github' 카테고리의 다른 글

[Git] 이미 commit한 메세지 수정하기📍 - 바로 이전/그 전/리모트 commit (6)	2021.07.11
[Git] Git branch 톺아보기 - 🎋 branch를 확인/생성/삭제 (0)	2021.07.10
[Git/Github] 중구난방 여러 개의 repo를 하나의 repo로 모아보자! (0)	2021.01.15
[Git] add와 commit을 동시에! (0)	2021.01.10
[Git] 프로젝트에 자동으로 생성된 .gitignore가 뭘까? - .gitignore (0)	2020.07.16