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 하기.

0. 참고 자료 GitHub의 대용량 파일 정보 - GitHub Docs GitHub의 크기 제한 정보 GitHub는 파일 과 리포지토리 크기에 대한 하드 제한이 있지만 모든 Git 리포지토리에 풍부한 스토리지를 제공하려고 시도합니다. 사용자의 성능과 안정성을 보장하기 위해 docs.github.com 1. Github 용량 제한 GitHub은(는) 리포지토리에 허용되는 파일의 크기를 제한합니다. GitHub는 100MB보다 큰 파일을 차단합니다. 50MB보다 큰 파일을 추가하거나 업데이트하려고 하면 Git에서 경고가 표시됩니다. (성공적으로 푸시되지만 커밋을 제거하고 별도의 방식을 사용하자. ) 2. 리포지토리의 기록에서 파일 제거 본격적으로 대용량 파일을 푸시하는 방법에 대하여 알아보기 전에 잘못 푸..

로컬에서 작업을 하다가 pull을 할 때 conflict가 발생한다. 원격 저장소의 변경사항과 로컬 저장소의 변경사항 사이에 누구를 우선적으로 반영할지 판단하기 어려워서 발생한 것 같다. conflict를 해결해보자. 1. conflict 발생 늘 하던 대로 pull 했더니 다음과 같이 문제가 생겼다. ❯ git pull origin mysql https://github.com/ramen4598/Study_nodeJS URL에서 * branch mysql -> FETCH_HEAD 힌트: You have divergent branches and need to specify how to reconcile them. 힌트: You can do so by running one of the following co..

0. 참고자료 해당 글은 notion ai의 도움을 받아서 작성했습니다. 1. Github Issue에 대한 설명과 사용법 Github Issue는 Github에서 제공하는 이슈 트래킹 시스템입니다. 이슈란 소프트웨어 개발 과정에서 발생할 수 있는 버그, 개선사항, 질문 등을 의미합니다. Github Issue를 사용하면 개발자들은 프로젝트에 대한 이슈들을 신속하게 식별하고 추적할 수 있습니다. 이슈는 프로젝트의 일정 관리, 문제 해결, 협업 및 팀 커뮤니케이션에 매우 유용합니다. 가. Issue 생성하기 Github Repository에서 Issue를 생성하려면 다음과 같다. 1. Github Repository에서 Issues를 클릭합니다. 2. New Issue를 클릭합니다. 3. 이슈 제목과 설명..

사실 따로 정리할까 했지만 시간이 없다. 투자하는 시간대비 얻는게 적은 것 같다. 필요한 순간에 다시 공부하기 좋은 순서로 학습자료를 올려둔다. 드림코딩 유튜브 생활코딩 유튜브 2023년 7월 5일 추가 [Github] 문서화를 위한 action (Doxygen) 1. 문서화 기본적으로 README를 하나하나 사람이 직접 만드는 것은 생각보다도 복잡하고 많은 시간과 노력을 필요로 한다. 스크립트의 양이 많고 복잡하기 때문이다. 또한 아주 상세하게 작성된 ramen4598.tistory.com 실제 action을 활용한 작업물.