분산 환경에서의 Git-3 - 프로젝트에 기여하기 - 비공개 대규모 팀

비공개 대규모팀

이런 상황에는 보통 팀을 여러개로 나눈다. 그래서 각각의 작은 팀이 서로 어떻게 하나로 Merge하는지를 살펴본다.

1. John과 Jessica는 한 팀이고 프로젝트에서 어떤 한 부분을 담당한다.
2. 또한 Jessica와 Josie도 다른 부분을 담당하는 한 팀이다.
3. 이런 상황이라면 회사는 Integration-Manager Workflow를 선택하는게 좋다.
4. 작은 팀이 수행한 결과물은 Integration-Manager가 Merge하고 공유 저장소의 master 브랜치를 업데이트 한다.
5. 팀마다 브랜치를 하나씩 만들고 Integration-Manager는 그 브랜치를 Pull해서 Merge한다.

두 팀에 모두 속한 Jessica의 작업 순서를 살펴보자.

 

우선 Jessica는 저장소를 Clone하고 featureA 작업을 먼저한다. featureA 브랜치를 만들고 수정을 하고 커밋을 한다. 

$ git checkout -b featureA
$ vim lib/simplegit.rb
$ git commit -am 'add limit to log function'

 

이 수정한 부분을 John과 공유해야 한다. 공유하려면 featureA 브랜치를 서버로 Push한다. ( master 브랜치는 Push할 수없다.)

$ git push -u origin featureA
...
To jessica@githost:simplegit.git
 * [new branch]      featureA -> featureA

 

Jessica는 자신이 한 일을 featureA라는 브랜치로 Push했다는 메일을 John에게 보낸다. John의 피드백을 기다리는 동안 Josie와 함께 featureB 작업을 하기로한다.

 

Jessica는 서버의 master 브랜치를 기반으로 featureB 브랜치를 하나 만든다.

$ git fetch origin
$ git checkout -b featureB origin/master
Switched to a new branch 'featureB'

 

Jessica는 몇가지 작업을 하고 featureB 브랜치에 커밋한다.

$ vim lib/simplegit.rb
$ git commit -am 'made the ls-tree function recursive'
[featureB e5b0fdc] made the ls-tree function recursive
 1 files changed, 1 insertions(+), 1 deletions(-)
$ vim lib/simplegit.rb
$ git commit -am 'add ls-files'
[featureB 8512791] add ls-files
 1 files changed, 5 insertions(+), 0 deletions(-)

 

Jessica의 저장소는 다음과 같다.

 

Josie가 이미 일부 작업을 하고 서버에 featureBee 브랜치로 Push 했다는 이메일을 보내왔다.

 

Jessica는 Merge하기 위해서 우선 Fetch 한다.

$ git fetch origin
...
From jessica@githost:simplegit
 * [new branch]      featureBee -> origin/featureBee

 

Jessica는 Fetch 해온 브랜치를 Merge한다.

$ git merge origin/featureBee
Auto-merging lib/simplegit.rb
Merge made by the 'recursive' strategy.
 lib/simplegit.rb |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

 

Push하려고 하는데 작은 문제가 생겼다.

• Jessica는 featureB 브랜치에서 작업을 했는데 서버에는 브랜치가 featureBee라는 이름으로 되어 있다.
• git push 명령으로 Push할 때 로컬 브랜치 featureB 뒤에 콜론(:)과 함께 서버 브랜치의 이름을 직접 지정해 준다.

$ git push -u origin featureB:featureBee
...
To jessica@githost:simplegit.git
   fba9af8..cd685d1  featureB -> featureBee

 

John이 몇 가지 작업을 하고 나서 featureA에 Push했고 확인해 달라는 내용의 이메일을 보내왔다. 

 

Jessica는 John의 Push한 작업을 Fetch한다.

$ git fetch origin
...
From jessica@githost:simplegit
   3300904..aad881d  featureA   -> origin/featureA

 

어떤 것이 업데이트 됐는지 git log 명령으로 확인한다.

$ git log origin/featureA ^featureA
commit aad881d154acdaeb2b6b18ea0e827ed8a6d671e6
Author: John Smith <jsmith@example.com>
Date:   Fri May 29 19:57:33 2009 -0700

    changed log output to 30 from 25

 

Jessica는 로컬의 featureA 브랜치로 Merge한다.

$ git checkout featureA
Switched to branch 'featureA'
$ git merge origin/featureA
Updating 3300904..aad881d
Fast forward
 lib/simplegit.rb |   10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)

 

Jessica는 일부 수정 커밋, 수정한 내용을 다시 서버로 Push 한다.

$ git commit -am 'small tweak'
[featureA 774b3ed] small tweak
 1 files changed, 1 insertions(+), 1 deletions(-)
$ git push
...
To jessica@githost:simplegit.git
   3300904..774b3ed  featureA -> featureA

 

Jessica의 저장소는 위와 같은 작업을 마치고 나면 다음과 같다.

 

그럼 featureA 와 featureBee 브랜치가 프로젝트의 메인 브랜치로 Merge할 준비가 되었다고 Integration-Manager에게 알려준다.

 

Integration-Manager가 두 브랜치를 모두 Merge하고 난 후에 메인 브랜치를 Fetch하면 다음과 같은 모양이 된다.

 

 

 

수많은 팀의 작업을 동시에 진행하고 나중에 Merge하는 기능을 사용하려고 다른 버전 관리 시스템에서 Git으로 바꾸는 조직들이 많아지고 있다. 팀은 자신의 브랜치로 작업하지만, 메인 브랜치에 영향을 끼치지 않는다는 점이 Git의 장점이다. 

 

다음은 이런 Workflow를 나타내고 있다.