This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. The development, release, and timing of any products, features, or functionality may be subject to change or delay and remain at the sole discretion of GitLab Inc.

Status	Authors	Coach	DRIs	Owning Stage	Created
proposed					-

이 문서는 진행 중이며, Cells 디자인의 매우 초기 단계를 나타냅니다. 중요한 측면들이 문서화되지 않았지만, 우리는 미래에 이를 추가할 계획입니다. 이것은 Cells를 위한 하나의 가능한 아키텍처이며, 우리는 구현할 접근 방법을 결정하기 전에 이를 대안과 대조할 것을 의도합니다. 이 문서는 우리가 이 접근 방식을 선택하지 않기로 결정하더라도 그 이유를 문서화하기 위해 유지될 것입니다.

Cells: Contributions: Forks

Forking workflow는 사용자가 기존 프로젝트 소스를 자신이 선택한 네임스페이스(개인 또는 그룹)로 복사할 수 있는 작업 흐름입니다.

1. 정의

Forking workflow는 다양한 사용 패턴을 가진 일반적인 작업 흐름입니다:

사용자들이 상류 프로젝트로 기여할 수 있게 합니다.
리포지터리를 개인 네임스페이스에 지속시킵니다.
사용자들은 프로젝트를 복사하여 변경한 후 수정된 프로젝트로 릴리스할 수 있습니다.

Forks를 통해 상위 프로젝트에 쓰기 액세스 권한이 없는 사용자도 변경을 가할 수 있습니다. Forking workflow는 오픈 소스 커뮤니티에서 상류 프로젝트로 기여하는 데 특히 중요합니다. 그러나, 특정 회사에서 책임의 강력한 분할과 더 엄격한 액세스 제어를 선호하는 경우에도 중요합니다. 프로젝트에 대한 액세스는 특정 개발자 디렉터리으로 제한됩니다.

Forks를 통해 다음이 가능해집니다:

상류 프로젝트를 수정할 수 있는 사용자의 더 강력한 제어.
책임의 분할: 상위 프로젝트는 프로덕션 시스템에 연결된 CI 구성을 사용할 수 있습니다.
더 제한적인 환경에서 fork의 컨텍스트에서 CI 파이프라인을 실행합니다.
모든 fork를 심사되지 않은 것으로 간주하여 프로젝트와 관련된 비밀이나 다른 정보의 유출 위험을 줄입니다.

다음 이유로 forking 모델은 Cells 아키텍처에서 문제가 됩니다:

Forks는 기존 리포지터리의 복제본입니다. Forks는 서로 다른 조직, Cells 및 Gitaly 샤드 간에 생성될 수 있습니다.
사용자들은 Merge Request을 생성하고 상류 프로젝트로 기여할 수 있습니다. 이 상류 프로젝트는 다른 조직 및 Cell에 있을 수 있습니다.
Merge Request CI 파이프라인은 소스 프로젝트의 컨텍스트에서 실행되지만 대상 프로젝트의 컨텍스트에서 표시됩니다.

2. 데이터 탐색

데이터 탐색에서 현재의 fork에 대한 다음 정보를 검색했습니다:

현재 GitLab.com에 약 180만 개의 fork가 있습니다.
fork의 대다수는 개인 네임스페이스에 속합니다(82%).
우리는 동일한 최상위 그룹 및/또는 조직 내에서 fork를 최소한 예상하고 있었습니다. Forking은 프로젝트에 액세스할 권한이 없는 사용자를 위해서만 필요합니다. 회사 내부에서는 프로젝트에 대한 권한이 서로 다른 팀원들 사이에서 마침표가 다른 경우를 제외하고 fork 작업을 많이 기대하지 않을 것입니다. 데이터에 의하면 fork 관계의 9%만이 최상위 최상위 네임스페이스 식별자(최상위 그룹과 개인 네임스페이스)를 일치시킵니다. 나머지 91%의 fork 관계는 서로 다른 최상위 네임스페이스를 통해 fork됩니다. 최상위 그룹을 식별할 때 최상위 그룹을 식별할 때 다음과 같이 확인했습니다:
- fork된 프로젝트 중 3%가 동일한 조직 내의 상류 프로젝트에서 fork됨.
- fork된 프로젝트의 83%는 상하 게프로젝트와 관련된 식별 가능한 조직이 없습니다.
- 나머지 14%는 다른 회사에서 소스 프로젝트에서 fork됨.
지난 12개월 동안 활동한 최상위 그룹의 9% (95,000 개)는 fork 관계를 가진 프로젝트를 가지고 있으며, 지난 12개월 동안 활동이 없는 최상위 그룹의 5% (91,000 개)는 fork 관계를 가진 프로젝트를 가지고 있습니다. 이러한 최상위 그룹을 Cells에 영향을 받을 것으로 예상합니다.

3. 제안

3.1. Forks는 현재 조직의 전용 기여 공간에 생성됩니다

조직 간에 프로젝트를 생성하는 대신, forks는 조직 내의 기여 공간에 생성됩니다. 기여 공간은 기본 조직에 존재하는 개인 네임스페이스와 유사하지만, 차이점은 기여자가 기여하려는 조직 내에 존재한다는 것입니다. 예시:

조직을 볼 수 있는 모든 사용자(공개 조직의 경우 모든 사용자)는 조직 내에 기여 공간을 생성할 수 있습니다. 이것은 해당 조직의 프로젝트를 fork할 수 있는 전용 네임스페이스로, 예를 들어 Produce Inc.에서 gitlab.com/organization/produce-inc/@ayufan으로 될 수 있습니다.
기여 공간을 생성하기 위해 조직의 멤버십이 필요하지 않습니다. 이것은 기여자가 그룹이나 프로젝트로 초대되지 않고도 fork를 생성하고 Merge Request을 만들 수있는 오픈 소스 작업 흐름을 방해할 수 있기 때문입니다. 우리는 엄격하게 가시성을 준수하므로 사용자들은 초대되기 전에는 비공개 조직에서 fork를 생성할 수 없을 것입니다.
프로젝트에 대한 fork를 생성하는 경우 사용자들은 조직 내의 그룹에 속한 fork를 생성할 수 있는 옵션만을 볼 수 있을 것입니다. 또한 사용자들에게 기여 공간을 생성하고 fork를 그 곳에 둘 수 있는 옵션을 제공할 것입니다. 오늘날은 fork를 생성할 때 “그룹 생성” 옵션이 있습니다. 이 기능 역시 새로운 fork를 저장할 조직 내의 새로운 그룹 생성으로만 제한될 것입니다.
기여하고 싶지만 기여할 의향이 없는 사용자들을 지원하기 위해 언링크된 fork를 생성하는 옵션을 고려할 수 있습니다. (../../../../user/project/repository/forking_workflow.md#unlink-a-fork)
사용자는 기여한 조직의 기여 공간을 할 수 있는 만큼의 기여 공간을 보유합니다.
사용자들은 기여 공간 내에 추가적인 개인 프로젝트를 생성할 수 없습니다. 개인 프로젝트는 여전히 개인 네임스페이스에 생성될 수 있습니다.
조직은 기여 공간의 사용을 방지하거나 비활성화할 수 있습니다. 이것은 조직 내의 그룹에 속하지 않은 모든 사람의 fork를 비활성화할 것입니다.
현재의 모든 fork는 조직 내 사용자의 기여 공간으로 이동합니다. 이것은 fork가 상류 프로젝트 외부의 데이터에 연결되어 있을 경우 데이터 손실을 야기할 수 있기 때문에 개인 프로젝트는 보존된 채로 남아 있고 fork 관계는 제거될 것입니다.
모든 fork는 해당 조직의 일부입니다.
Fork는 연방되지 않는 특징을 가집니다.
기여 공간 및 fork한 프로젝트는 부모 프로젝트와 구성을 공유하지 않습니다.
조직이 삭제될 경우, fork를 포함한 프로젝트는 기본 조직으로 이동하거나 그들을 담을 수 있는 새로운 조직이 생성될 것입니다. 이는 사실상 이전 조직의 유령 조직입니다.
기여 공간의 데이터는 고객 사용량에 기여하지 않습니다.
현재 우리는 조직 범위의 러너를 가지고 있지 않지만, 만약 우리가 구현한다면 이것들은 아마 기여 공간 프로젝트에서 어떤 방식 또는 그들이 사용되는 방식에 대한 특별한 설정이 필요할 것입니다.

3.2. 클러스터 내 포크

본 제안은 통신이 클러스터의 모든 신뢰된 셀 간에 API를 통해 이루어지는 클러스터 내 포크를 구현합니다.

포크는 항상 사용자가 선택한 그룹의 맥락에서 생성됩니다.
포크는 조직에서 격리됩니다.
조직이나 그룹 소유자는 조직 간 포킹 또는 포킹 일반을 비활성화할 수 있습니다.
Merge Request은 대상 프로젝트의 맥락에서 생성되며, 다른 셀의 외부 프로젝트를 참조합니다.
대상 프로젝트에는 정보 제시에 사용되는 Merge 참조가 전달됩니다.
현재처럼 CI 파이프라인이 소스 프로젝트의 맥락에서 가져오고, 그 결과가 대상 프로젝트의 Merge Request에 가져옵니다.
대상 프로젝트를 보유한 셀은 소스 프로젝트의 상태를 가져오기 위해 내부적으로 GraphQL을 사용하고, Merge Request의 정보에 포함합니다.

장점:

기존 포크는 모두 클러스터 내 포크로 처리되므로 계속 작동합니다.

단점:

조직의 목적은 조직 간의 강력한 격리를 제공하는 것입니다. 포킹을 허용함으로써 보안 경계가 깨질 수 있습니다.
그러나 이는 현재 사용자들이 로컬 컴퓨터에 리포지터리를 복제하고 선택한 리포지터리로 푸시할 수 있는 능력과 다르지 않습니다.
소스 프로젝트의 액세스 제어는 상위 프로젝트의 것보다 낮을 수 있습니다. 현재 시스템은 기여하기 위해 포크 및 상위 프로젝트의 액세스 수준이 동일해야 한다는 요구 사항을 가지고 있습니다.

3.3. 포크는 현재 프로젝트의 내부 프로젝트로 생성됩니다.

조직 간 프로젝트를 생성하는 대신, 포크는 기존 프로젝트에 첨부됩니다. 프로젝트를 포킹하는 각 사용자는 고유한 프로젝트를 받게 됩니다. 예시:

프로젝트: gitlab.com/gitlab-org/gitlab의 경우, 포크는 gitlab.com/gitlab-org/gitlab/@kamil-gitlab에 생성됩니다.
포크는 현재 조직의 맥락에서 생성되며, 조직 경계를 넘어가지 않고 조직에서 관리됩니다.
사용자에게 묶임(또는 포크의 기타 사용자 지정된 이름).
포크는 연방화된 기능이 아닙니다.

단점:

모든 기존 포크를 어떻게 처리하고 이주할지에 대한 답이 되지 않습니다.
현재 그룹/프로젝트 설정을 공유할 수 있으며, 이는 일부 보안 경계를 깰 수 있습니다.

3.4. 포크는 현재 조직의 개인 네임스페이스에 생성됩니다.

모든 사용자는 각 공개 조직에 개인 네임스페이스를 가질 수 있습니다. 조직을 처음 방문하면 사용자는 해당 조직에 대한 범위가 지정된 개인 네임스페이스를 받게 됩니다. 사용자는 업스트림 리포지터리가 개인 네임스페이스와 동일한 조직에 있는 경우 개인 네임스페이스로 포크를 생성할 수 있습니다. 조직을 제거하면 해당 조직의 개인 네임스페이스가 제거됩니다.

장점:

대부분의 기존 코드 경로를 재사용합니다.
대부분의 기존 제품 설계 규칙을 재사용합니다.
조직 경계가 자연스럽게 격리됩니다.
여러 개인 네임스페이스를 사용하면 사용자가 개인 프로젝트를 조직 간으로 섞지 않고 분리할 수 있게 됩니다.
대부분의 사용자가 하나의 조직에서 작업할 것으로 예상되기 때문에 대부분의 사용자가 각각의 개인 프로젝트를 어느 조직에 저장했는지 기억할 필요가 없을 것입니다.

단점:

중복되는 개인 네임스페이스가 생성될 것입니다. 우리는 향후 반복에서 이를 개선할 것으로 예상합니다.
여러 개인 네임스페이스는 특히 많은 수의 조직을 거쳐 작업할 때 난항을 겪을 수 있습니다. 우리는 이를 예외상황으로 예상합니다.
개인 네임스페이스의 수명 주기는 이미 사용자 계정이나 공개되지 않은 자체 설치와 같은 것과 마찬가지로 조직에 달려있을 것입니다.
조직 개인 네임스페이스는 새로운 URL 경로가 필요합니다.
기존의 개인 네임스페이스 경로가 적응되어야 할 것입니다.

URL 경로 변경은 토론 중입니다.

4. 평가

이미 많은 어려운 문제들을 해결했기 때문에 3.4. 포크는 현재 조직의 개인 네임스페이스에 생성됩니다를 따를 것입니다. URL 경로를 다시 작업하거나 여러 개인 네임스페이스를 처리하는 것과 같은 이 제안의 단점은 관리할 수 있으며, 다른 대안 제안을 통해 만들어진 문제들보다 덜 중요합니다.

5. 예시

예시로, gitlab-org/gitlab을 다른 조직으로 이동하는 경우에 대한 본 제안의 영향을 설명하겠습니다. gitlab-org/gitlab은 8천개가 넘는 포크가 있습니다.

이 방향이 해당 포크의 카노니컬 URL에 영향을 미치나요?

네. 포크의 카노니컬 URL은 변경될 것입니다. 구체적인 경로 변경은 토론 중에 있습니다. 기존 사용자들은 레거시 개인 네임스페이스에서 포크를 계속 기여하려면 이를 소스 프로젝트 조직의 개인 네임스페이스로 이주해야 합니다. 예를 들어 https://gitlab.com/DylanGriffith/gitlab에서의 개인 네임스페이스 포크는 https://gitlab.com/-/organizations/gitlab-inc/@DylanGriffith/gitlab로 이주되어야 합니다. 우리는 이를 자동으로 이동시키는 방법을 제공할 수 있겠지만, 매뉴얼으로 진행되는 경우에는 다음과 같은 과정이 필요할 것입니다:

기여 공간 포크 생성
원본 포크에서 로컬 브랜치를 새 포크로 푸시
여전히 열려 있는 Merge Request을 다시 만들고 Merge하는 경우

리포지터리 자체의 Git URL에는 영향을 미치나요?

네. 구체적인 경로 변경은 토론 중에 있습니다.

해당 포크가 조직 내에서 또는 기여 공간으로 이동될 때 사용자의 조치가 필요할까요?

아니요. 조직이 공개되어 있다면, 사용자는 개인 네임스페이스를 가지게 될 것입니다.

저희가 기존에 GitLab.com에서 호스팅되는 공개 프로젝트의 기존 포크를 망가뜨리지 않을 것이라고 약속할 수 있나요?

기존 포크 프로젝트는 삭제되지 않지만 그 포크 관계는 제거될 것입니다. 오픈 소스 프로젝트 소유자에게 이 프로젝트를 이주할 때 기존의 포크에서 포크 관계가 끊어질 것임을 알려줄 것입니다. 이들의 Merge Request을 모두 닫아야 한다는 요구 사항 때문에, 이들의 포크를 이동시키려면 이전의 Merge Request의 히스토리를 유지하는 프로세스가 필요할 것입니다. gitlab-org/gitlab의 경우, 이 프로젝트를 이동할 때 이들의 포크를 끊을 것임을 오픈 소스 프로젝트 소유자에게 알리겠습니다. 이 프로세스에 대한 최소한의 자동 이주가 어떠한 경우에도 허용 가능한지에 대한 추가 피드백을 요청할 것입니다. 그러나 이동 후 기여자의 작업 흐름은 변경될 것이므로 이는 특별한 사건이 될 것입니다.