Git 포크는 실제로 Git 클론입니까?

사람들이 Git에서 코드를 포크한다고 말하고 있습니다. Git "포크"는 Git "복제본"과 미래의 합병을 포기하려는 (의미없는) 심리적 의지와 같이 의심스럽게 들립니다. 힘내에는 포크 명령이 없습니다.

GitHub는 서신에 스테이플 링을하여 포크를 좀 더 실제적으로 만듭니다. 즉, 포크 버튼을 누른 후 나중에 풀 요청 버튼을 누르면 시스템이 소유자에게 이메일을 보낼 정도로 똑똑합니다. 따라서 저장소 소유권 및 권한과 관련하여 약간의 춤입니다.

예 아니오? 이 방향으로 Git을 확장하는 GitHub에 대한 불안이 있습니까? 아니면 기능을 흡수하는 Git 소문이 있습니까?

GitHub 컨텍스트에서 Fork 는 Git을 확장하지 않습니다.
서버 측에서만 복제 할 수 있습니다.

로컬 워크 스테이션에서 GitHub 리포지토리를 복제 할 때 "기여자"로 명시 적으로 선언하지 않으면 업스트림 리포지토리에 다시 기여할 수 없습니다. 클론이 해당 프로젝트의 별도 인스턴스이기 때문입니다. 프로젝트에 공헌하고 싶다면 다음과 같은 방법으로 포크를 사용하면됩니다.

• GitHub 계정에서 해당 GitHub 리포지토리를 복제합니다 (즉, "포크"부분 , 서버 측의 복제본).
• 해당 GitHub 리포지토리에 커밋을 제공합니다 (자체 GitHub 계정에 있으므로 이에 대한 모든 권한을 갖습니다)
• 원래 GitHub 리포지토리 ( 자신의 GitHub 리포지토리에서 변경 한 "풀 요청"부분) 에 대한 흥미로운 기여를 알립니다.

" Collaborative GitHub Workflow " 도 확인하십시오 .

원래 저장소 (업스트림이라고도 함)와의 연결을 유지하려면 해당 원래 저장소를 참조하는 원격을 추가해야합니다.
" GitHub에서 오리진과 업스트림의 차이점은 무엇입니까? "를 참조하십시오.

Git 2.20 (2018 년 4 분기) 이상에서는 델타 아일랜드를 사용 하여 포크에서 가져 오는 것이 더 효율적 입니다.

사람들이 git에서 코드를 포크한다고 말하고 있습니다. Git "포크"는 git "복제본"과 미래의 병합을 포기하는 (의미없는) 심리적 의지와 같은 것으로 보입니다. 자식에는 포크 명령이 없습니다.

"포킹"은 개념으로, 버전 관리 시스템에서 특별히 지원하는 명령이 아닙니다.

가장 간단한 종류의 분기는 분기와 동의어입니다. VCS에 관계없이 지점을 만들 때마다 "포크"됩니다. 이 포크는 일반적으로 다시 합치기가 매우 쉽습니다.

별도의 당사자가 코드의 전체 사본을 가져와 걸어가는 포크의 종류는 반드시 Subversion과 같은 중앙 집중식 시스템에서 VCS 외부에서 발생합니다. Git과 같은 분산 VCS는 전체 코드베이스를 포크하고 효과적으로 새 프로젝트를 시작하는 데 훨씬 더 나은 지원을 제공합니다.

Git (GitHub 아님)은 기본적으로 몇 가지 방식으로 전체 저장소를 "포킹"(즉, 복제) 지원합니다.

• 복제하면 원격 호출 origin이 생성됩니다.
• 기본적으로 클론의 모든 지점은 추적합니다 origin등가물
• 가져온 원본 프로젝트에서 변경 내용을 가져오고 병합하는 것은 매우 쉽습니다.

Git은 원래 프로젝트의 누군가에게 사용자에게 요청하거나 변경 사항을 자신에게 푸시하기 위해 쓰기 권한을 요청하는 것처럼 간단하게 포크 소스에 변경 사항을 제공합니다. 이것이 GitHub가 더 쉽고 표준화하는 부분입니다.

이 방향으로 git를 확장하는 Github에 대한 불안이 있습니까? 또는 기능을 흡수하는 자식 소문이 있습니까?

당신의 가정이 틀리기 때문에 불안하지 않습니다. GitHub는 멋진 GUI와 풀 요청을 발행하는 표준화 된 방법으로 Git의 분기 기능을 "확장"하지만 Git에 기능을 추가 하지는 않습니다 . 전체 리 포크 포킹의 개념은 근본적인 수준에서 분산 버전 제어에 바로 적용됩니다. 언제든지 GitHub를 버릴 수 있으며 "포크 한"프로젝트를 계속 푸시 / 풀할 수 있습니다.

예, 포크는 복제품입니다. 허가 없이는 다른 사람의 사본으로 푸시 할 수 없기 때문에 등장했습니다 . 그들은 당신을 위해 그것 의 사본 을 만듭니다 ( fork ), 당신도 글을 쓸 수 있습니다.

나중에 실제 소유자 또는 다른 사용자가 변경 사항과 같은 포크를 사용하는 경우 자신의 저장소로 다시 가져올 수 있습니다. 또는 "풀 요청"을 보낼 수도 있습니다.

이 문맥에서 "포크"는 "내 자신의 수정을 추가 할 수 있도록 코드를 복사하십시오"를 의미합니다. 할 말이 많지 않습니다. 모든 클론은 본질적으로 포크이며 포크에서 변경 사항을 가져올 지 여부를 결정하는 것은 원본에 달려 있습니다.

복제에는 git 저장소의 사본을 로컬 시스템에 작성하는 것이 포함되며, forking은 저장소를 다른 저장소에 복제합니다. 복제는 개인적인 용도로만 사용되지만 (향후 병합이 발생할 수는 있지만) 포크를 사용하면 가능한 새로운 프로젝트 경로를 복사하여 열 수 있습니다.

일부 프로젝트에 참여하기로 결정하면 분기가 수행됩니다. 히스토리 로그와 함께 전체 프로젝트의 사본을 작성합니다. 이 사본은 전적으로 저장소에서 작성되며 일단 변경하면 풀 요청을 발행합니다. 이제 소스 요청에 따라 소스 요청을 수락하고 변경 사항을 원래 코드에 통합하십시오.

Git clone은 사용자가 소스 사본을 얻을 수있는 실제 명령입니다. git clone [URL] 이것은 자신의 로컬 리포지토리에 [URL]의 복사본을 만들어야합니다.

포크는 다른 저장소의 사본이지만 계정이 수정되었다고 생각합니다. 예를 들어, 다른 리포지토리를 로컬로 직접 복제하는 경우 원격 개체 원본은 여전히 ​​복제 한 계정을 사용합니다. 코드를 커밋하고 기여할 수 없습니다. 단지 순수한 코드 사본입니다. 그렇지 않으면 리포지토리를 포크하면 github 계정의 계정 설정 업데이트로 리포지토리가 복제됩니다. 그런 다음 계정 컨텍스트에서 리포지토리를 복제하면 코드를 커밋 할 수 있습니다.

"포크"가 무엇인지에 대한 오해가 있습니다. 포크는 실제로 사용자 별 분기 집합에 지나지 않습니다. 포크로 푸시하면 실제로는 유일한 저장소이기 때문에 원래 저장소로 푸시합니다.

커밋을 확인한 다음 원래 리포지토리로 이동하고 커밋 ID를 사용하여 포크로 푸시하여 시도해 볼 수 있습니다. 커밋이 원래 리포지토리에 있음을 알 수 있습니다.

이것은 많은 의미가 있지만 분명하지는 않습니다 (최근에 실수로 만 발견했습니다).

John이 저장소 SuperProject를 포크 할 때 실제로 발생하는 것처럼 보이는 것은 소스 저장소의 모든 분기가 "John.master", "John.new_gui_project"등과 같은 이름으로 복제 된 것입니다.

GitHub는 "John"을 "숨 깁니다". GitHub의 저장소에 대한 "복사본"을 가지고 있다는 착시를 제공하지만 필요하지도 않습니다.

따라서 내 포크 브랜치 "master"의 이름은 실제로 "Korporal.master"이지만 GitHub UI에서는이를 표시하지 않으며 "master"만 표시합니다.

이것은 내가 어쨌든 내가 최근에 해왔 던 것들을 기반으로 후드 아래에서 계속 생각하는 것입니다. 당신이 그것을 숙고 할 때 매우 좋은 디자인입니다.

이러한 이유로 Microsoft가 Visual Studio Team Services 오퍼링에서 Git 포크를 구현하는 것이 매우 쉽다고 생각합니다.

복제가 서버에서 시스템으로 이루어지고 포크 작업이 서버 자체에서 복제되고 있다는 사실 외에도 중요한 차이점은 복제 할 때 실제로 모든 분기, 레이블 등을 얻는다는 것입니다.

그러나 분기 할 때 실제로는 마스터 브랜치의 현재 파일 만 가져옵니다. 이것은 우리가 다른 가지 등을 얻지 못한다는 것을 의미합니다.

따라서 무언가를 원래 저장소로 다시 병합해야하는 경우 저장소 간 병합이므로 더 높은 권한이 필요합니다.

포크는 Git의 명령이 아닙니다. GitHub이 구현하는 개념 일뿐입니다. Git은 마스터 복사본과 동기화 할 필요없이 피어 투 피어 환경에서 작동하도록 설계되었습니다. 서버는 또 다른 피어이지만 마스터 복사본으로 간주합니다.

가장 간단한 용어로

저장소를 포크 한다고 말하면 기본적으로 GitHub 계정의 GitHub ID 아래에 원래 저장소의 사본이 작성됩니다.

과

리포지토리를 복제 한다고 말하면 GitHub 계정에 사본이 없어도 시스템 (PC / 노트북)에서 직접 원래 리포지토리의 로컬 사본을 생성하게됩니다.