개요
기본적으로 데이터베이스에 직접 원시 개체를 만들고 분기 참조를 업데이트하여 Git을 설치하지 않고도 Git에서 수행할 수 있는 모든 작업을 기술적으로 수행할 수 있으므로 REST API를 통해 많은 Git 기능을 다시 구현할 수 있습니다.
REST API는 Git 리포지토리가 비어 있거나 사용할 수 없는 경우 409 Conflict를 반환합니다. 사용할 수 없는 리포지토리는 일반적으로 GitHub가 리포지토리를 만드는 중임을 의미합니다. 빈 리포지토리의 경우, PUT /repos/{owner}/{repo}/contents/{path} REST API 엔드포인트를 사용해 콘텐츠를 만들고 리포지토리를 초기화하면 해당 API를 사용해 Git 데이터베이스를 관리할 수 있습니다. 이 응답 상태가 지속되면 사이트 관리자에게 문의에 문의하세요.
Git 개체 데이터베이스에 대한 자세한 내용은 Pro Git 책의 Git Internals 챕터를 참조하세요.
예를 들어 리포지토리의 파일에 대한 변경 내용을 커밋하려는 경우 다음을 수행합니다.
- 현재 커밋 개체 가져오기
- 가리키는 트리 검색
- 해당 특정 파일 경로에 대해 트리에 있는 Blob 개체의 콘텐츠 검색
- 어떻게든 콘텐츠를 변경하고 새 콘텐츠가 포함된 새 Blob 개체를 게시하여 Blob SHA 다시 가져오기
- 해당 파일 경로 포인터가 트리 SHA를 다시 가져오는 새 Blob SHA로 대체된 새 트리 개체 게시
- 현재 커밋 SHA를 부모로 지정하고 새 트리 SHA를 사용하여 새 커밋 개체를 생성한 후에 커밋 SHA를 다시 가져오기
- 브랜치 참조를 업데이트하여 새 커밋 SHA를 가리키도록 하세요.
복잡해 보일 수 있지만 모델을 이해하고 API로 할 수 있는 많은 작업을 열면 실제로 매우 간단합니다.
끌어오기 요청의 병합 가능성 확인
경고
merge Git 참조를 업데이트할 때 Git을 직접 사용하거나 GET /repos/{owner}/{repo}/git/refs/{ref}에 의존하지 마세요. 이 경우 경고 없이 내용이 오래될 수 있습니다.
소비하는 API는 테스트 병합 커밋을 생성하기 위해 명시적으로 풀 리퀘스트를 요청해야 합니다. 테스트 병합 커밋은 UI에서 끌어오기 요청을 보고 “병합” 단추가 표시되거나 REST API를 사용하여 끌어오기 요청을 가져오거나, 만들거나, 편집할 때 만들어집니다. 이 요청이 없으면 다음에 누군가가 끌어오기 요청을 볼 때까지 merge Git 참조가 만료됩니다.
현재 오래된 merge Git ref를 생성하는 폴링 메서드를 사용하는 경우 GitHub 다음 단계를 사용하여 기본 분기에서 최신 변경 내용을 가져오는 것이 좋습니다.
- 풀 리퀘스트 웹후크를 수신합니다.
- 병합 커밋 후보를 만들기 위한 백그라운드 작업을 시작하려면
GET /repos/{owner}/{repo}/pulls/{pull_number}를 호출합니다. -
[ `GET /repos/{owner}/{repo}/pulls/{pull_number}` ](/rest/pulls/pulls#get-a-pull-request)를 사용하여 리포지토리를 폴링하여 `mergeable` 특성이 `true` 또는 `false`인지 확인합니다. 이전 단계를 수행한 후에만 Git을 직접 사용하거나 [`GET /repos/{owner}/{repo}/git/refs/{ref}`](/rest/git/refs#get-a-reference)를 통해 `merge` Git 참조를 업데이트할 수 있습니다.