github 관련)
무신사 페이지의 일부 데이터는 'utf-16' 방식의 인코딩으로 되어 있어, 해당 데이터를 Write 시에 문제가 발생할 수 있다. => 따라서, csv파일로 저장할 때 encoding='utf-16'으로 설정해 주어야 한다. (utf-8 , euc-kr, ansi, cp949 ansi 모두 안 된다.. ) + 인코딩 BOM 관련: https://brownbears.tistory.com/124
python의 logging module. 로그를 기록할 때 매우 유용하다 !..
github 현업 시의 규칙)
브랜치 관련)
브랜치 전략으로 Git-Flow를 사용한다.
main branch
: 배포 가능한 상태만을 관리한다.
develop branch
: 기능 개발을 위한 브랜치들을 병합하기 위해 사용한다.
모든 기능이 추가되고 버그가 수정되어 배포 가능한 안정적인 상태라면 해당 develop 브랜치를 master 브랜치에 merge한다.
평소에는 이 브랜치를 기반으로 개발을 진행한다.
feature branch
: 기능을 개발하는 브랜치로, 새로운 기능 개발 및 버그 수정이 필요할 때마다 develop 브랜치로부터 분기한다.
feature 브랜치에서의 작업은 기본적으로 공유할 필요가 없기 때문에 자신의 로컬 저장소에서 관리한다.
개발이 완료되면 develop 브랜치로 merge하여 팀원과 공유한다.
더 이상 필요하지 않은 feature 브랜치는 삭제한다.
release branch
: 배포를 위한 브랜치로, 최종적인 버그 수정이나 문서 추가 등 배포와 관련된 작업을 수행한다.
배포 관련 작업 이외에는 release 브랜치에 새로운 기능을 추가로 merge하지 않는다.
hotfix branch
: 배포한 버전에 긴급하게 수정을 해야 할 필요가 있을 경우, master 브랜치에서 분기한다.
문제가 되는 부분을 수정 후에 master 브랜치에 merge하고 배포한다.
hotfix 브랜치에서의 변경 사항은 develop 브랜치에도 merge한다.
중심이 되는 master와 develop 브랜치를 제외한 나머지 feature, release, hotfix 브랜치는 merge되면 삭제하도록 한다.
🌿 Naming Rule
master와 develop 브랜치는 본래 이름을 사용하도록 한다.
feature 브랜치는 feature/기능요약 형식을 사용하도록 한다.
release 브랜치는 release-버전 형식을 사용하도록 한다.
hotfix 브랜치는 hotfix-버전 형식을 사용하도록 한다.
Commit 관련)
프로젝트를 진행하면서 커밋 메시지를 작성할 때, 다음의 원칙을 따르도록 한다.
⭐ Structure
type: title (필수)
body (선택)
- 작업한 내용
footer (선택)
🌙 Type
타입은 소문자로 작성한다.
feat - 새로운 기능 추가
fix - 버그나 코드 수정
docs - 문서 수정 (README.md, Issue Template, 라이센스 등)
style - 코드 포맷팅, 세미콜론 누락 등 코드의 변경이 없는 경우
refactor - 코드 리팩토링
test - 테스트 코드, 리팩토링 테스트 코드 추가
chore - 빌드 업무 수정, 패키지 매니저 수정 등 설정 변경 (.gitignore 포함)
☀ Title
제목은 총 50자 이내이며, 마지막에 마침표를 붙이지 않는다.
영어와 한글을 자유롭게 사용하되, 영어 사용 시 대문자로 시작하며 명령어로 작성한다.
⚡ Body & Footer
본문의 내용은 커밋의 이유나 무엇이 왜 변경되었는지 간단히 작성한다.
본문과 꼬리말은 선택적으로 작성하며, 다른 부분과 구분하기 위해 한칸을 띄우고 작성하도록 한다.
💫 Example
feat: OO 기능 구현
- OO을 위해 OO 기능을 구현
Resolves #10
See also #11, #13