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

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