Github 협업하기: 커밋(Commit), 풀 리퀘스트(Pull-Reqeust), 이슈(Issue) 정책 세우기

차분함은 공포를 느끼지 않고 생각을 멈추게 하며 작게만 느껴진다.

- 영국 왕립 해병대 - 

Calmness stops thinking without feeling fear and only feels small.
- royal marines commando - 

 

 

다양한 컨벤션 규칙

2주 전에 성공적으로 프로젝트를 마치면서 커밋(Commit), 풀 리퀘스트(Pull-Request), 이슈(Issue) 정책을 수립했는지 정리하는 글이다. 앞으로도 여러 이해관계자들과 함께 프로젝트를 진행할 때 크게 도움이 되는 정책이라고 생각되었고, 혼자 진행하려고 생각 중인 개인 프로젝트에서도 채택하려고 한다. 

 

아래 그림을 살펴보면 XXX 컨벤션이라고 정리했는데, 규칙을 의미하는 것이다. 

가장 최근에 진행한 패캠 x 아파트너 기업 협약 프로젝트 컨벤션

 

 

1. 커밋 컨벤션

1. 커밋 제목의 가장 앞 부분에 Gitemoji를 추가한다.
   • 가독성이 좋은 3~4 글자의 대문자 제목 활용합니다.
2. ":" 쌍점(colon, 콜론)의 위치는 5번째 위치한다.
3. 커밋 메시지 "요약(Summary)"은 자유롭게 작성하고, 72 자를 넘어가지 않도록 작성한다.
4. 커밋 메시지 “설명(Description)”은 스테이징 된 파일들(Staged Files) 마다 설명과 특징을 자세히 작성한다.

 

[이모지][분류 제목]: 내용

🎉INIT: (Begin a project) 프로젝트 시작
📝DOC : (Documentation) 문서화 관련된 작업
✨ENH : (Enhancement) 개선하거나 신기능 추가
💄UXUI: (Add or update the UI and Style files) UI나 style 파일 추가 및 수정
🙈IGN : (Add or update a .gitignore file) .gitignore 파일 추가 및 수정
♻️REF : (Refactor) 코드 리팩토링한 작업
🧪FAIL: (Add a failling test) 실패하는 테스트 추가
✅TEST: (Add, update or pass tests) 새로운 유닛 테스트를 추가하거나 기존 테스트를 수정
🔍SEO : (Improve SEO) SEO 개선 코드
🐛BUG : (Bug) 버그 수정
🔥DEL : (Remove Code or Files) 파일 및 코드 삭제
🚚MOVE: (Move or Rename Resorces) 파일 및 리소스 위치 이동
🚑FIX : (Error Fix) 에러 수정 및 해결
⚙️SET : (Setting) 필수 기본 파일 추가 및 수정(Ex.index.js,page.js...)
👷CICD: (CI/CD)CI/CD 빌드 시스템을 추가하거나 업데이트
⚡️PERF: (Performance) 계산 속도의 개선과 관련된 작업
🔀MERG: (Merge branches) 브랜치 병합
🤡MOCK: (Mock things) Mock 데이터 파일 및 코드 추가/수정

 

커밋 형식

[Gitemoji][분류 제목]: [요약]

 

커밋 예제

ex) ♻️REF : 미사용 코드 제거
    ✨ENH : 예약 확인 및 수정 intersectionObserver로 페이징 + 무한스크롤 구현
    💄UXUI: 새 소식 상세 페이지 UI 적용
    🙈IGN : .env.local 파일 무시 추가
    🎉INIT: 프로젝트 시작

 

 

2. 풀 리퀘스트 

1. 반드시 정상적으로 실행이 되는 커밋만 풀 리퀘스트에 포함하기

배포 중단, 코드 충돌, 복잡성, 다른 코드에 악영향 등 다양한 심각한 문제로 이어지기 쉽습니다. 

 

2. 한 번에 수많은 커밋을 포함하지 않기

일주일만 지나도 내가 어떻게 코드 작성했는지 기억이 흐릿해집니다.
누구나 쉽게 이해할 수 있는 풀 리퀘스트는 팀원과 자신에게 큰 자산입니다.

 

3. 칸반(Kanban) 제목과 동일한 풀 리퀘스트 이름 작성하기

지금까지 풀 리퀘스트 제목 정하기 어려우셨죠? 칸반(Kanban) 제목명과 동일하게 작성하시면 됩니다.

 

4. 설명충 대환영입니다.

다른 사람이 작성한 코드를 다시 보는 경우는 사용하거나, 겹친다거나, 문제가 생겼을 때만 보는 것은 정상입니다. 우리 각 자 담당한 업무를 어떻게 해야할 지 고민하고 최적으로 해결하기 위해 공부하느라 고생이 많아서 다른 분들의 코드 리뷰를 디테일하게 하기 힘들잖아요...

 

그래서 누구보다 해당 업무에 대한 이해도가 높으신 여러분들이 이해하기 쉽도록 최소한의 필요한 설명을 남겨주시면, 열심히 만드신 코드를 참고해야 할 때 정말 큰 도움이 되고 작성해주신 분에게도 복습의 일환으로 큰 자산이에요! 담당한 업무를 해결하기 위해 어떠한 고민을 하고 공부하고 채택했는지 디테일한 설명 남겨주시면 정말 좋습니다 :)