developerWorks에 처음 로그인하면 developerWorks프로파일이 생성됩니다.귀하의 프로파일에서 동의하신 내용이 공개되지만 이 사항은 언제든지 변경 가능합니다. 귀하의 성명(숨김으로 체크되어 있어도 표시됩니다)과 디스플레이 이름은 게시한 컨텐츠나 사이트 엑세스시 표시됩니다.

모든 정보가 안전하게 전송되었습니다.

처음 developerWorks에 로그인할 때 프로파일이 작성되므로, 이를 위해 디스플레이 이름을 선택해야 합니다. 선택하신 디스플레이 이름은 developerWorks에 게시한 컨텐츠에 표시됩니다.

3글자 이상 31글자 이하의 길이로 사용 가능합니다. dW커뮤니티 내에서는 보안상 이메일주소를 제외한 다른 이름을 지정하셔야 합니다.

모든 정보가 안전하게 전송되었습니다.

My developerWorks：

나의 통지：

로그아웃

언어 선택：

분산 버전 제어 시스템 소개

Bazaar, Mercurial 및 Git의 사용 방법을 익히고 비교하기

Noah Gift , Production Engineer, Weta Digital

Noah Gift는 O'Reilly에서 출판한 "Python For UNIX and Linux System Administration"의 공동 저자이며 Manning을 위한 "Google App Engine In Action"에도 참여하고 있다. Gift는 저자, 연사, 컨설턴트 및 커뮤니티 리더로 IBM Developerworks, Red Hat Magazine, O'Reilly 및 MacTech에 글을 기고하고 있다. Gift가 운영하는 컨설팅 회사의 웹 사이트는 http://www.giftcs.com이며 http://noahgift.com에서 그가 쓴 많은 글을 찾아볼 수 있다. Noah의 Twitter에서도 그의 소식을 접할 수 있다.

그는 Cal State Los Angeles에서 CIS 석사 학위를 받았으며 Cal Poly San Luis Obispo에서 영양학 학사 학위를 받았다. Apple 및 LPI 인증 시스템 관리자이며 Caltech, Disney Feature Animation, Sony Imageworks 및 Turner Studios에서 근무했었다. 현재는 뉴질랜드의 Weta Digital에서 일하고 있다. 여가 시간에는 부인 Leah, 아들 Liam과 함께 시간을 보내거나 피아노 연주, 마라톤 달리기 및 종교적인 수양을 하면서 보낸다.

Adam Shand, Infrastructure Manager, Weta Digital

Adam은 뉴질랜드 최초의 ISP 중 하나를 설립한 90년대 초반부터 시스템 관리자 및 팀장으로 활동했다. 1997년에 미국으로 건너온 후 8년 동안 여러 닷컴 회사에서 시스템 관리자 및 팀장으로 근무했으며 그가 근무한 회사 중에는 세계 최대의 ISP 중 하나도 포함되어 있다. 2000년에 지역 공동체와 제휴하여 무료 무선 인터넷을 제공하는 비영리 단체를 설립했다. 가장 최근에는 고향인 뉴질랜드로 돌아와서 Peter Jackson의 시각 효과 회사인 Weta Digital에서 인프라 팀을 운용하고 있다.

요약： 분산 버전 제어에 관심이 있지만 도무지 감을 잡지 못해서 주저하고 있습니까? 이 기사에서는 사용할 수 있는 세 가지 기본 시스템(Git, Mercurial 및 Bazaar)을 소개하고 분산 워크플로우 채택 시 얻을 수 있는 몇 가지 장점을 살펴본 후 일반적인 작업과 서브버전을 비교하는 지침을 제공합니다.

여기에 태그 달기!

원문 게재일: 2009 년 4 월 07 일
번역 게재일: 2009 년 6 월 30 일
난이도: 중급
영어로: 보기
PDF: A4 and Letter (61KB | 10 pages)Get Adobe® Reader®
페이지뷰： 3010 회
의견：

소개

지난 수 년 동안 분산 버전 제어 시스템이 개발 프로세스에 제공할 수 있는 장점에 대한 수많은 논의가 있었다. 발전을 거듭해 온 분산 도구는 최근에 이르러 단점이 거의 없을 정도로 개선되었다. 초기에는 경쟁력이 높지 않았지만 사용자의 뜻에 따라 분산 도구에서 제공할 수 있는 유연성이 추가되면서 결국에는 충분한 경쟁력을 확보할 수 있게 되었다. 이 기사를 모두 읽고 나면 분산 버전 제어 시스템을 충분히 시작할 수 있으며 분산 모델의 장점에 대한 기본적인 이해도 갖출 수 있다.

분산 버전 제어와 관련된 대부분의 논의는 중앙 집중식 서버가 더 이상 필요하지 않게 되었다는 점에 중점을 두고 있다. 일부 개발자 그룹에게는 필수적인 기능으로 인식될 정도로 우수한 기능으로 자리 잡은 분산 버전 제어의 진정한 가치는 개발자 그룹이 스스로 선택한 거의 모든 워크플로우를 구현할 수 있다는 것이다. 기존의 중앙 집중식 모델에서 수행하던 작업을 두 명의 개발자가 로컬 무선 연결만 제공되는 카페에 모여서 함께 수행할 수 있다.

새롭고 다양한 방식으로 작업할 수 있다는 이러한 가능성은 분산 버전 제어의 진정한 매력을 대변한다. 실제로 이 기사의 끝에서는 이 애드혹 커피숍의 워크플로우를 정확하게 구현하는 방법을 설명한다. 작가, 교사 또는 하드코어 Linux® 커널 개발자의 경우 이 워크플로우를 효과적으로 활용할 수 있다.

분산 버전 제어란?

DVCS(Distributed Version Control System)는 파일의 버전을 관리하는 방법으로 중앙 집중식 서버가 없어도 되지만 필요한 경우 사용할 수도 있다. 변경 사항을 DVCS의 다른 사용자에게 병합할 수 있기 때문에 매우 유연한 워크플로우를 구성할 수 있다.

DVCS는 기존의 중앙 집중식 워크플로우뿐만 아니라 보안이 강화된 워크플로우까지도 활용할 수 있기 때문에 중앙 집중식 버전 제어에 비해 유연성이 뛰어나다는 장점과 더불어 매우 빠르다는 장점도 가지고 있다. 대부분의 작업이 클라이언트에서 로컬로 실행되기 때문에 네트워크 작업이 필요하지 않으므로 중앙 집중식 서버에 비해 훨씬 빠르게 작업을 처리할 수 있다.

후크란?

후크는 버전 제어 작업을 수행하는 동안 프로그래밍 방식으로 조치를 취하는 방법이다. 후크를 사용하면 코드가 저장소에 체크인될 때 이메일을 자동으로 보낼 수 있다. 또는 코드를 체크인하기 전에 사용자가 테스트 파일을 포함하는 등의 요구 사항을 충족했는지 여부를 확인할 수도 있다.

플러그인을 작성하는 방법을 통해서도 버전 제어 시스템의 기능을 확장할 수 있다. 고유한 플러그인을 작성하는 방법이 궁금한 경우 참고자료 섹션에서 제공하는 링크를 통해 Bazaar, Git 및 Mercurial용 플러그인 시스템을 설명하는 기사를 볼 수 있다.

DVCS와 중앙 집중식 버전 제어 시스템의 주요 차이점

DVCS와 중앙 집중식 버전 제어 시스템 사이에는 세 가지 주요 차이점이 있다. 첫 번째 차이점은 DVCS의 핵심적인 작동 방식인 로컬 커미트를 통한 오프라인 작업이다. 이는 중앙 집중식 서버와의 연결을 통해 모든 작업이 발생해야 하는 중앙 집중식 버전 제어와는 근본적으로 다른 방식이다. 이 유연성으로 인해 개발자는 사무실에서 업무를 보는 것과 마찬가지로 손쉽게 비행기 안에서 작업을 수행하고 커미트 후 커미트를 수행할 수 있다.

두 번째 차이점은 DVCS가 중앙 집중식 시스템에 비해 더 유연하다는 것이다. 즉, DVCS의 경우에는 기존의 중앙 집중식 워크플로우, 순수 애드혹 및 애드혹과 중앙 집중식을 혼합한 방식의 워크플로우를 포함한 다양한 유형의 워크플로우가 가능하다. 따라서 이메일, 피어 투 피어 및 개발 팀에서 생각할 수 있는 모든 방법을 통해 개발 작업을 수행할 수 있다.

세 번째 차이점은 DVCS가 중앙 집중식 버전 제어 시스템에 대해 훨씬 빠르다는 것이다. 왜냐하면 DVCS에서는 대부분의 작업이 클라이언트에서 매우 빠르게 수행되기 때문이다. 또한 push(다른 노드와의 통신)가 필요한 경우에도 두 클라이언트 모두에 전체 메타데이터가 있기 때문에 빠르게 작업을 처리할 수 있다. 이 속도 차이는 상당한 격차를 보여 주며 로컬 저장소 또는 네트워크 저장소인지 여부에 따라 DVCS가 서브버전보다 대략 3배에서 10배 정도 빠른 속도를 제공할 수 있다.

위로

분산 버전 제어 워크플로우

DVCS는 매우 유연하기 때문에 다양한 유형의 워크플로우가 가능하지만 이 기사에서는 두 가지 워크플로우에 대해서만 설명한다. 첫 번째 가장 일반적인 워크플로우는 Partner 워크플로우이다. Partner 워크플로우를 사용하는 개발자는 프로젝트를 시작한 다음 분기를 만든다. 그런 다음 변경 사항이 발생할 때마다 변경 사항을 다른 개발자가 작업 중인 분기와 병합한다.

두 번째 일반적인 워크플로우는 중앙 집중식 서버와 로컬 커미트를 사용하는 것이다. 이 워크플로우는 로컬에서 커미트한 후 최종 변경 사항을 중앙 집중식 서버에 병합한다는 점을 제외하면 중앙 집중식 서브버전 저장소를 사용하는 것과 매우 비슷하다. 이 워크플로우의 경우에는 이 워크플로우와 Partner 워크플로우를 혼합한 형식의 워크플로우를 비롯한 여러 가지 변형이 있다. 여기에서 중요한 점은 DVCS를 사용하면 여러 가지 방식 중에서 자신에게 가장 적합한 작업 방식을 선택할 수 있다는 것이다.

위로

간단한 실행 방법

새로운 기술을 실제로 이해하는 가장 좋은 방법은 직접 사용해 보는 것이다. 이 섹션에서는 Mercurial, Bazaar 및 Git의 일반적인 작업을 실행해 볼 수 있다.

Mercurial
- 설치: sudo easy_install-2.5 mercurial
- 프로젝트 디렉토리 작성: mkdir hgrepo; cd hgrepo
- 프로젝트 초기화: hg init
- 파일 추가: touch foo.txt; hg add foo.txt
- 커미트: hg commit -m "added foo.txt" commit
- 공유 저장소 가져오기: hg clone ssh://example.com//projects/hgrepo
- 로컬 변경 사항 커미트: hg -ci -m "adding a change"
- 서버에 변경 사항 저장: hg push
- 보류 중인 업데이트를 패치로 보기: hg incoming -p
- 서버에서 업데이트 다운로드: hg pull
- 변경 사항 적용: hg update
- 충돌 병합: hg merge
- 관련이 없는 두 원격 저장소 병합: hg pull -f ssh://example2.com//projects/hgrepo
Bazaar
- 설치: sudo easy_install-2.5 bzr
- 프로젝트 디렉토리 작성: mkdir bzrrepo; cd bzrrepo
- 프로젝트 초기화: bzr init
- 파일 추가: touch foo.txt; bzr add foo.txt
- 커미트: bzr commit -m "added foo.txt" commit
- 공유 저장소 가져오기: bzr branch bzr+ssh://example.com/projects/gitrepo
- 로컬 변경 사항 커미트: bzr -ci -m "adding a change"
- 서버에 변경 사항 저장: bzr push
- 서버에서 업데이트 다운로드: bzr pull
- 변경 사항 적용: bzr update
- 충돌 병합: bzr merge
Git
- 설치: http://kernel.org/pub/software/scm/에서 최신 tar 파일 다운로드
- 프로젝트 디렉토리 작성: mkdir gitrepo; cd gitrepo
- 프로젝트 초기화: git init
- 파일 추가: touch foo.txt; git add foo.txt
- 커미트: git commit -m "added foo.txt" commit
- 공유 저장소 가져오기: git clone ssh://example.com/projects/bzrrepo
- 로컬 변경 사항 커미트: bzr -ci -m "adding a change" commit
- 서버에 변경 사항 저장: bzr push
- 서버에서 업데이트 다운로드: bzr pull
- 변경 사항 적용: bzr update
- 충돌 병합: bzr merge

위로

변환 도구 및 서브버전 통합

세 가지 DVCS 모두 기존 서브버전 저장소를 각 DVCS의 형식으로 쉽게 변환할 수 있으며 DVCS 간 변환도 가능하다. 따라서 모든 개발자가 DVCS를 쉽게 사용할 수 있으며 DVCS 간 이동도 자유롭다.

예를 들어, Mercurial에서는 hgimportsvn 및 hgpullsvn 도구를 사용하여 기존 서브버전 저장소와 통신하여 히스토리가 있는 새로운 hg 저장소를 만들 수 있다. 또 다른 도구인 tailor는 저장소와 저장소를 연결하는 범용 도구이다.

DVCS를 통합하여 기존 서브버전 저장소와 함께 사용하는 작업도 직접 경험해 볼 만한 흥미로운 작업이다. 이 작업에 대한 자세한 설명은 이 기사의 범위를 벗어나기 때문에 여기에서는 자세히 다루지 않지만 참고자료 섹션에 소개된 링크를 통해 단일 서브버전 분기와 Git, Bazaar 및 Mercurial 간의 양방향 작업을 지원하는 몇 가지 도구를 살펴볼 수 있다.

위로

써드파티 호스팅 옵션

중앙 집중식 "허브"를 호스트할 필요가 없거나 호스트하지 않으려는 오픈 소스 또는 기업 개발자의 경우 Git, Bazaar 또는 Mercurial을 통해 프로젝트를 호스트할 때 주로 사용하는 몇 가지 방법이 있다. Mercurial의 경우에는 잘 알려진 무료 및 유료 호스팅 사이트인 Bitbucket을 사용한다. Git의 경우에는 Github를 사용하며 Bazaar의 경우에는 Canonical에서 후원하고 있는 Launchpad를 사용한다.

위로

해커의 팁: "커피숍" Mercurial 워크플로우

그림 1. 커피숍 워크플로우

예를 들어, 두 사람이 커피숍의 무선 네트워크에 연결되어 있을 때 보안 애드혹 버전 제어 워크플로우를 사용하려는 경우 다음과 같은 작업을 수행할 수 있다.

첫 번째 사용자가 Mercurial을 사용하여 다음과 같이 저장소를 작성한다.

mkdir /tmp/myhgrepo
cd /tmp/myhgrepo
hg init

그런 다음 이 저장소를 읽기 전용 공유로 웹을 통해 공유한다.

hg serve

그런 다음 두 번째 사용자가 다음 명령을 사용하여 이 저장소를 복제한다.

hg clone http://example.com:8000

참고: 이는 다른 시스템의 IP 또는 로컬 호스트 이름이다. OS X의 경우 your-machine-name.local에서 Bonjour를 통해 사용할 수 있다.

그런 다음 두 번째 사용자가 필요한 사항을 변경한 후 자신의 저장소를 읽기 전용 HTTP 공유로 제공한다.

http://example.com:8000

이제 첫 번째 사용자가 자신의 저장소에 대한 두 번째 사용자의 복제본을 다시 복제해 온다.

hg clone http://example2.com:8000

이 워크플로우는 반복해서 진행될 수 있으며 각 개발자는 자신이 원할 때 상대의 저장소를 가져온 후 로컬 파일 시스템만을 업데이트하므로 안전하다. 이것이 바로 커피숍 워크플로우이다.

위로

결론

이 기사에서는 분산 버전 제어의 가치와 세 가지 주요 옵션인 Git, Mercurial 및 Bazaar 사이의 몇 가지 차이점에 대해 살펴보았다. 버전 제어를 처음 경험하는 개발자라면 실제 경험을 쌓아가면서 후크, 플러그인 및 그 장점에 대해서도 자세히 알아보기 바란다.

이미 익숙한 개발자라면 각 도구를 활용하여 장점을 최대한 살릴 수 있을 것이다. 참고자료 섹션의 링크를 통해 분산 버전 제어에 대한 구체적인 내용과 사용법에 대한 자세한 설명을 볼 수 있다.

참고자료

교육

DVCS 개요.
Tailor는 "범용" 버전 제어 마이그레이션 도구이다.
Mercurial에는 svn 간 변경 사항을 미러링하는 유틸리티가 있다.
Bazaar에는 svn의 마이그레이션을 수행하는 다양한 도구가 있다.
Git에는 한 쌍의 도구가 있으며 유명한 Git 호스팅 공급자인 github에 의해 자동으로 작업이 처리된다.
developerWorks의 AIX와 UNIX 영역에서는 AIX 시스템 관리의 모든 부분과 관련된 다양한 정보를 볼 수 있다.
오픈 소스: developerWorks 오픈 소스 영역에서 오픈 소스 기술을 활용하여 개발 작업을 수행하고 이러한 기술을 IBM 제품과 함께 사용하는 데 도움이 되는 사용법 정보, 도구 및 프로젝트 업데이트를 확인할 수 있다.
developerWorks 기술 행사 및 웹 캐스트: developerWorks 기술 행사 및 웹 캐스트를 통해 최신 정보를 얻을 수 있다.
팟캐스트: IBM 기술 전문가를 생생한 음성으로 만나보자.