3번의 프로젝트를 진행하면서 추후 참고할 만한 부분만 가져왔습니다. 1. 디렉터리 구조 frontend, backend 소스코드에 이미지 빌드를 위한 Dockerfile을 생성.https 인증서 발급을 위한 cert-compose.yml과 nginx.conf.db를 위한 db-compose.yml 생성.application 실행을 위한 app-compose.yml과 reverse proxy를 위한 nginx 설정 파일들 추가. 2. Dockerfile 예시 가. frontend (react)# 5173 port를 사용하는 React를 정적으로 빌드하다음 Nginx를 이용해 배포한다.# nginx 이미지를 사용합니다. 뒤에 tag가 없으면 latest 를 사용합니다.FROM nginx:1.26.1# roo..

GitHub의 Branch Rules에 변경 사항이 생겨서 새로 정리해 보았습니다. 아래는 각 규칙과 해당 기능에 대한 설명입니다. 1. Branch Rules 종류 및 설명 규칙설명주요 용도Restrict creations브랜치 생성 제한무분별한 브랜치 생성 방지Restrict updates브랜치 업데이트 제한권한 없는 사용자의 직접 푸시 방지Restrict deletions브랜치 삭제 제한중요 브랜치 보호Require linear history선형 히스토리 강제깔끔한 Git 히스토리 유지Require merge queue병합 큐 사용 강제체계적인 병합 순서 관리Require deployments to succeed배포 성공 요구안정적인 배포 보장Require signed commits서명된 커밋 요구..

GitLab에 저장된 작업물을 Github으로 옮기는 방법을 정리해 보았습니다.  1. Remote 변경하기 기존의 GitLab Repo를 clone하고 remote를 Github Repo로 수정한다. 이를 위해선 Github에 새로운 Repo가 생성되어있어야 한다.git clone https://old_git.gitcd old_git/git remote remove origingit remote add origin https://github.com/new_azgit.gitgit branch -M maingit push origingit clone --branch master --single-branch https://old_git.git : 하나의 branch만 clone하고 싶은 경우. 2. BFGG..

1. 문서화 기본적으로 README를 하나하나 사람이 직접 만드는 것은 생각보다도 복잡하고 많은 시간과 노력을 필요로 한다. 스크립트의 양이 많고 복잡하기 때문이다. 또한 아주 상세하게 작성된 설명은 사실상 코드를 직접 보는 것과 차이가 없을 수 있다. (고도로 발단된 설명은 코드와 다를 바 없다.) 차라리 코드에 대한 최소한의 설명을 주석으로 추가하는 것이 올바를 수 있다. 이에 정해진 규칙에 따라서 작성된 주석을 자동으로 문서화하는 프로그램을 사용할 수도 있다. 3줄 요약 닥치고 md를 작성하는 짓은 멍청하다. → 이럴 바에는 그냥 코드를 보고 이해하는 것이 더 올바르다. 그럼에도 코드를 보고서 쉽게 파악하기 동작 원리는 주석으로 추가하는 것이 옳다. 필요하다면 최소한의 클래스와 메서드만 자동으로 문..

1. Projects 생성 개발 프로세스 전반을 관리하기 위해서 사용한다. 가. view 생성 + New view를 누르면 다양한 형태의 view를 생성할 수 있다. Table 형태의 view다. 다른 view에서 추가한 item들은 다른 view에도 자동으로 추가된다. Board를 통해서 작업의 status를 쉽게 파악하고 관리할 수 있다. Roadmap은 작업의 일정을 쉽게 파악하고 관리할 수 있다. 일정 관리를 위해서 별도의 문서를 추가로 작성하지 않아도 되어 편하다. 나. fields Robby scene, In Game scene 등 카테고리 fields값을 기준으로 그룹을 지었다. 이외에도 땡땡이를 누르면 field값을 이용해서 filter를 걸 수도 있고 정렬도 할 수 있다. 다. Setti..

1. Branch Protection rules 선택할 수 있는 rule이 너무 많다. 사용할 때마다 설명을 추가하겠다. Branch name pattern : Protection rule이 적용될 브랜치를 선택한다. 정규 표현식을 지원하는 것 같다. Require a pull request before merging → Require a approvals : merge 전에 PR을 생성하고 다른 사람의 승인이 필요함. 협업 시 branch를 direct push로부터 보호하고 코드 리뷰를 강제하기 위함. Require status checks to pass before merging : status check를 통과해야만 merge 된다. status check란 PR시 동작하는 테스트 정도로 이해하자..

1. Git flow 💡 Git-flow는 총 5가지의 브랜치를 사용해서 운영을 합니다. main(master) : 기준이 되는 브랜치로 제품을 배포하는 브랜치 입니다. develop : 개발 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 합칩니다. feature : 단위 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop 브랜치에 합칩니다. release : 배포를 위해 master 브랜치로 보내기 전에 먼저 QA(품질검사)를 하기위한 브랜치. hotfix : master 브랜치로 배포를 했는데 버그가 생겼을 떄 긴급 수정하는 브랜치 입니다. develop 브랜치를 기준으로 작업에 필요한 새로운 branch 만들어서 작업 후에 develop에 merge 하기.

1. 빈 박스 생성하기 - [ ] 2. 체크된 박스 생성하기 - [x] - [X] 대소문자 상관없이 x 추가.