[Git] 분산 환경에서의 Git 워크플로

중앙집중형 버전 관리 시스템 vs Git

중앙집중형 버전 관리 시스템

• 각 개발자는 중앙 저장소를 중심으로 하는 하나의 노드역할만 한다

Git

• 개발자가 하나의 노드 역할을 한다
• 또한 중앙 저장소 같은 역할도 가능하다

 

여기서 다루는 워크플로는 크게 세 가지다.

1. 중앙집중식 워크플로
2. Integration-Manager 워크플로
3. Dictator and Lieutenants 워크플로

---

1. 중앙집중식 워크플로

이 워크플로는 중앙집중식 버전 관리 시스템에서 사용했던 워크플로다.

Git은 중앙집중식이 아니지만, 여전히 이 방식을 사용할 수 있다.

 

중앙 저장소는 하나 존재한다.

개발자들은 하나의 중앙 저장소를 clone하여 사용한다.

 

중앙 저장소에 로컬 저장소에 반영되지 않은 최신 사항이 있는 경우, 이를 fetch하고 merge한 뒤에야 push가 가능하다.

 

사용법

1. 중앙 저장소를 생성한다.
2. 모든 개발자에게 이 저장소에 Push 권한을 부여한다.
3. 개발자들은 작업 사항을 중앙 저장소에 Push한다.

---

2. Integration-Manager 워크플로

Git에선 하나의 로컬 저장소에 여러 개의 원격 저장소를 둘 수 있다.

또한, 나는 Push가 가능하지만 다른 사람들은 읽기만 가능한 공개 저장소를 만들 수도 있다.

이 점을 활용한 것이 Integration-Manager 워크플로다.

 

 

사람들

• 기여자(공식 저장소 push 불가)
• Integration-Manager(공식 저장소 push 가능)

이 워크플로에선 기여자와 Integration-Manager로 나뉜다.

 

모든 개발자들은 공식 저장소(blessed repository)를 clone하여 로컬에서 작업한다.

이후 개발이 된 사항을 본인의 공개 저장소에 push한다.

하지만 각 개발자들은 공식 저장소에 push할 권한이 없기 때문에, 권한이 있는 Integration-Manager에게 자신의 공개 저장소의 내용을 pull할 것을 요청한다(pull request, pr).

 

Integration-Manager는 pr을 보내온 기여자들의 공개 저장소를 자신의 로컬 저장소의 원격 저장소로 등록한 뒤(한 로컬 저장소에 여러 개의 원격 저장소를 등록할 수 있으므로), 로컬에서 테스트를 거친 뒤 이상이 없으면 공식 저장소로 push한다.

 

장점

• 기여자와 Integration-Manager가 자신의 페이스대로 개발할 수 있다
  • 기여자는 수정사항 반영을 기다릴 필요 없이 본인의 저장소에서 계속 작업할 수 있다
  • 관리자는 여유를 가지고 기여자가 요청한 사항을 검토할 수 있다.

---

3. Dictator and Lieutenants 워크플로

수백 명의 개발자가 참여하는 큰 프로젝트를 운영할 때 사용하는 방식이다.

대표적인 예시로 Linux 커널 프로젝트가 있다.

위에서 살펴본 Integration-Manager가 여러명 모인 것을 Lieutenants라고 한다.

 

사람들

• Benevolent Dictator(최종 관리자, 왕과 같다)
• Lieutenants(맡은 부분의 관리자, 장관과 같다)
• Developer(실제 개발자, 일꾼과 같다)

이 워크플로에선 모든 사람들이 각자의 레포지토리를 갖는다.

 

사용법

1. 개발자들은 코드를 수정한 뒤 공식 저장소의 master 브랜치 위로 rebase한다.
2. 개발자는 Lieutenant에게 Pull Request를 한다.
3. Lieutenant는 개발자의 원격 저장소를 remote로 등록하고, 수정사항을 fetch하고 merge한다음 테스트를 진행한다.
4. 문제가 없으면, 자신의 저장소에 push한다.
5. Lieutenant는 수정사항을 모아 Dictator에게 Pull Request를 한다. 
6. 테스트를 진행한 뒤 문제가 없으면 공식 저장소에 Push한다.

* 본 포스트는 ProGit(https://git-scm.com/book/en/v2)의 내용을 바탕으로 작성되었습니다.