페이지

2013년 1월 19일 토요일

git

내가 여지껏 써본 revison control software(RCS) 는 소시적 MS SourceSafe , Rational ClearCase, Perforce, Git 등이 있다.

Clearse에서 Peforce로 처음 바꿨을때 그 속도에 감탄했었다.  Peforce가 빨랐다기 보다는 ClearCase가 너무나 느렸던 탓이다. 실제로 Perforce와 SVN의 속도를 비교해보면 p4가 더 빠르긴 하지만 큰 차이는 없는 것으로 알고 있다.

git을 반년정도 써오고 있는데 지금까지는 아주 basic한 workflow만 써오다가, 복수개의 remote 서버를 추가해서 로컬 브랜치로 만들고 각 브랜치 간의 머지 및 integration을 로컬에서 할 수 있음을 알고는 git의 강력함을 느꼈다.

시나리오를 만들어 보면

  • git remote 서버들
    • team의 master 서버인 origin
    • 오픈소스여서 대외적으로 공개될 git인 rsa
  • 로컬 브랜치들
    • develop : origin/develop
    • release : origin/release
    • rsa : rsa/master
  • workflows
    • dev 에 비교적 unstable한 코드들을 넣고  커미하고 자가 검증
    • integration을 하기 위해 최신 develop 브랜치 로 release로 overwrite하고 integration build를 만들어서 검증팀에 주고 디펙 수정
    • 각 마일스톤 별로 release criteria를 만족하면 rsa로 push
    • rsa에서 디펙 어싸인이 되면 rsa브랜치에 quick fix를 하고 develop 브랜치에 머지
    • release 디펙 어싸인되면 release브랜치에 quick fix를 하고 develop에 머지
위 workflow를 git이 아닌 p4로 한다고 생각하면 일이 생각보다 복잡해진다.
  1. 우선 develop/ release, rsa의 working copy를 만들어야 한다. 대부분의 코드는 같을 것이기 때문에 여기서 많은 하드 공간이 낭비된다. git은 같은 hash를 가지면 그것을 브랜치 간에 share하기 때문에 엄청난 효율을 가질 수 있다. perforce도 서버단에서는 같은 오브젝트임을 알지만 로컬에  N번의 working copy를 sync해야 하는 것은 어쩔 수 없는 비효율
  2. 1에서 만약 rsa가 물리적으로 다른 서버라면 서버단에서도 같은 오브젝트가 아닌 다른 오브젝트로 인식할 것이므로 또 비효율이 발생할 수 있다.
위 시나리오에서 브랜치가 더 늘어나고 remote더 늘어날 수록 개발자가 감당해야 하는 복잡함은 perforce쪽이 더 많아 진다. peforce 대신에 Centralized RCS 로 단어를 바꿔도 같은 뜻이 된다. 즉, Centralized계열의 한계라고 볼 수 있다.

게다가 훌륭한 code review툴인 gerrit까지 무료로 쓸 수 있지 않은가
RCS가 git으로 천하통일 될 수 밖에 없는 이유 되겠다.