포킹 워크플로

1. 개발자가 '공식' 서버 쪽 리포지토리를 '포크'합니다. 이렇게 하면 자체 서버 쪽 복사본이 만들어집니다.

2. 새 서버 쪽 복사본이 로컬 시스템에 복제됩니다.

3. '공식' 리포지토리의 Git 원격 경로가 로컬 복제에 추가됩니다.

4. 새 로컬 기능 브랜치가 만들어집니다.

5. 개발자가 새 브랜치에서 변경을 수행합니다.

6. 변경 사항에 대한 새 커밋이 만들어집니다.

7. 브랜치는 개발자의 자체 서버 쪽 복사본으로 푸시됩니다.

8. 개발자가 새 브랜치에서 '공식' 리포지토리로 풀리퀘스트를 엽니다.

9. 풀리퀘스트는 병합 승인을 얻고 원래 서버 쪽 리포지토리로 병합됩니다.

공식 코드베이스에 기능을 통합하기 위해 유지 관리자는 기여자의 변경 사항을 로컬 리포지토리로 풀해서 프로젝트가 중단되지 않는지 확인하고, 로컬 메인 브랜치에 병합한 다음 메인 브랜치를 서버의 공식 리포지토리로 푸시합니다. 이제 프로젝트에 이 기여가 포함되며, 다른 개발자들은 공식 리포지토리에서 변경 사항을 풀해서 로컬 리포지토리를 동기화해야 합니다.

포킹 워크플로에서 “공식” 리포지토리라는 개념은 단지 관례에 불과하다는 점을 이해하는 것이 중요합니다. 사실, 공식 리포지토리를 "공식"으로 부르는 유일한 이유는 프로젝트 유지 관리자의 공개 리포지토리이기 때문입니다.

"포크된" 리포지토리와 "포킹"은 특별한 작업이 아니라는 점에 유의하세요. 포크된 리포지토리는 표준 git clone 명령을 사용하여 만들어집니다. 포크된 리포지토리는 주로 "서버 쪽 복제"이며, 보통 Bitbucket 같은 타사 Git 서비스에서 관리하고 호스팅합니다. 포크된 리포지토리를 만드는 고유한 Git 명령은 없습니다. 복제 작업은 기본적으로 리포지토리 및 리포지토리 이력의 복사본입니다.

이 개인 공용 리포지토리는 모두 다른 개발자와 브랜치를 공유하는 편리한 방법일 뿐입니다. 모든 사람은 기능 브랜치 워크플로 및 Gitflow 워크플로에서와 마찬가지로 개별 기능을 분리하기 위해 여전히 브랜치를 사용해야 합니다. 유일한 차이점은 브랜치를 공유하는 방식입니다. 기능 브랜치 및 Gitflow 워크플로에서는 브랜치를 공식 리포지토리로 푸시하는 반면 포킹 워크플로에서는 브랜치를 다른 개발자의 로컬 리포지토리로 풀합니다.

포킹 워크플로 프로젝트에 새로 온 개발자는 모두 공식 리포지토리를 포크해야 합니다. 앞서 말했듯이, 포킹은 표준 git clone 작업일 뿐입니다. 서버로 SSH를 수행하고 git clone을 실행하여 서버의 다른 위치에 복사하면 됩니다. Bitbucket처럼 인기 있는 Git 호스팅 서비스는 이 단계를 자동화하는 리포지토리 포킹 기능을 제공합니다.

포킹 워크플로 프로젝트에 새로 온 개발자는 모두 공식 리포지토리를 포크해야 합니다. 앞서 말했듯이, 포킹은 표준 git clone 작업일 뿐입니다. 서버로 SSH를 수행하고 git clone을 실행하여 서버의 다른 위치에 복사하면 됩니다. Bitbucket처럼 인기 있는 Git 호스팅 서비스는 이 단계를 자동화하는 리포지토리 포킹 기능을 제공합니다.

Bitbucket을 사용하여 리포지토리를 호스팅한다고 가정하면 프로젝트 개발자는 자체 Bitbucket 계정이 있어야 하며 다음을 사용하여 리포지토리의 포크된 복사본을 복제해야 합니다.

다른 Git 워크플로에서는 중앙 리포지토리를 가리키는 단일 원본 원격 리포지토리를 사용하지만, 포킹 워크플로에는 두 개의 원격 리포지토리가 필요합니다. 하나는 공식 리포지토리용이고 다른 하나는 개발자의 개인 서버 쪽 리포지토리용입니다. 이런 원격 리포지토리를 원하는 대로 부를 수 있지만, 일반적인 관례는 원본 리포지토리를 포크된 리포지토리용 원격 리포지토리(git clone을 실행하면 자동으로 만들어짐) 및 공식 리포지토리용 업스트림 리포지토리로 사용하는 것입니다.

위 명령을 사용하여 업스트림 원격 리포지토리를 직접 만들어야 합니다. 이렇게 하면 공식 프로젝트가 진행되는 동안 로컬 리포지토리를 쉽게 최신 상태로 유지할 수 있습니다. 참고로 업스트림 리포지토리의 인증이 활성화된 경우(즉, 오픈소스가 아닌 경우) 다음과 같이 사용자 이름을 입력해야 합니다.

사용자는 공식 코드베이스에서 복제하거나 풀하기 전에 유효한 비밀번호를 입력해야 합니다.

다른 Git 워크플로에서와 마찬가지로 개발자는 포크된 리포지토리의 개발자 로컬 복사본에서 코드를 편집하고, 변경 사항을 커밋하고, 브랜치를 만들 수 있습니다.

모든 변경 사항은 공개 리포지토리로 푸시하기 전까지는 완전히 비공개 상태 입니다. 또한 공식 프로젝트가 진행되면 git pull로 새 커밋에 액세스할 수 있습니다.

개발자는 전용 기능 브랜치에서 작업해야 하기 때문에 일반적으로 빨리 감기 병합으로 이어집니다.

새 기능을 공유할 준비가 되면 개발자는 두 가지 작업을 수행해야 합니다. 우선, 기여를 공용 리포지토리로 푸시하여 다른 개발자들이 접근할 수 있게 해야 합니다. 원본 원격 리포지토리가 이미 설정되어 있어야 합니다. 그런 경우 다음 작업만 수행하면 됩니다.

원본 원격 리포지토리가 메인 코드베이스가 아니라 개발자의 개인 서버 쪽 리포지토리를 가리킨다는 점에서 다른 워크플로와 다릅니다.

둘째, 개발자는 프로젝트 유지 관리자에게 해당 기능을 공식 코드베이스에 병합하겠다고 알려야 합니다. 그러면 Bitbucket에는 공식 리포지토리에 병합할 브랜치를 지정할 것인지 묻는 양식으로 연결되는 “풀리퀘스트” 버튼이 제공됩니다. 보통은 기능 브랜치를 업스트림 원격 리포지토리의 메인 브랜치에 통합하고 싶을 것입니다.

요약하자면, 포킹 워크플로는 일반적으로 공개 오픈소스 프로젝트에서 사용됩니다. 포킹은 프로젝트 리포지토리의 서버 복사본에서 실행되는 git clone 작업입니다. 포킹 워크플로는 대개 Bitbucket과 같은 Git 호스팅 서비스와 함께 사용됩니다. 포킹 워크플로의 간략한 예는 다음과 같습니다.

1. bitbucket.org/userA/open-project에서 호스팅되는 오픈소스 라이브러리에 기여하려고 합니다

2. Bitbucket을 사용하면 bitbucket.org/YourName/open-project로 리포지토리 포크를 만들 수 있습니다

3. 로컬 시스템에서 https://bitbucket.org/YourName/open-project에서 git clone을 실행하여 리포지토리의 로컬 복사본을 얻습니다

4. 로컬 리포지토리에 새 feature 브랜치를 만듭니다

5. 새 기능을 완료하는 작업이 끝나면 git commit을 실행하여 변경 사항을 저장합니다

6. 그런 다음 새 기능 브랜치를 포크된 원격 리포지토리로 푸시합니다

7. Bitbucket을 사용하여 bitbucket.org/userA/open-project에서 원본 리포지토리에 대한 새 브랜치용 풀리퀘스트를 엽니다

포킹 워크플로는 프로젝트 유지 관리자가 각 개별 기여자에 대한 권한 부여 설정을 수동으로 관리할 필요 없이 개발자의 기여에 대해 리포지토리를 열 수 있도록 지원합니다. 따라서 유지 관리자는" 풀" 스타일 워크플로를 더 많이 이용할 수 있습니다. 오픈소스 프로젝트에서 가장 일반적으로 사용되는 포킹 워크플로는 비공개 비즈니스 워크플로에도 적용되기 때문에 릴리스에 병합되는 내용을 신뢰할 수 있는 방식으로 제어할 수 있습니다. 배포 매니저가 있거나 릴리스 주기가 엄격한 팀이 유용하게 사용할 수 있습니다.

어떤 워크플로가 나에게 적합한지 잘 모르겠다면 종합적인 Git 워크플로 비교 페이지를 확인해 보세요.