리포지토리 제한

특정 유형의 리소스는 크기가 매우 크기 때문에 GitHub에서의 과도한 처리가 요구됩니다. 따라서 요청이 적절한 시간 내에 완료될 수 있도록 제한이 설정됩니다. 권장 한도 최댓값을 초과하면 기본 Git 작업에 대한 반응 시간 저하, UI 대기 시간을 비롯한 리포지토리 상태 저하의 위험이 증가합니다.

참고 항목

이 지침을 따르면 리포지토리 안정성을 향상할 수는 있지만, 다른 요소로 인해 예기치 않은 동작이 발생할 수 있으므로 지원 가능성을 보장하지는 않습니다.

아래 제한은 대부분은 GitHub 및 API 모두에 영향을 줍니다.

리포지토리 크기

성능과 관리 효율성을 최적의 상태로 유지하려면 리포지토리 구조와 크기에 관한 다음 한도 최댓값 범위를 유지하는 것이 좋습니다.

디스크 크기: 10GB

디스크 크기는 .git 폴더(해당 리포지토리가 압축된 형태)를 의미합니다. 리포지토리가 크면 페치 작업의 속도가 느려지고 개발자와 CI의 복제 시간이 길어질 수 있습니다. 다음을 통해 리포지토리 크기를 관리할 수 있습니다.
- 이진 파일용 Git 대용량 파일 스토리지(Git LFS)을 사용합니다.
- 프로그래밍 방식으로 생성된 파일을 개체 스토리지 등의 Git 외부에 저장합니다.
디렉터리 폭(단일 디렉터리의 항목 수): 3,000

자주 수정되는 파일이 많이 들어 있는 디렉터리는 리포지토리 유지 비용을 크게 높이고 기본 Git 작업의 성능을 저하시킬 수 있습니다. 파일을 단순 디렉터리 구조로 분할하면 이러한 트리의 크기가 줄어들어 새로 생성되는 데이터가 줄어듭니다.
디렉터리 깊이: 50

디렉터리 트리의 깊이가 깊으면 기록 검색 작업이 느려질 수 있습니다.
분기 수: 5,000

분기 수가 많을 경우 페치 작업에서 불필요한 데이터가 발생하여 전송 시간이 느려질 수 있고, 극단적인 경우 리포지토리 성능이 제한될 수 있습니다.

활동

제한이나 성능 문제를 피하려면 다음 운영 한도 범위를 유지하는 것이 좋습니다.

푸시 크기: 해당 한도는 2GB로 적용됩니다.
단일 개체 크기:

권장되는 최대 한도는 1MB입니다. 100MB로 적용됩니다. Git 리포지토리에서 큰 파일을 추적하려면 Git LFS을 사용하는 것이 좋습니다. Git Large File Storage 정보을(를) 참조하세요.
Git 읽기 작업(예: 페치, 복제):

권장되는 최대 작업 한도는 리포지토리별로 초당 15개입니다. 읽기 작업량이 많아지면 리포지토리의 성능이 제한될 수 있습니다. CI나 머신 사용자 또는 타사 애플리케이션 등의 자동화 프로세스는 경우에 따라 리포지토리의 성능을 저하시킬 수 있습니다. CI의 복제 전략을 최적화하거나 리포지토리 캐시 서버를 사용하는 것이 좋습니다. 얕은 클론은 전체 클론보다 서버에 더 적은 비용과 부담을 주어 더 나은 성능을 발휘할 수 있습니다.
푸시 속도: 권장되는 최대 푸시 한도는 리포지토리별로 분당 6개입니다.

GitHub은(는) Markdown 및 Mermaid 다이어그램과 같은 일부 파일의 서식이 지정된 미리 보기를 표시합니다. GitHub은(는) 파일이 작을 경우(일반적으로 2MB 미만) 항상 이러한 미리 보기를 렌더링하려고 시도하지만, 복잡한 파일은 시간이 초과되어 일반 텍스트로 대체되거나 전혀 표시되지 않을 수 있습니다. 이러한 파일은 항상 raw.githubusercontent.com을 통해 서비스되는 원시 형식(예: https://raw.githubusercontent.com/octocat/Spoon-Knife/master/index.html)으로 사용할 수 있습니다. 원시 단추를 클릭하여 파일의 원시 URL을 가져옵니다.

끌어오기 요청 제한

끌어오기 요청 작업이 많은 리포지토리의 지연 및 성능 문제를 줄이려면 다음 한도 내 범위를 유지하는 것이 좋습니다.

끌어오기 요청 열기(대상: 동일 분기): 1,000

동일한 분기를 대상으로 하는 끌어오기 요청이 많이 열려 있으면 병합 가능성 검사가 느려지거나 시간 제한이 발생할 수 있습니다. 병합 큐를 사용하는 경우 "require this branch to be up to date before merging" 설정을 사용하지 않도록 설정하는 것이 좋습니다. 이렇게 하면 병합 가능성 검사 대상이 큐의 끌어오기 요청으로 제한됩니다.
끌어오기 요청 병합 속도: 분당 병합된 끌어오기 요청 1회

각각의 병합은 열려 있는 모든 끌어오기 요청에 대한 병합성 검사를 트리거하며, 이로 인해 특히 사용 중인 리포지토리에서 성능 병목 현상이 발생할 수 있습니다. 이로 인해 개발자 생산성에 영향을 주는 병합 경합 상황이 발생할 수도 있습니다. 부하를 줄이려면 병합 큐를 사용할 때 "require this branch to be up to date before merging" 설정을 사용하지 않도록 설정합니다.

차이 제한

차이가 매우 클 수 있으므로 커밋, 끌어오기 요청 및 비교 보기에 대한 차이에 이러한 제한을 적용합니다.

끌어오기 요청에서 총 차이는 로드할 수 있는 20,000줄 또는 _1MB_의 원시 Diff 데이터를 초과할 수 없습니다.
단일 파일의 차이는 로드할 수 있는 20,000줄 또는 _500KB_의 원시 Diff 데이터를 초과할 수 없습니다. 단일 파일에 대해 _400줄_과 _20KB_가 자동으로 로드됩니다.
단일 차이의 최대 파일 수는 _300개_로 제한됩니다.
단일 차이에서 렌더링 가능한 파일(이미지, PDF, GeoJSON 파일 등)의 최대 수는 _25개_로 제한됩니다.

제한된 차이의 일부 부분이 표시될 수 있지만, 제한을 초과하는 부분은 표시되지 않습니다.

이 문서의 내용

리포지토리 크기

활동

텍스트 제한

끌어오기 요청 제한

차이 제한

커밋 나열 제한

다시 지정 제한

조직 및 계정 제한

웹후크 및 GitHub Apps