[Git] 프로젝트를 진행할 때 깃허브(Github)를 쓰는 법
Git과 워크플로우
git이 무엇인지, 그리고 어떻게 레포지토리를 만들 수 있는지 등은 구글에 검색하면 굉장히 많다.
그러나 git을 협업에, 특히 프로젝트 진행할 때 어떻게 이용하는지에 대한 설명은 잘 없는 것 같다.
사실 분산 환경에서의 워크플로 등 git workflow 키워드로 검색하면 잘나오는데, 과거의 나는 이걸 잘 몰랐다…
progit에 대표적인 3가지 방법이 소개되어있는데, 이 글에서는 이걸 다뤄보려고 한다.
- 중앙집중식 워크플로
- Integration-Manager 워크플로
- Dictator and Lieutenants 워크플로
요약해서 결론을 말하자면,
혼자 내지는 친한 친구 몇 명과 비공개 프로젝트 할 때: 중앙집중식 워크플로
다른 사람들과 함께 비공개 프로젝트 할 때 : Integration-Manager 워크플로
다른 사람들과 함께 공개 프로젝트 할 때 : Dictator and Lieutenants 워크플로
정도로 생각하면 되겠다.
중앙집중식 워크플로
중앙집중형 버전 관리 시스템에서 사용하는 방식이다. 단, Git은 모든 자료를 모든 사람이 가지고 있기 때문에 서버가 아닌, 클라이언트 쪽에서 Merge한다.
가령 두 개발자 철수와 영희가 저장소를 공유한다고 할 때, 철수와 영희 둘다 로컬환경에서 저장소를 clone, 수정, 커밋할 것이다. 철수가 커밋한 내용을 먼저 서버에 push하면, 영희는 push하지 못한다. 그 전에 철수가 수정한 커밋을 fetch하고 merge해야한다. 토픽 브랜치를 만들어 수정하는 경우에도, 그 브랜치를 로컬의 master브랜치에 merge한 후 origin/master브랜치를 fetch하고 merge해야 push할 수 있다. 무조건 배포 브랜치인 master브랜치에 push한다고 보면 될 것 같다. 규모가 크지 않고 개발자의 수가 적은 프로젝트에 적합하다.
Integration-Manager 워크플로
각 팀마다 브랜치를 하나씩 만들고 Integration-Manager가 그 브랜치를 Pull해서 Merge하는 워크플로이다.
- 프로젝트의 Integration-Manager는 프로젝트 메인 저장소에 Push를 한다.
- 프로젝트 기여자는 메인 저장소를 Clone하고 수정한다.
- 기여자는 자신의 저장소에 Push하고 Integration-Manager가 접근할 수 있도록 공개한다.
- 기여자는 Integration-Manager에게 변경사항을 적용해 줄 것을 이메일로 요청한다.
- Integration-Manager는 기여자의 저장소를 리모트 저장소로 등록하고 수정사항을 Merge하여 테스트한다.
- Integration-Manager는 Merge한 사항을 메인 저장소에 Push한다.
가령 철수와 영희가 A라는 한 팀, 영희와 바둑이가 B라는 한 팀으로 일한다고 하면 각각의 팀은 featureA, featureB라는 브랜치를 각각 만들게 될 것이다. 영희가 저장소를 clone하고 featureA브랜치를 만들어 먼저 수정하고 커밋한다. 그러면 수정부분을 철수와 공유해야 하므로 featureA브랜치를 서버로 Push한 후, 철수에게 featureA브랜치를 확인하라고 메일을 보내야 한다. 그러는 동안, 바둑이가 featureB브랜치를 만들고 수정했다는 메일을 받았다. 영희는 서버로부터 fetch, merge해야 한다. 시간이 지난 후, featureA와 featureB 브랜치가 master 브랜치로 merge될 준비가 되었다. 그러면, Integration-manager에게 그 사실을 알려준다. Integration-manager는 각 브랜치를 검토하고 master브랜치에 통합할 것이다.
Dictator and Lieutenants 워크플로
아주 큰 프로젝트를 운영할 때, 여러 명의 Integration-Manager가 저장소에서 자신이 맡은 부분만을 담당하고 이 사람들을 Lieutenants라 한다. 모든 Lieutenants는 최종 관리자 아래에 있으며 그 최종관리자를 Benevolent Dictator라고 부른다. Benevolent Dictator가 각 Lieutenant의 저장소를 가져와 공식 저장소에 Push하고 모든 프로젝트 참여자는 이 공식 저장소를 Pull해야 한다.
- 개발자는 코드를 수정하고 master 브랜치를 기준으로 자신의 토픽 브랜치를 rebase한다. 여기서 master브랜치란 공식 저장소의 branch를 말한다.
- Lieutenant들은 개발자들의 수정사항을 자신이 관리하는 master 브랜치에 Merge한다.
- Dictator는 Lieutenant의 master 브랜치를 자신의 master 브랜치에 Merge한다.
- Dictator는 자신의 master 브랜치를 Push하며 다른 모든 개발자는 Dictator의 master 브랜치를 기준으로 Rebase한다.
공개 팀을 운영할 때는 모든 개발자가 프로젝트의 공유 저장소에 직접적으로 쓰기 권한을 가지지 않는다. Github의 경우, Fork를 지원하나 다른 방식으로는 이메일과 Patch를 사용하는 방식도 있다.
Github사이트의 해당 프로젝트 페이지로 가서 Fork버튼을 누르면 쓰기 권한이 있는 저장소가 하나 만들어질 것이다. 이 저장소를 원격저장소로 등록한 뒤 토픽 브랜치를 만들어 작업할 때마다 이 리모트 토픽 브랜치 자체에 바로 Push를 해야 한다. 이렇게 하면 관리자가 토픽 브랜치를 프로젝트에 포함시키고 싶지 않을 때 master브랜치를 이전으로 되돌리는 수고를 덜어줄 수 있다.
Fork한 저장소에 Push하고 준비가 되면 프로젝트 관리자에게 Pull Request해야 한다. Github에 pull request버튼을 누르거나 $git request-pull명령어를 사용하여 이메일을 수동으로 만들 수 있다.
Patch메일을 전송하는 방법도 있는데, $git format-patch [commit-id]하면 현재 커밋부터 아규먼트로 준 커밋까지의 내용을 patch파일로 만들어서 준다. Gmail을 사용하여 메일을 보내려면 먼저 ~/.gitconfig 파일에서 이메일 부분을 다음과 같이 설정한다.
[imap]
folder = "[Gmail]/Drafts"
host = imaps://imap.gmail.com
user = user@gmail.com
pass = [password]
port = 993
sslverify = false
이후 $cat *.patch |git imap-send해보면 정상적으로 동작할 것이다. gmail의 draft폴더로 가보면 메일원고가 있을 텐데 To부분을 메일링리스트의 주소로, CC부분에 관리자나 이 메일을 참고해야 하는 개발자의 메일 주소를 적고 실제로 전송하면 완료.
Gmail말고 SMTP 서버를 이용하여 Patch를 보낼 수 있다. 이 경우 ~/.gitconfig파일의 sendmail section을 고쳐야 한다.
[sendemail]
stmpencryption = tls
smtpserver = smtp.gmail.com
smtpuser = user@gmail.com
smtpserverport = 587 //아니면 456
이후 $git send-email *.patch하면 정상적으로 동작할 것이다.
댓글남기기