포크 워크플로 살펴보기

Forking 워크플로는 널리 사용되는 다른 Git 워크플로와 근본적으로 다릅니다.

"중앙" 코드베이스 역할을 하는 단일 서버 쪽 리포지토리를 사용하는 대신, 모든 개발자에게 해당하는 서버 쪽 리포지토리를 제공합니다.

즉, 각 참가자는 다음의 두 가지 Git 리포지토리를 보유합니다.

Forking 워크플로는 공개 오픈 소스 프로젝트에서 가장 많이 나타납니다.

Forking 워크플로의 주요 이점은 모든 사람이 단일 중앙 리포지토리에 푸시하지 않고도 기여를 통합할 수 있다는 점입니다.

개발자가 해당하는 서버 쪽 리포지토리에 푸시하면 프로젝트 유지 관리자만 공식 리포지토리에 푸시할 수 있습니다.

이를 통해 유지 관리자는 공식 코드베이스에 대한 쓰기 권한을 부여하지 않고 개발자의 커밋을 허용할 수 있습니다.

포크 워크플로는 일반적으로 원래 프로젝트 유지 관리자의 리포지토리에 병합하기 위한 것입니다.

그 결과, 대규모의 유기적 팀(신뢰할 수 없는 제3자 포함)이 안전하게 협업할 수 있는 유연한 방법을 제공하는 분산 워크플로를 제공합니다.

이를 통해 오픈 소스 프로젝트에 이상적인 워크플로도 만들 수 있습니다.

작동 방식

다른 Git 워크플로와 마찬가지로 Forking 워크플로는 서버에 저장된 공식 공용 리포지토리로 시작합니다.

하지만 새 개발자가 프로젝트 작업을 시작하려는 경우 공식 리포지토리를 직접 복제하지 않습니다.

대신, 공식 리포지토리를 포크하여 서버에 복사본을 만듭니다.

이 새 복사본은 개인 공용 리포지토리로 사용됩니다. 다른 개발자가 이 리포지토리에 푸시할 수는 없지만, 변경 내용을 풀할 수는 있습니다(이것이 필요한 이유는 잠시 후에 확인할 수 있음).

서버 쪽 복사본을 만든 후 개발자는 git 복제를 수행하여 로컬 컴퓨터로 이 복사본을 가져옵니다.

해당 복사본은 다른 워크플로에서와 마찬가지로 개인 개발 환경으로 사용됩니다.

로컬 커밋을 게시할 준비가 되면 이는 공식 리포지토리가 아니라 공용 리포지토리에 커밋을 푸시합니다.

그런 다음 기본 리포지토리를 사용하여 끌어오기 요청을 제출하고 이를 통해 프로젝트 유지 관리자는 업데이트 통합 준비가 되었음을 알 수 있습니다.

또한 제공되는 코드에 문제가 있는 경우 끌어오기 요청은 편리한 토론 스레드로 사용됩니다.

다음은 이 워크플로의 단계별 예제입니다.

기능을 공식 코드베이스에 통합하려면 다음을 수행합니다.

이제 기여는 프로젝트의 일부에 해당하며, 다른 개발자가 로컬 리포지토리를 동기화하려면 공식 리포지토리에서 풀해야 합니다.

Forking 워크플로에서 "공식" 리포지토리의 개념은 단순히 규칙이라는 점을 이해하는 것이 중요합니다.

공식 리포지토리를 만드는 유일한 것이므로, 공식은 프로젝트 유지 관리자의 리포지토리에 해당합니다.

"포크된" 리포지토리와 "forking"이 특별한 작업이 아니라는 점에 유의해야 합니다.

포크된 리포지토리는 표준 git clone 명령을 사용하여 만듭니다. 포크된 리포지토리는 일반적으로 Azure Repos와 같은 Git 서비스 공급자에 의해 관리되고 호스트되는 "서버 쪽 복제본"입니다.

포크된 리포지토리를 만드는 고유한 Git 명령은 없습니다.

복제 작업은 기본적으로 리포지토리와 해당 기록의 복사본입니다.