Redddy's Devlog

들어가며깃허브 organizations에서 여러 레포지토리를 만들어 작업을 하더라도 issue 나 pr 템플릿은 동일하게 가져가고 싶을 수 있다. 각 레포지토리마다 .github/ISSUE_TEMPLATE 디렉토리 만들고 그 하위에 이슈 템플릿 만들거나, pull_request_template.md 사용해서 pr 템플릿을 만들 수도 있다. 하지만 이렇게 만들면 중복된다는 문제가 발생한다!  해결예를 들어 한 organizations에 있는 backend 레포지토리와 frondend 레포지토리에서 동일한 issue 및 pr 템플릿을 사용하고 싶다면 .github 라는 이름의 레포지토리를 만들고 그 레포지토리 안에서 issue 및 pr 템플릿을 만들면 된다!    courgette 레포지토리와 aubergi..

문제우테코에서 프로젝트를 진행할 때 각 팀당 주어지는 레포지토리는 하나이다. 코딩해듀오는 백엔드와 프론트엔드 브랜치 prefix를 BE와 FE로 정하여 여기에서 작업을 하고 백엔드 코드와 프론트코드 모두 있는 브랜치는 production으로 정하였다. 다시 말해 prefix가 BE면 백엔드 코드만, FE면 프론트엔드 코드만 존재하고 production 브랜치에는 백엔드, 프론트엔드 코드 모두 존재한다.  백엔드 코드와 프론트엔드 코드 각자도생하다가 런칭 페스티벌 즈음에 production 브랜치에서 만났다. 이 브랜치에서 만나는 과정도 CI/CD 파일들이 컨플릭트 나긴 하였지만 어찌저찌 잘 해결하였다.  하지만 문제는 BE/test 브랜치에서 production 코드를 pull 땡겨와 머지하는 실수를 하..

로컬 환경에서 코드를 수정하고, add와 commit이란 작업을 하는데 commit message를 남길 때 규칙이 있다. Commit message 7가지 규칙 제목과 본문을 빈 행으로 구문한다 제목을 50글자 내로 제한 제목 첫 글자는 대문자로 작성 제목 끝에 마침표 넣지 않기 제목은 명령문으로 사용하며 과거형을 사용하지 않는다 본문의 각 행은 72글자 내로 제한 어떻게 보다는 무엇과 왜를 설명한다 Commit message 구조 다음과 같은 구조가 commit message 에서 사용되고 있다. : Type feat: 새로운 기능 추가, 기존의 기능을 요구 사항에 맞추어 수정 fix: 기능에 대한 버그 수정 build: 빌드 관련 수정 chore: 패키지 매니저 수정, 그 외 기타 수정 ex) .g..