# 리포지토리 제한

리포지토리의 제한 사항에 대해 알아봅니다.

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

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

아래 제한 사항의 대부분은 GitHub와 API 모두에 영향을 미칩니다.

## 리포지토리 크기

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

* **디스크 크기**: 10GB

  디스크 크기는 `.git` 폴더(해당 리포지토리가 압축된 형태)를 의미합니다. 리포지토리가 크면 페치 작업의 속도가 느려지고 개발자와 CI의 복제 시간이 길어질 수 있습니다. 다음을 통해 리포지토리 크기를 관리할 수 있습니다.

  * 이진 파일에는 Git 대용량 파일 스토리지(Git LFS)를 사용합니다.
  * 프로그래밍 방식으로 생성된 파일을 개체 스토리지 등의 Git 외부에 저장합니다.

* **디렉터리 폭(단일 디렉터리의 항목 수)**: 3,000

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

* **디렉터리 깊이**: 50

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

* **지점 수**: 5,000

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

## 활동

쓰로틀링과 성능 문제를 피하려면 다음 작동 한도 범위를 유지하는 것이 좋습니다.

* **푸시 크기**: 해당 한도는 2GB로 적용됩니다.

* **단일 개체 크기**:

  권장되는 최대 한도는 1MB입니다. 100MB로 적용됩니다. Git 리포지토리에서 큰 파일을 추적하려면 Git LFS 사용을 권장합니다.
  [Git 대용량 파일 저장소에 대하여](/ko/enterprise-server@3.22/repositories/working-with-files/managing-large-files/about-git-large-file-storage)을(를) 참조하세요.

* **Git 읽기 작업(예: 페치, 복제)**:

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

* **푸시 속도**: 권장되는 최대 푸시 한도는 리포지토리별로 분당 6개입니다.

## 텍스트 제한

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

## 끌어오기 요청 제한

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

* **오픈 풀 리퀘스트(동일한 브랜치에 대한)**: 1,000

  동일한 분기를 대상으로 하는 끌어오기 요청이 많이 열려 있으면 병합 가능성 검사가 느려지거나 시간 제한이 발생할 수 있습니다. 병합 큐를 사용하는 경우 "이 브랜치를 병합하기 전에 최신 상태로 유지해야 함" 설정을 비활성화하는 것이 좋습니다. 이렇게 하면 병합 가능성 검사 대상이 큐의 끌어오기 요청으로 제한됩니다.

* **끌어오기 요청 병합 속도**: 분당 병합된 끌어오기 요청 1회

  각각의 병합은 열려 있는 모든 끌어오기 요청에 대한 병합성 검사를 트리거하며, 이로 인해 특히 사용 중인 리포지토리에서 성능 병목 현상이 발생할 수 있습니다. 이로 인해 개발자 생산성에 영향을 주는 병합 경합 상황이 발생할 수도 있습니다. 부하를 줄이려면 병합 큐를 사용할 때 "병합 전에 이 브랜치가 최신 상태인지 확인" 설정을 비활성화하세요.

## 차이 한계

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

* 풀 리퀘스트에서 전체 diff는 로드할 수 있는 *20,000줄* 또는 \_1MB\_의 원시 diff 데이터를 초과할 수 없습니다.
* 단일 파일의 차이는 \_로드 가능한 20,000줄\_이나 원시 차이 데이터의 \_500KB\_를 초과해서는 안 됩니다. 단일 파일에 대해 \_400줄\_과 \_20KB\_가 자동으로 로드됩니다.
* 단일 차이의 최대 파일 수는 \_300개\_로 제한됩니다.
* 단일 차이에서 렌더링 가능한 파일(이미지, PDF, GeoJSON 파일 등)의 최대 수는 \_25개\_로 제한됩니다.

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

## 커밋 나열 제한

비교 보기 및 끌어오기 요청 페이지에는 `base` 및 `head` 수정 간의 커밋 목록이 표시됩니다. 이러한 목록은 커밋 **250**개로 제한됩니다. 이 제한이 초과된다면 추가 커밋이 있다는 뜻입니다(하지만 추가 커밋이 표시되지는 않습니다).

커밋 탭에 표시되는 커밋의 최대 수는 **10,000개**입니다. 필요한 경우 많은 양의 커밋을 계산하고 열거할 수 있는 `git rev-list --count mybranch` 같은 다른 도구를 사용하십시오.

## 다시 지정 제한

"Rebase and merge" 옵션을 사용하여 풀 리퀘스트를 병합하는 것은 최대 **100개** 커밋으로 제한됩니다.  100개 이상의 커밋이 포함된 끌어오기 요청이 있는 경우, 병합 커밋을 생성하거나, 커밋을 스쿼시 및 병합하거나, 여러 개의 끌어오기 요청으로 커밋을 분할해야 합니다.

## 조직 및 계정 제한

조직과 계정은 **100,000**개의 리포지토리를 초과할 수 없습니다. 계정이 리포지토리 수가 **50,000**개를 초과하면 한도에 근접했음을 알리는 배너가 표시됩니다. 또한 관리자는 이메일 알림을 받게 되며, 추가로 5,000개의 리포지토리가 생성될 때마다 감사 로그가 업데이트됩니다.
[리포지토리 정보](/ko/enterprise-server@3.22/repositories/creating-and-managing-repositories/about-repositories#about-repository-ownership)을(를) 참조하세요.

## 통합 및 GitHub Apps

GitHub에서 통합을 구축할 때는 사용자가 생성한 데이터를 귀하의 계정에 중앙 집중화하지 말고 각 사용자의 GitHub 계정에 저장하세요. 이렇게 하면 사용자가 자신의 작업을 완전히 제어할 수 있으며 리포지토리 한도를 초과하지 않도록 방지할 수 있습니다.