커밋 이전 ‘빌드’하여 에러가 있는지 검사하기!
(나중에 Dev까지 Merge하고 문제 터지면 팀장한테 혼날 수 있음)
가벼운 테스트를 통하여 최소한의 동작을 확인한 후 버그 발생 시 수정 필요
(사격 했는데 나중에 대미지가 안들어가서 디버깅 포인트 찍히는 상황 등을 예방 가능!)
하나의 커밋에 너무 많은 내용을 담기보다는 쪼개서 커밋하기
(Histroy 등을 통해 변경 여부를 파악하기 쉬워지며, 문제가 된 커밋을 찾기도 비교적 쉬움)
깃헙 규칙 - 커밋 네이밍
아래의 타입에 따라 ‘~~ Update’ Or ‘Add ~~’ 와 같은 방식을 통해
어떠한 내용이 반영되었는지의 가독성 증가
작업 타입
작업내용
✨ update
해당 파일에 새로운 기능이 생김
🎉 add
없던 파일을 생성함, 초기 세팅
🐛 bugfix
버그 수정
♻️ refactor
코드 리팩토링
🩹 fix
코드 수정
🚚 move
파일 옮김/정리
🔥 del
기능/파일을 삭제
🍻 test
테스트 코드를 작성
🙈 gitfix
gitignore 수정
🔨script
package.json 변경(npm 설치 등)
💻init
프로젝트 생성
깃헙 규칙 - 브랜치 규칙
Main (Matser) : 기본 / 도전 과 같이 큰 줄기를 완성함에 따라 Merge할 브랜치
Dev : 개발 베이스 브랜치 (Feature 브랜치에서 기능 구현을 확인한 후, Merge)
Dev에 Merge하는 경우, 전/후에 미리 Slack 등에 공지하여
Git 충돌을 피할 것!
Feature_기능 : 네이밍에 해당하는 ‘기능’을 구현하는 브랜치
(Dev Merge 이후 깔끔하게 제거하는 것을 권장)
(Dev에 Merge 하기전에, Dev 브랜치가 앞서있는지를 Fetch 등을 통해 확인하고
Merge or Rebase하여 안전하게 Merge 하자)
개인 브랜치(선택) : 개발하는 내용의 용량이 큰 경우의 선택적 브랜치
깃헙 규칙 - 작업 요청 및 책임 관련
가능하다면 클래스 작성자가 수정하는 것을 권장
다만 작성자에게 ‘허락’을 맡고 수정하는 경우는 커밋의 세부적 내용에 표기하며
해당 내용은 별도의 Feature 브랜치를 파거나 Dev에 직접 커밋하여
다른 작성자들에게 해당 사실을 공유하였으면 함