code

GitHub의 프로젝트 대 저장소

starcafe 2023. 6. 7. 23:02
반응형

GitHub의 프로젝트 대 저장소

GitHub에서 프로젝트(리포지토리 내에 만들 수 있음)와 저장소의 개념적 차이는 무엇입니까?

SO에서 몇 가지 유사질문(여기, 여기, 여기)을 보았지만 GitHub 프로젝트가 무엇인지, GitHub 저장소가 무엇인지, 각 질문을 사용해야 하는 시기를 설명하는 질문은 없습니다.

각 용어에 대해 설명하고, 각 용어를 사용/작성할 시기에 대한 예를 제시해 주시면 감사하겠습니다.예를 들어, 프로토타입 애플리케이션이 여러 개 있고 모두 서로 독립적인 경우 모든 애플리케이션의 소스 코드를 체계적으로 관리하려면 무엇을 생성해야 합니까?

사실 1: 프로젝트와 리포지토리는 GitHub에서 항상 동의어였습니다.

사실 2: 이것은 더 이상 사실이 않습니다.

리포지토리 및 프로젝트에 대해 많은 혼란이 있습니다.과거에는 두 용어가 사용자와 GitHub의 자체 문서에 의해 거의 동일하게 사용되었습니다.이는 이 용어들 사이의 미묘한 차이를 설명하는 몇 가지 답변과 의견에 의해 반영됩니다. 그리고 언제 이 용어가 다른 용어보다 선호되었는지를 설명합니다.문제 추적기가 프로젝트의 일부이지만 엄격한 기트로 간주될 수 있는 저장소의 일부가 아닌 등의 차이는 항상 미묘했습니다.

더 이상은 안돼요.

현재 repos 및 프로젝트는 별도의 API를 가진 다른 종류의 엔티티를 말합니다.

그 이후로 repo를 프로젝트라고 부르는 것은 더 이상 옳지 않습니다.공식 문서에서 혼동되는 경우가 많으며 이미 널리 사용된 용어가 새 엔티티의 이름으로 선택된 것은 유감이지만 이 경우가 해당되므로 이를 감수해야 합니다.

결과적으로 저장소와 프로젝트는 일반적으로 혼동되기 때문에 GitHub 프로젝트에 대해 읽을 때마다 정말로 프로젝트에 대한 것인지 아니면 저장소에 대한 것인지 궁금해해야 합니다.만약 그들이 다른 이름이나 "proj"와 같은 약어를 선택했다면, 우리는 논의되는 것이 새로운 유형의 실체, 구체적인 특성을 가진 정확한 물체, 또는 일반적으로 말하는 레포와 같은 종류의 투영이라는 것을 알 수 있었습니다.

일반적으로 명확한 용어는 "프로젝트 보드"입니다.

API를 통해 무엇을 배울 수 있습니까?

Projects API 문서의 첫 번째 끝점은 다음과 같습니다.

다음과 같이 설명됩니다. 리포지토리 프로젝트를 나열합니다.즉, 리포지토리에는 많은 프로젝트가 있을 수 있습니다.그래서 그 둘은 같은 의미를 가질 수 없습니다.여기에는 프로젝트가 비활성화된 경우의 응답이 포함됩니다.

{
  "message": "Projects are disabled for this repo",
  "documentation_url": "https://developer.github.com/v3"
}

즉, 일부 리포지토리에서 프로젝트를 사용할 수 없습니다.다시 말하지만, 레포가 프로젝트를 사용하지 않도록 설정할 수 있는 경우에는 동일하지 않습니다.

다른 흥미로운 엔드포인트가 있습니다.

  • 리포지토리 프로젝트 만들기 -POST /repos/:owner/:repo/projects
  • 조직 프로젝트 생성 -POST /orgs/:org/projects

하지만 없습니다.

  • 사용자 프로젝트 만들기 -POST /users/:user/projects

이것은 우리를 또 다른 차이로 이끌었습니다.

또는 수 .
또는 수 .

또는 더 중요한 것은:

수 그 .
수 수 없습니다.
및 수 .

참고 항목:

혼란스럽다는 거 알아요.저는 최대한 정확하게 설명하려고 노력했습니다.

깃허브는 최근 프로젝트라는 새로운 기능을 소개했습니다.이것은 많은 프로젝트 관리 도구에 일반적인 비주얼 보드를 제공합니다.

프로젝트.

GitHub에 문서화된 리포지토리:

저장소는 GitHub의 가장 기본적인 요소입니다.프로젝트의 폴더로 가장 쉽게 상상할 수 있습니다.리포지토리에는 모든 프로젝트 파일(문서 포함)이 들어 있으며 각 파일의 수정 내역이 저장됩니다.리포지토리에는 여러 공동작업자가 있을 수 있으며 공용 또는 개인 작업자일 수 있습니다.

GitHub에 문서화된 프로젝트:

GitHub의 프로젝트 보드는 당신이 당신의 일을 정리하고 우선순위를 정하는 것을 도와줍니다.특정 피쳐 작업, 포괄적인 로드맵 또는 릴리스 체크리스트를 위한 프로젝트 보드를 만들 수 있습니다.프로젝트 보드를 사용하면 필요에 따라 사용자 정의된 워크플로우를 유연하게 만들 수 있습니다.

혼동의 일부는 새 기능인 프로젝트가 위 문서에서 프로젝트라는 용어의 오버로드된 사용과 충돌한다는 것입니다.

GitHub 리포지토리는 사용자가 관심을 갖는 모든 파일, 폴더 및 기타 리소스를 저장하는 데 사용됩니다.

Git Project : 또한 Git Repository의 Resource 중 하나이며 주로 사용하는 것은 비주얼 보드로 프로젝트를 관리하는 것입니다.Git Repository에서 프로젝트를 생성하면 프로젝트를 관리하기 위한 Kanban 보드와 같은 비주얼 보드를 생성합니다.

이렇게 하면 저장소에 여러 프로젝트가 있을 수 있습니다.

일반적으로 GitHub에서는 저장소 1개 = 프로젝트 1개.예를 들어, https://github.com/spring-projects/spring-boot . 하지만 이것은 어려운 규칙은 아닙니다.

1개의 리포지토리 = 많은 프로젝트.예: https://github.com/donhuvy/java_examples

1개의 프로젝트 = 많은 저장소.예: https://github.com/zendframework/zendframework (Zend Framework 3이라는 이름의 1개 프로젝트에는 61 + 1 = 62개의 저장소가 있습니다. 그렇지 않나요?Zend Frameworks의 모듈 + 메인 저장소를 카운트합니다.)

는 @Brandon Ibbotson 논평에 전적으로 동의합니다.

GitHub 저장소는 폴더와 파일이 존재할 수 있는 "디렉토리"일 뿐입니다.

내가 이해하는 개념적 차이는

  • 프로젝트는 여러 개의 프로젝트를 포함하고 서로 독립적인 프로젝트를 포함할 수 있지만 동시에 여러 개의 프로젝트를 포함할 수도 있습니다.
  • 프로젝트가 특정 기능에 대한 작업 모음일 수 있는 동안 리포지토리는 코드를 저장하는 곳일 뿐입니다.

이해 하셨나요?대규모 저장소에는 여러 사람이 동시에 여러 프로젝트를 수행할 수 있습니다(여러 가지 기능이 모노리스에 추가됨). 대규모 프로젝트에는 서로 상호 작용하는 동일한 프로젝트의 일부인 소규모 저장소가 많이 있을 수 있습니다(마이크로 서비스).그것은 당신이 하고 싶은 것에 대한 개인적인 견해입니다.

repo(스토리지)와 프로젝트(태스크)의 차이가 가장 큰 것 같습니다. 제가 틀렸다면 알려주세요. 설명해주세요!감사해요.

이 질문에 대한 답변을 읽어보면 두 용어는 서로 교환할 수 있으며 아무도 실제로 명확하게 이해할 수 있는 방식으로 두 용어를 구별하지 못했다는 결론에 도달합니다!

이것은 그 주제에 대한 저의 개인적인 이해입니다.

프로젝트의 경우 서로 다른 리포지토리에서 버전 제어를 수행할 수 있습니다.또한 저장소의 경우 전체 프로젝트 또는 프로젝트의 일부를 관리할 수 있습니다.

프로젝트(각 애플리케이션과 독립적인 여러 프로토타입 애플리케이션)에 대해 설명합니다.프로젝트를 하나의 리포지토리 또는 여러 리포지토리별로 관리할 수 있으며, 그 차이는 다음과 같습니다.

  1. 하나의 리포지토리로 관리합니다.응용 프로그램 중 하나가 변경되면 전체 프로젝트(모든 응용 프로그램)가 새 버전에 커밋됩니다.

  2. 여러 리포지토리에서 관리합니다.하나의 응용프로그램이 변경되면 응용프로그램을 관리하는 리포지토리에만 영향을 미칩니다.다른 리포지토리의 버전이 변경되지 않았습니다.

git 어휘와 관련하여 프로젝트는 실제 내용(파일)이 있는 폴더입니다.Repository(리포)는 Git가 프로젝트 폴더에서 수행된 모든 변경 사항에 대한 기록을 보관하는 폴더입니다.그러나 일반적인 의미에서 이 두 가지는 동일하다고 볼 수 있습니다.프로젝트 = 저장소

언급URL : https://stackoverflow.com/questions/40509838/project-vs-repository-in-github

반응형