Close

포킹 워크플로

포킹 워크플로는 인기 있는 다른 Git 워크플로와 근본적으로 다릅니다. 이 워크플로는 단일 서버 쪽 리포지토리를 사용하여 "중앙" 코드베이스 역할을 하도록 하는 대신 모든 개발자에게 자체 서버 쪽 리포지토리를 제공합니다. 즉, 각 기여자가 하나가 아닌 개인 로컬 리포지토리와 공용 서버 쪽 리포지토리, 총 2개의 Git 리포지토리를 갖게 됩니다. 포킹 워크플로는 공개 오픈소스 프로젝트에서 가장 자주 볼 수 있습니다.

포킹 워크플로의 가장 큰 장점은 모두가 하나의 중앙 리포지토리로 푸시할 필요 없이 기여를 통합할 수 있다는 것입니다. 개발자는 자체 서버 쪽 리포지토리로 푸시하고 프로젝트 유지 관리자만 공식 리포지토리로 푸시할 수 있습니다. 이렇게 하면 유지 관리자가 개발자에게 공식 코드베이스에 대한 쓰기 권한을 주지 않고도 모든 개발자의 커밋을 수락할 수 있습니다.

포킹 워크플로는 보통 Gitflow 워크플로에 기반한 브랜칭 모델을 따릅니다. 즉, 전체 기능 브랜치가 원래 프로젝트 유지 관리자의 리포지토리에 병합하는 데 사용된다는 뜻입니다. 그 결과 대규모의 유기적인 팀(신뢰할 수 없는 타사 포함)이 안전하게 공동 작업할 수 있는 유연한 방법을 제공하는 분산형 워크플로가 가능합니다. 이 워크플로는 오픈소스 프로젝트에도 이상적입니다.


작동 방식


다른 Git 워크플로와 마찬가지로 포킹 워크플로는 서버에 저장된 공식 공용 리포지토리에서 시작됩니다. 하지만 새 개발자가 프로젝트 작업을 시작하려고 할 때 공식 리포지토리를 직접 복제하지 않습니다.

대신 공식 리포지토리를 포크해서 서버에 복사본을 만듭니다. 이 새 복사본은 개인 공용 리포지토리 역할을 합니다. 다른 개발자는 여기로 푸시할 수는 없지만 변경 사항을 풀할 수는 있습니다. (이 사실이 왜 중요한지 잠시 후에 살펴보겠습니다.) 개발자는 서버 쪽 복사본을 만든 후에 git clone을 수행하여 로컬 컴퓨터에 복사본을 가져옵니다. 다른 워크플로와 마찬가지로 이 복사본은 비공개 개발 환경으로 사용됩니다.

개발자가 로컬 커밋을 게시할 준비가 되면 공식 리포지토리가 아닌 자체 공용 리포지토리로 커밋을 푸시합니다. 그다음에 메인 리포지토리로 풀리퀘스트를 제출하여 프로젝트 유지 관리자에게 업데이트를 통합할 준비가 되었음을 알립니다. 풀리퀘스트는 기여한 코드에 이슈가 있을 때 편리한 토론 스레드 역할도 합니다. 다음은 이 워크플로의 단계별 예시입니다.

콘솔 창
관련 자료

고급 Git 로그

Bitbucket 로고
솔루션 보기

Bitbucket Cloud에서 Git에 대해 알아보기

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 clone https://user@bitbucket.org/user/repo.git

원격 리포지토리 추가


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

git remote add upstream https://bitbucket.org/maintainer/repo

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

git remote add upstream https://user@bitbucket.org/maintainer/repo.git

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

브랜치에서 작업하기: 변경 실행 및 푸시


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

git checkout -b some-feature # Edit some code git commit -a -m "Add first draft of some feature"

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

git pull upstream main

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

풀 리퀘스트 만들기


리포지토리 일러스트레이션

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

git push origin feature-branch

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

둘째, 개발자는 프로젝트 유지 관리자에게 해당 기능을 공식 코드베이스에 병합하겠다고 알려야 합니다. 그러면 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 워크플로 비교 페이지를 확인해 보세요.


이 문서 공유

여러분께 도움을 드릴 자료를 추천합니다.

이러한 리소스에 책갈피를 지정하여 DevOps 팀의 유형에 대해 알아보거나 Atlassian에서 DevOps에 대한 지속적인 업데이트를 확인하세요.

도구로 가득한 벽을 사용하여 협업하는 사람들

Bitbucket 블로그

DevOps 일러스트레이션

DevOps 학습 경로

Atlassian 전문가와 함께 하는 Demo Den 기능 데모

Bitbucket Cloud가 Atlassian Open DevOps와 작동하는 방법

DevOps 뉴스레터 신청

Thank you for signing up