분산 환경에서의 Git-1 - 분산 환경에서의 Workflow

분산 환경에서의 Workflow

중앙집중식 Workflow

중앙 저장소는 딱 하나 있고 변경사항은 모두 이 중앙 저장소에 집중된다. 

팀이 작거나 이미 중양 집중식 에 적응한 상황이라면 이 Workflow에 따라 Git을 도입하여 사용할 수 잇다.

1. 중앙 저장소를 하나 만들고 개발자 모두에게 Push권한을 부여한다. 
2. 모두에게 Push 권한을 부여해도 Git은 한 개발자가 다른 개발자의 작업을 덮어 쓰도록 허용하지 않는다.
3. 한 개발자가 Clocne 하고 나서 수정하는 사이에 이미 다른 개발자가 중앙 저장소에 무언가 Push했다면 이 개발자는 Push 할 수 없다.
4. Git은 Fetch하고 Merge해야 서버로 Push할 수 있다고 알려준다.

 

Integration-Manger Workflow

Git을 사용하면 리모트 저장소를 여러 개 운영할 수 있는데, 이 workflow는 이 부분을 활용한다.

이 Workflow에는 다음과 같은 특징이 있다.

• 소스를 통합하는 프로젝트 메인 저장소가 있다.
• 기여자(개발자) : 프로젝트 메인 저장소를 fork하여 자신만의 저장소를 만들어 실제 소스를 수정(기여)한다.
• Integration-Manager : 기여자들의 리모트 저장소의 소스를 선별 취합하여 프로젝트 메인 저장소에 Push한다.
• 프로젝트 메인 저장소는 Integration-Manager 에게는 읽기쓰기 권한, 기여자에게는 읽기 권한이 부여된다.

이러한 Workflow는 다음과 같이 진행된다.

1. 프로젝트 Integration-Manager는 프로젝트 메인 저장소에 Push를 한다.
2. 프로젝트 기여자는 메인 저장소를 Clone(fork)하고 수정한다.
3. 기여자는 자신의 저장소에 Push하고 Integration-Manager가 접근할 수 있도록 공개해 놓는다.
4. 기여자는 Integration-Manager에게 이메일 같은 것으로 변경사항을 적용해 달라고 요청한다.
5. Integration-Manager는 기여자의 장소를 리모트 저장소로 등록하고 수정사항을 Merge하여 테스트 한다.
6. Integration-Manager는 Merge한 사항을 메인 저장소에 Push한다.

 

이 방식은 GitHub 같은 사이트에서 주로 사용하는 방식이다. GitHub는 프로젝트를 Fork하고 수정사항을 반영하여 다시 모두에게 공개하기 좋은 구조로 되어 있다. 이 방식의 장점은 기여자와 Integration-Manager가 각자의 사정에 맞춰 프로젝트를 유지할 수 있다는 점이다. 기여자는 자신의 저장소와 브랜치에서 수정 작업을 계속해 나갈 수 있고 수정사항이 프로젝트에 반영되도록 기다릴 필요가 없다. Integration-Manager는 여유를 가지고 기여자가 Push해 놓은 커밋을 적절한 시점에 Merge한다.

Dictor and Lieutenants Workflow

보통 수백 명의 개발자가 참여하는 아주 큰 프로젝트를 운영할 때 이 방식을 사용한다. 리눅스 커널 프로젝트가 대표적이다. 

다음과 같은 참여자가 있다.

• Lieutenants(중위) : 여러 명의 Integration-Manager가 저장소에서 자신이 맡은 부분만을 담당한다.
• Dictator(독재자) : Lieutenants를 관리 하는 최종 관리자이다.
• 기여자(개발자) : 소스수정에 참여한다.

이러한 Workflow는 다음과 같이 진행된다.

1. 개발자는 코드를 수정하고 master 브랜치를 기준으로 자신의 토픽 브랜치를 Rebase한다. 여기서 master의 브랜치란 Dictator의 브랜치를 말한다.
2. Lieutenant 들은 개발자들의 수정사항을 자신이 관리하는 master 브랜치에 Merge한다.
3. Dictator는 Lieutenant의 master 브랜치를 자신의 master 브랜치로 Merge한다.
4. Dictator는 Merge한 자신의 master 브랜치를 Push하여 다른 모든 개발자가 Rebase할 수 있는 기준으로 만든다.

 

 

이 방식이 일반적이지는 않지만 깊은 계층구조를 가지는 환경이나 규모가 큰 프로젝트에서는 매우 쓸모 있다. 프로젝트 리더가 모든 코드를 통하기 전에 코드를 부분부분 통합하도록 여러 명의 Lieutenant에게 위임한다 

워크플로 요약

  이 세 가지 워크플로가 Git 같은 분산 버전 관리 시스템에서 주로 사용하는 것들이다. 사실 이런 워크플로뿐만 아니라 다양한 변종 워크플로가 실제로 사용된다. 어떤 방식을 선택하고 혹은 조합해야 하는 지 살짝 감이 잡힐 것이다. 앞으로 몇 가지 구체적 사례를 들고 우리가 다양한 환경에서 각 역할을 어떻게 수행하는지 살펴본다. 이어지는 내용에서 프로젝트에 참여하고 기여할 때 작업 패턴이 어떠한지 몇 가지 살펴보기로 한다.

프로젝트에 기여하기

기여하는 방식에 영향을 끼치는 변수가 몇가지 있다.

• 활발히 활동하는 개발자의 수
• 프로젝트에서 선택한 저장소 운영방식
• 접근권한

이런 변수에 따라서 프로젝트에 기여하는 방법과 Workflow 등이 달라지게 된다. 간단한 것부터 복잡한 것까지 각 상황을 살펴보면 실제 프로젝트에 필요한 방식을 선택할 수 있게 된다.

커밋 가이드라인

공백문자를 깨끗하게 정리하고 커밋해야 한다.

 

git diff -check : 잘못 사용한 공백을 다음과 같이 확인할 수 있다.

 

최대한 수정사항을 하나의 주제로 요약할 수 있어야 하고, 최대한 수정사항을 하나의 주제로 요약할 수 있어야 하고, 여러 가지 이슈에 대한 수정사항을 하나의 커밋에 담지 않아야 한다.

 

• 여러가지 이슈를 한꺼번에 수정했다 하더라도 Staging Area를 이용하여 한 커밋에 하나의 이슈만 담기도록 한다. 
• 작업내용을 분할하고 각 커밋마다 적절한 메시지를 작성한다. 
• 같은 파일의 다른 부분을 수정하는 경우에는 git add -patch 명령을 써서 한 부분씩 나누어 Stating Area에 저장해야 한다.

결과적으로 최종 프로젝트의 모습은 한번에 커밋을 하든 다섯 번에 나누어 커밋을 하든 똑같다. 하지만, 여러번 나누어 커밋하는 것이 좋다. 다른 동료가 수정한 부분을 확인할 때나 각 커밋의 시점으로 복원해서 검토할 때 이해하기 훨씬 쉽다. 나중에 이미 저장된 커밋을 다시 수정하거나 파일을 단계적으로 Staging Area에 저장하는 방법을 살펴본다. 다양한 도구를 이용해서 간단하고 이해하기 쉬운 커밋을 쌓아가야한다. 

 

좋은 커밋 메시지를 작성하는 습관은 Git을 사용하는데 도움이 된다.

 

커밋 메시지를 작성할 때 사용하는 규칙

1. 메시지의 첫 줄에 50자가 넘지 않는 아주 간략한 메시지를 작성한다.
2. 첫 줄 다음에 한줄은 비우고 그 다음에 커밋을 자세히 설명한다. 
3. 현재형 표현을 사용한다. 
   • I added tests for --> Add tests for

아래 내용은Tim Pope가 작성한 커밋 메시지의 템플릿이다.

영문 50글자 이하의 간략한 수정 요약

자세한 설명. 영문 72글자 이상이 되면
라인 바꿈을 하고 이어지는 내용을 작성한다.
특정 상황에서는 첫 번째 라인이 이메일
메시지의 제목이 되고 나머지는 메일
내용이 된다. 빈 라인은 본문과 요약을
구별해주기에 중요하다(본문 전체를 생략하지 않는 한).

이어지는 내용도 한 라인 띄우고 쓴다.

  - 목록 표시도 사용할 수 있다.

  - 보통 '-' 나 '*' 표시를 사용해서 목록을 표현하고
    표시 앞에 공백 하나, 각 목록 사이에는 빈 라인
    하나를 넣는데, 이건 상황에 따라 다르다.

 

메시지를 이렇게 작성하면 함께 일하는 사람은 물론이고 자신에게도 매우 유용하다. Git 개발 프로젝트에는 잘 쓰인 커밋 메시지가 많으므로 프로젝트를 내려받아서 git log --no-merges 명령으로 꼭 살펴보기를 권한다.