방식 A - 개인 저장소 + Collaborator

개념: 한 사람이 만들고, 팀원을 초대한다

개인 저장소 + Collaborator 방식은 가장 직관적인 GitHub 협업 구조입니다. 팀원 중 한 명이 자기 GitHub 계정에 저장소를 만들고, 나머지 팀원을 Collaborator로 초대합니다.


팀원 A (저장소 Owner)
  └── github.com/teamA/project  ← 저장소 생성
        ├── 팀원 B (Collaborator)  ← 초대받음
        ├── 팀원 C (Collaborator)  ← 초대받음
        └── 팀원 D (Collaborator)  ← 초대받음

Collaborator로 초대된 팀원들은 저장소에 직접 push할 수 있는 권한을 갖게 됩니다. fork 없이 같은 저장소에서 함께 작업합니다.

참고: fork 기반 워크플로우 fork란 원본 저장소를 내 GitHub 계정에 복사하는 것입니다. 주로 오픈소스 기여 시 사용합니다 - 원본 저장소에 직접 push 권한이 없을 때, fork한 내 복사본에서 작업한 뒤 원본에 PR을 보내는 방식입니다.

이 튜토리얼에서는 Collaborator로 초대되어 저장소에 직접 push할 수 있으므로, fork 기반 워크플로우는 다루지 않습니다.

권한 구조: Owner vs Collaborator

권한	Owner	Collaborator
코드 push	O	O
브랜치 생성/삭제	O	O
PR 생성 및 merge	O	O
저장소 설정 변경	O	X
Collaborator 추가/제거	O	X
저장소 삭제	O	X

핵심 포인트 Collaborator는 코드 작업에 필요한 거의 모든 권한을 갖지만, 저장소 자체를 관리하는 권한(설정 변경, 삭제 등)은 Owner만 가집니다.

장점

빠른 시작 - 저장소를 만들고 팀원을 초대하면 바로 협업을 시작할 수 있습니다. 별도의 조직 생성이나 설정이 필요 없습니다.
별도 설정 불필요 - Organization을 만들거나 Team을 구성할 필요가 없어 초기 설정 비용이 비교적 적습니다.
학습 비용 낮음 - GitHub 기본 기능만으로 충분합니다. Collaborator 초대는 직관적이고 간단합니다.

단점

저장소가 개인 계정에 귀속 - 저장소가 Owner의 개인 계정에 속하므로, Owner가 탈퇴하거나 계정을 삭제하면 저장소에 접근할 수 없게 됩니다.
세밀한 권한 제어 어려움 - Collaborator에게는 모두 동일한 수준의 권한이 부여됩니다. "이 사람은 읽기만, 저 사람은 쓰기도" 같은 구분이 어렵습니다.
저장소 단위 관리 - 프로젝트가 여러 저장소로 나뉘면, 각 저장소마다 Collaborator를 따로 관리해야 합니다.

소유권이 걱정된다면? Owner의 계정에 저장소가 귀속되더라도, clone한 로컬 저장소(내 컴퓨터에 있는 저장소)에 모든 코드와 커밋 이력이 남아 있으므로 코드 자체가 사라지는 것은 아닙니다. 만약 프로젝트를 본인 계정에서 독립적으로 유지보수하고 싶다면, git clone --mirror로 본인 계정에 완전한 복사본을 만들어 둘 수 있습니다. 자세한 방법은 챕터 2의 프로젝트 종료 후 포트폴리오 정리 세션을 참고하세요.

적합한 상황

2-6명 규모의 소규모 팀
수 주에서 수 개월 정도의 단기 프로젝트
저장소가 1개인 프로젝트
빠른 시작이 중요하고 별도의 권한 관리가 필요 없을 때

Collaborator 방식의 장단점을 살펴봤는데, 그렇다면 더 체계적인 권한 관리가 필요하다면 어떻게 해야 할까요? 다음 세션에서는 Organization 방식을 알아봅니다.