커밋 메시지 작성 가이드라인

<aside> 💻 (1) 커밋 메시지의 제목과 상세 설명 사이에는 한 줄을 비워두세요.

(2) 커밋 메시지의 제목 뒤에 온점(.)을 붙이지 마세요.

(3) 커밋 메시지의 제목의 첫 번째 알파벳은 대문자로 작성하세요.

(4) 커밋 메시지의 제목은 명령조로 작성하세요.(Fix it / Fixed it / Fixes it)

(5) 커밋의 상세 내용에는 이런 걸 적으면 좋습니다.

• 왜 커밋을 했는지
• 어떤 문제가 있었고
• 적용한 해결책이 어떤 효과를 가지는지

(6) 다른 사람들이 자신의 코드를 바로 이해할 수 있다고 가정하지 말고 최대한 친절하게 작성하세요.

</aside>

커밋할 때 알아야 할 가이드라인

<aside> 💻 (1) 하나의 커밋에는 하나의 수정사항, 하나의 이슈(issue)를 해결한 내용만 남기도록 하세요. 다양하게 수정을 하고나서 하나의 커밋으로 남기는 것은 좋지 않습니다. 하나의 커밋이 하나의 사실만을 갖고 있어야 나중에 이해하기 쉽습니다.

(2) 현재 프로젝트 디렉토리의 상태가 그 내부의 전체 코드를 실행했을 때 에러가 발생하지 않는 상태인 경우에만 커밋을 하도록 하세요. 나중에 동료 개발자가 특정 커밋의 코드로 실행했을 때 에러가 발생한다면 혼란을 줄 수 있습니다.

커밋으로 보관된 특정 시점의 전체 코드는 항상 문제없이 실행되는 상태여야 합니다. 이미 과거의 커밋이 되어버렸다고 우리에게 쓸모없는 커밋이 되는 건 절대 아닙니다. 과거의 커밋이라도

• 과거 버전의 프로그램을 사용해야하거나
• 과거 커밋을 시작점으로 한 다른 방향의 별도 프로젝트를 시작하거나
• 아예 그 커밋으로 현재 프로젝트를 리셋할 수도 있습니다.

커밋은 같이 개발하는 팀원들과 하나의 규칙을 정해서

• 나중에 다시 봤을 때 이해하는데 어려움이 없도록
• 다른 동료 개발자와 협업하는 데 방해가 되지 않도록

하는 것이 가장 좋습니다 !!

</aside>

포크해온 레포지토리에 커밋해서 잔디 남기기 !

[Git] 커밋을 해도 잔디가 안 심어질 때, fork한 repository의 커밋으로도 잔디를 심어보자, 저장소의 커밋 기록까지 전부 복사해오기 !

좋은 커밋 메시지 남기기

<aside> 🙌🏻 커밋의 종류를 명시하라.

• feat: 어떤 특정 어플리케이션에 더할 새로운 feature
• fix: 어떤 오류 해결(fix)
• style: 스타일과 연관된 feature나 업데이트들
• refactor: 코드 베이스의 특정 부분을 재정렬(refactoring)
• test: 테스트와 관련된 모든 것
• docs: 문서화에 관한 모든 것
• chore: 정규 코드 유지보수.
• build : 빌드 시스템 또는 외부 종속성에 영향을 미치는 변경 사항(예: gulp, broccoli, npm)
• perf : 성능을 향상시키는 코드 변경
• ci : CI 구성 파일 및 스크립트 변경 사항(예: CircleCi, SauceLabs) </aside>

<aside> 🙌🏻 커밋 메시지 팁

1. 제목을 본문으로부터 빈 칸 한 줄 띄워 구분하라
2. 커밋 메세지는 어떠한 공백오류(whitespace errors)를 포함하지 않아야 한다
3. 불필요한 구두점을 삭제하라
4. 제목 행을 마침표(.)로 끝맺지 마라
5. (영어일 경우) 제목 행과 매 문단의 시작을 대문자로 하라
6. 제목 행에는 명령어를 사용하라
7. 본문 영역은 적용한 변경 사항과 그것을 만든 이유에 대해 설명하기 위해 활용하라
8. 검토자들이 본래 문제가 무엇이었는지 이해하고 있을 것이라 가정하지 말고 그것을 더해 적어라
9. 본인의 코드가 설명 없이도 괜찮다고 생각하지 마라
10. 소속되어 있는 팀의 정해진 커밋 규칙을 따르라 </aside>

또한 커밋 종류를 표현하기 위해 이모티콘을 사용할 수도 있습니다.

Git