분산 버전 관리를 사용하시나요?

Question

분산 버전 제어(분산 개정 제어, 분산 버전 제어라고도 함)를 사용하는 사람들의 의견과 이를 찾는 방법을 듣고 싶습니다.Mercurial, Darcs, Git, Bazaar 중 무엇을 사용하고 있나요?아직도 사용하고 있나요?과거에 클라이언트/서버 rcs를 사용해 본 적이 있다면 더 좋아졌나요, 나빠졌나요, 아니면 그냥 다르다고 생각하시나요?제가 시류에 편승하게 만들려면 무엇을 말해 주실 수 있나요?아니면 그 문제에 대해 뛰어 내리거나 부정적인 경험을 가진 사람들의 의견도 듣고 싶습니다.

저는 현재 이 질문의 원인이 되는 현재 소스 제어 시스템(Subversion)을 교체하려고 합니다.

나는 특히 컴퓨터가 동시에 켜지지 않고 연결이 매우 느린 다른 나라의 동료와 함께 이 기능을 사용하는 사람에게 관심이 있습니다.

분산 버전 제어가 무엇인지 확실하지 않은 경우 다음 몇 가지 기사를 참조하세요.

분산 버전 제어 소개

위키피디아 항목

Answer 1

저는 직장과 개인 프로젝트에서 Mercurial을 사용해 왔는데 정말 만족 스럽습니다. 내가 본 이점은 다음과 같습니다.

1. 로컬 버전 관리. 때때로 작업 중이며 버전 기록을 유지하고 싶지만 중앙 저장소로 푸시 할 준비가되지 않았습니다. 분산 VCS를 사용하면 준비가 될 때까지 분기없이 로컬 저장소에 커밋 할 수 있습니다. 이렇게하면 다른 사람들이 내가 필요로하는 변경을해도 여전히 가져 와서 내 코드에 통합 할 수 있습니다. 준비가되면 서버로 푸시합니다.
2. 병합 충돌이 적습니다. 이러한 문제는 계속 발생하지만 발생 빈도가 낮고 위험도 적습니다. 모든 코드가 내 로컬 저장소에 체크인 되었기 때문입니다. 언제든 백업하고 다시 할 수 있습니다.
3. 개별 저장소를 브랜치로. 동시에 실행중인 개발 벡터가 두 개있는 경우 저장소의 복제본을 여러 개 만들고 각 기능을 독립적으로 개발할 수 있습니다. 이렇게하면 무언가가 긁히거나 미끄러 져도 조각을 뽑을 필요가 없습니다. 그들이 갈 준비가되면 나는 그것들을 합치기 만하면됩니다.
4. 속도. Mercurial은 대부분의 일반적인 작업이 로컬이기 때문에 작업이 훨씬 더 빠릅니다.

   물론 다른 새로운 시스템과 마찬가지로 전환 중에도 약간의 고통이있었습니다. SVN을 사용할 때와는 다르게 버전 관리에 대해 생각해야하지만 전반적으로 그만한 가치가 있다고 생각합니다.

Answer 2

제가 일하는 곳에서 우리는 SVN에서 Bazaar로 이동하기로 결정했습니다 (git와 mercurial을 평가 한 후). Bazaar는 간단한 명령으로 시작하기 쉬웠습니다 (git이 가지고있는 140 개의 명령과는 다릅니다).

우리가 보는 이점은 기본 버전을 방해하지 않고 로컬 브랜치를 만들고 작업 할 수 있다는 것입니다. 또한 네트워크 액세스없이 작업 할 수 있으므로 diff를 수행하는 것이 더 빠릅니다.

제가 좋아하는 bzr의 한 명령은 shelve 확장입니다. 단일 파일에서 논리적으로 다른 두 개의 코드 조각에 대한 작업을 시작하고 한 조각 만 커밋하려는 경우 shelve 확장을 사용하여 문자 그대로 나중에 다른 변경 사항을 보류 할 수 있습니다. Git에서는 인덱스 (스테이징 영역)에서 놀면서 똑같이 할 수 있지만 bzr에는 더 나은 UI가 있습니다.

대부분의 사람들은 커밋과 푸시 (bzr ci + bzr push)를 위해 두 가지 명령을 입력해야하므로 이동을 꺼려했습니다. 또한 분기와 병합의 개념을 이해하기 어려웠습니다 (아무도 분기를 사용하거나 svn에서 병합하지 않습니다).

이 사실을 이해하면 개발자의 생산성이 향상됩니다. 모든 사람이 그것을 이해할 때까지 모든 사람 사이에 일관되지 않은 행동이있을 것입니다.

Answer 3

직장에서 약 2 개월 전에 CVS에서 Git으로 전환했습니다 (내 경험의 대부분은 Subversion에 대한 것입니다).분산 시스템에 익숙해지는 데 필요한 학습 곡선이 있었지만 Git은 작업 환경의 유연성과 병합이라는 두 가지 핵심 영역에서 우수하다는 것을 알게되었습니다.

전체 버전 관리 기능에 액세스하기 위해 VPN을 사용하거나 네트워크에 연결할 필요가 없습니다.즉, 내가 만든 거대한 커밋을 확인하거나 엉망이 될 때 되돌릴 수 없다는 것을 걱정할 필요없이 어디에서나 아이디어를 실험하거나 대규모 리팩토링을 수행 할 수 있습니다.

병합은 클라이언트 측에서 수행되기 때문에 서버 측 병합을 시작하는 것보다 훨씬 빠르고 오류가 발생하기 쉽습니다.

Answer 4

우리 회사는 현재 Subversion, CVS, Mercurial 및 git을 사용하고 있습니다.

5년 전 시작했을 때 CVS를 선택했고, 아직도 우리 부서의 주요 개발 및 릴리스 유지 관리 지점에서 CVS를 사용하고 있습니다.그러나 많은 개발자들은 CVS 브랜치의 어려움 없이(특히 이들을 병합하는) 개인 체크포인트를 확보하기 위한 방법으로 Mercurial을 개별적으로 사용하고 있으며 최대 5명 정도가 있는 일부 브랜치에서는 Mercurial을 사용하기 시작했습니다.다음 해에 마침내 CVS를 버릴 가능성이 높습니다.Mercurial의 사용은 유기적으로 증가했습니다.어떤 사람들은 CVS에 만족하기 때문에 아직까지 만지지도 않습니다.Mercurial을 사용해 본 모든 사람은 별다른 학습 곡선 없이도 결국 만족하게 되었습니다.

Mercurial을 통해 우리에게 정말 좋은 점은 우리의 (가정에서 만든) 연속 통합 서버가 개발자 Mercurial 저장소와 메인라인을 모니터링할 수 있다는 것입니다.따라서 사람들은 자신의 저장소에 커밋하고 지속적인 통합 서버를 통해 이를 확인한 다음 변경 세트를 게시합니다.우리는 많은 플랫폼을 지원하므로 적절한 수준의 수동 검사를 수행하는 것은 불가능합니다.또 다른 장점은 병합이 쉬운 경우가 많지만 어려울 때 병합을 잘 수행하는 데 필요한 정보를 얻을 수 있다는 것입니다.누군가 병합된 버전이 작동하게 되면 병합 변경 세트를 푸시할 수 있으며 그러면 다른 사람이 노력을 반복할 필요가 없습니다.

가장 큰 장애물은 개발자와 관리자의 두뇌를 다시 연결하여 단일 선형 분기 모델에서 벗어나야 한다는 것입니다.이에 대한 가장 좋은 약은 리누스 토발즈(Linus Torvalds)의 복용량입니다. 멍청하고 추악하다 중앙 집중식 SCM을 사용하는 경우.좋은 기록 시각화 도구가 도움이 되지만 아직 사용 가능한 도구에 만족하지 않습니다.

Mercurial과 CVS는 모두 Windows, Linux 및 Solaris를 혼합하여 사용하는 개발자에게 잘 작동하며 시간대에 문제가 없다는 것을 발견했습니다.(실제로 이것은 그리 어렵지 않습니다.내부적으로 epoch 초를 사용하면 모든 주요 SCM ​​시스템이 이를 올바르게 수행할 것으로 예상됩니다.

상당한 노력을 기울여 메인라인 CVS 기록을 Mercurial로 가져오는 것이 가능했습니다.사람들이 기록 마이그레이션 도구를 테스트하는 방법으로 메인라인 CVS 기록에 의도적으로 코너 케이스를 도입하지 않았다면 더 쉬웠을 것입니다.여기에는 일부 Mercurial 분기를 CVS 기록에 병합하는 작업이 포함되어 있어 프로젝트가 첫날부터 사용된 것처럼 보입니다.

우리 실리콘 디자인 그룹은 Subversion을 선택했습니다.그들은 주로 내 사무실에서 8개 시간대 떨어져 있으며 심지어 우리 사무실 사이의 상당히 좋은 전용 회선을 통해서도 SUbversion 체크아웃은 고통스럽기는 하지만 실행 가능합니다.중앙 집중식 시스템의 가장 큰 장점은 잠재적으로 큰 바이너리를 확인할 수 있다는 것입니다(예:벤더 릴리스) 모든 분산 저장소를 거대하게 만들지 않고.

Linux 커널 작업에는 git을 사용합니다.기본 Windows 버전이 완성되면 Git이 우리에게 더 적합할 것입니다. 하지만 Mercurial 디자인이 너무 단순하고 우아해서 우리는 이를 계속 사용할 것입니다.

Answer 5

분산 소스 제어를 직접 사용하지 않지만 다음과 같은 관련 질문과 답변을 통해 몇 가지 통찰력을 얻을 수 있습니다.

• 분산 소스 제어 옵션
• Git이 Subversion보다 나은 이유

Answer 6

저는 Mercurial 소스 제어 시스템을 개인적으로 사용합니다.지금까지 1 년 이상 사용하고 있습니다.실제로 VSC에 대한 첫 경험이었습니다.

Git을 사용해 보았지만 내가 필요로하는 것보다 너무 많다는 것을 알았 기 때문에 실제로 밀어 넣지 않았습니다.Mercurial은 많은 명령을 공유하기 때문에 Subversion 사용자 인 경우 쉽게 선택할 수 있습니다.또한 내 저장소 관리가 정말 쉽습니다.

내 코드를 사람들과 공유하는 두 가지 방법이 있습니다.

• 동료와 서버를 공유하고 프로젝트의 기본 저장소를 유지합니다.
• 내가 작업하는 일부 OSS 프로젝트의 경우 Mercurial (hg 내보내기)을 사용하여 작업 패치를 만들고 프로젝트의 관리자가이를 저장소 (hg 가져 오기)에 적용합니다.

  작업하기는 정말 쉽지만 매우 강력합니다.하지만 일반적으로 VSC를 선택하는 것은 프로젝트의 필요에 따라 달라집니다 ...

Answer 7

임베디드 시스템 개발을 위해 Sun 워크 스테이션을 끄기 전에는 Sun의 TeamWare 솔루션. TeamWare는 SCCS를 로컬 리포지토리 파일 개정 시스템으로 사용하는 완전 배포 솔루션으로, 병합 작업 (지점 이름 변경을 통해 수행됨)을 처리하는 도구 세트를 사용하여 여러 개의 중앙 리포지토리로 다시 래퍼합니다. 실제로 배포되기 때문에 실제로 마스터 리포지토리 자체가 없으며 (원하는 경우 규칙에 따라 제외) 모든 사용자는 전체 소스 트리 및 개정판의 자체 복사본을 가지고 있습니다. "복구"작업 중에 3-way diff를 사용하는 병합 도구는 알고리즘 적으로 무엇이 무엇인지 분류하고 시간이 지남에 따라 축적 된 여러 개발자의 변경 사항을 결합 할 수 있습니다.

개발 플랫폼 용 Windows로 전환 한 후 AccuRev 로 전환했습니다. AccuRev는 중앙 집중식 서버에 의존하기 때문에 실제로는 분산 솔루션이 아니지만 논리적으로 워크 플로 모델에서 매우 가깝습니다. TeamWare가 모든 파일의 모든 수정본을 포함하여 각 클라이언트의 모든 사본을 완전히 분리했을 경우 AccuRev 하에서 이것은 중앙 데이터베이스에서 유지되며 로컬 클라이언트 컴퓨터에는 로컬 편집을위한 현재 버전의 플랫 파일 만 있습니다. 그러나 이러한 로컬 복사본은 서버에 대한 클라이언트 연결을 통해 버전을 지정할 수 있으며 다른 개발자가 암시 적으로 만든 다른 변경 (예 : 브랜치)과 완전히 별도로 추적 할 수 있습니다.

개인적으로는 TeamWare에서 구현 한 분산 모델이나 AccuRev에서 구현 한 일종의 하이브리드 모델이 완전 중앙 집중식 솔루션보다 우수하다고 생각합니다. 그 주된 이유는 파일을 체크 아웃하거나 다른 사용자가 파일을 잠근다는 개념이 없기 때문입니다. 또한 사용자는 분기를 만들거나 정의 할 필요가 없습니다. 도구는이를 암시 적으로 수행합니다. 소스 파일 세트에 기여하거나 유지하는 더 큰 팀이나 다른 팀이있는 경우 "도구 생성"잠금 관련 충돌을 해결하고 궁극적으로 변경을 조정해야하는 개발자 수준에서 코드 변경을 더 잘 조정할 수 있습니다. 어떤 의미에서 분산 모델은 중앙 집중식 모델에 의해 제정 된 코스 그레인 잠금보다 훨씬 더 세밀한 "잠금"을 허용합니다.

Answer 8

대규모 프로젝트 (GHC)와 많은 소규모 프로젝트에서 darcs를 사용했습니다. 나는 darcs와 사랑 / 증오 관계가 있습니다.

장점 : 저장소 설정이 매우 간편합니다. 저장소간에 변경 사항을 이동하기가 매우 쉽습니다. 별도의 저장소에서 복제하고 '분기'를 시도하기가 매우 쉽습니다. 일관된 소규모 그룹에서 의미있는 '커밋'을 만들기가 매우 쉽습니다. 파일과 식별자의 이름을 매우 쉽게 바꿀 수 있습니다.

사소 : 역사에 대한 개념은 없습니다. '8 월 5 일의 상황'을 복구 할 수 없습니다. 이전 버전으로 돌아 가기 위해 darcs를 사용하는 방법을 알아 낸 적이 없습니다.

딜 브레이커 : darcs는 확장되지 않습니다. 저와 다른 많은 사람들이 darcs를 사용하여 GHC에 큰 문제를 겪었습니다. 9 일 동안 100 % CPU 사용으로 중단했습니다. 3 개월치 변경. 지난 여름에 2 주를 잃은 나쁜 경험을했습니다 darcs 기능을 만들려고 노력했고 결국 모든 변경 사항을 깨끗한 저장소에 직접 재생했습니다.

결론 : darcs는 취미 프로젝트를 위해 자신을 쏘지 않도록 간단하고 가벼운 방법을 원할 때 좋습니다. 그러나 darcs 2에서 해결 된 일부 성능 문제에도 불구하고 여전히 산업적 강점에는 적합하지 않습니다. 나는 자랑스러운 '패치 이론'이 몇 가지 방정식과 멋진 그림보다 조금 더 많은 것이 될 때까지 darcs를 정말로 믿지 않을 것입니다. 참조 된 장소에서 발표 된 실제 이론을보고 싶습니다. 시간이 지났습니다.

Answer 9

저는 특히 GitHub에서 Git을 정말 좋아합니다.로컬에서 커밋하고 롤백 할 수 있다는 것이 정말 좋습니다.체리 피킹 병합은 사소하지는 않지만별로 어렵지 않으며 Svn 또는 CVS가 할 수있는 것보다 훨씬 더 발전했습니다.

Answer 10

우리 그룹은 Git을 사용하고 있으며 세상의 모든 차이가있었습니다. 우리는 SCCS와 csh 스크립트 더미를 사용하여 코드를 공유하는 매우 크고 복잡한 프로젝트를 관리했습니다 (어쨌든 시도).

Git을 사용하면 하위 모듈 지원으로 이러한 작업을 쉽게 수행 할 수 있으며 최소한의 스크립팅 만 있으면됩니다. 우리의 릴리스 엔지니어링 노력은 계속 줄어 들었습니다. 브랜치는 유지 관리 및 추적이 쉽기 때문입니다. 저렴하게 분기하고 병합 할 수 있기 때문에 여러 프로젝트 (계약)에 걸쳐 단일 소스 컬렉션을 유지하는 것이 합리적으로 쉬워졌지만 이전에는 일반적인 흐름에 대한 모든 중단이 매우 비용이 많이 들었습니다. 또한 Git의 스크립팅 가능성이 엄청난 플러스라는 것을 발견했습니다. 후크 또는 . git-sh-setup를 수행하는 스크립트를 통해 동작을 사용자 정의 할 수 있고 이전과 같이 kludges 더미처럼 보이지 않기 때문입니다. .

때때로 네트워크에 연결되지 않은 분산 된 사이트 (이 경우 연결이 끊긴 보안 랩)에서 버전 제어를 유지해야하는 상황이 있으며 Git에는이를 매우 원활하게 처리하는 메커니즘 (번들, 기본 클론)이 있습니다. 메커니즘, 포맷 된 패치 등).

이 중 일부는 우리가 80 년대 초반을 벗어나 최신 버전 제어 메커니즘을 채택한 것입니다.하지만 Git은 대부분의 영역에서 "올바른 작업"을 수행했습니다.

원하는 답변의 범위는 확실하지 않지만 Git에 대한 우리의 경험은 매우 긍정적이었습니다.

Answer 11

중규모 팀과의 다양한 연결을 통해 SourceForge 및 기타 서버와 함께 Subversion을 사용하고 있으며 매우 잘 작동합니다.

Answer 12

저는 여러 가지 이유로 중앙 집중식 소스 제어의 큰 지지자이지만 프로젝트에서 BitKeeper를 잠시 사용해 보았습니다.아마도 몇 년 동안 하나의 형식 (Perforce, Subversion, CVS)으로 중앙 집중식 모델을 사용한 후 분산 소스 제어를 사용하기가 어려웠습니다.

저는 우리의 도구가 실제 작업을 방해해서는 안된다는 생각을 갖고 있습니다.작업을 더 쉽게 만들어야합니다.그래서 머리가 두근 거리는 경험을 몇 번하고 난 후 보석을 냈습니다.모델이 SCM 세계에서 대부분의 개발자에게 익숙한 모델과 매우 다르기 때문에 보트를 흔들기 전에 팀과 함께 정말 강건한 테스트를 수행하는 것이 좋습니다.

Answer 13

저는 잠시 동안 바자 를 사용해 왔고 정말 좋아합니다. 사소한 분기 및 다시 병합은 사용되어야하는 분기 사용에 큰 자신감을줍니다. (중앙 vcs 도구가이를 허용해야한다는 것을 알고 있지만 Subversion을 포함한 일반적인 도구는이를 쉽게 허용하지 않습니다.)

bzr은 중앙 저장소로 작업하여 완전 분산에 이르기까지 솔로에서 매우 다양한 워크 플로 를 지원합니다. . 각 분기 (개발자 또는 기능 용)를 독립적으로 병합 할 수 있으므로 분기별로 코드 검토를 수행 할 수 있습니다.

bzr에는 훌륭한 플러그인 ( bzr-svn )도 있습니다. Subversion 저장소. svn 리포지토리의 복사본을 만들 수 있습니다 (처음에는 로컬 리포지토리에 대한 전체 기록을 가져 오는 데 시간이 걸립니다). 그런 다음 다른 기능에 대한 분기를 만들 수 있습니다. 기능의 절반을 통과하는 동안 트렁크를 빠르게 수정하려면 추가 분기를 만들고 그 안에서 작업 한 다음 다시 트렁크에 병합하여 절반이 완료된 기능을 그대로두고 트렁크 외부에 둡니다. 훌륭한. Subversion에 대한 작업은 지금까지 나의 주요 용도였습니다.

참고 저는 Linux에서만 사용했으며 대부분 명령 줄에서 사용했지만 다른 플랫폼에서도 잘 작동하도록 설계되었지만 TortoiseBZR 및 IDE와의 통합에 대해 많은 작업이 수행되고 있습니다. 등

Answer 14

저는 집 프로젝트를 위해 Mercurial을 사용하고 있습니다.지금까지 제가 좋아하는 점은 여러 저장소를 가질 수 있다는 것입니다.랩톱을 기내로 가져가도 집에서 CVS를 실행할 때와 달리 버전 관리 기능이 있습니다.분기는 hg clone와 클론 작업만큼 쉽습니다.

Answer 15

<인용구>

Subversion 사용

Subversion은 배포되지 않기 때문에 사람들이 내가 무슨 말을하는지 잘 모르겠다면 위키피디아 링크가 필요하다고 생각합니다. :)

Answer 16

darcs 2.1.0을 사용했으며 내 프로젝트에 적합합니다.사용하기 쉬운.체리 따기 변경을 좋아합니다.

Answer 17

저는 직장에서 동료 중 한 명과 함께 Git을 사용합니다.하지만 메인 저장소는 SVN입니다.우리는 종종 워크 스테이션을 전환해야하며 Git을 사용하면 다른 컴퓨터의 로컬 저장소에서 변경 사항을 가져 오기가 매우 쉽습니다.동일한 기능에 대해 팀으로 작업 할 때 작업 병합이 수월합니다.

git-svn 브리지는 SVN에 체크인 할 때 git-svn-id 주석을 추가하기 위해 모든 커밋을 다시 작성하기 때문에 약간 불안정합니다.이것은 내 동료의 저장소와 광산 사이의 좋은 병합 기록을 파괴합니다.모든 팀원이 Git을 사용한다면 중앙 저장소를 전혀 사용하지 않을 것입니다.

개발하는 OS를 말하지 않았지만 Git은 모든 기능을 얻기 위해 명령 줄을 사용해야한다는 단점이 있습니다.Gitk는 병합 히스토리를 시각화하는 데 유용한 GUI이지만 병합 자체는 수동으로 수행해야합니다.Git-Gui 및 Visual Studio 플러그인은 아직 다듬어지지 않았습니다.

Answer 18

다중 사이트 및 연결이 끊긴 시나리오 모두에 분산 버전 제어 ( Plastic SCM )를 사용합니다.

1- 다중 사이트 : 멀리있는 그룹이있는 경우 인터넷 연결에 의존 할 수 없거나 충분히 빠르지 않아 개발자 속도가 느려질 수 있습니다. 그런 다음 다시 동기화 할 수있는 독립 서버 (플라스틱은 분기를 앞뒤로 복제 함)를 갖는 것이 매우 유용하고 작업 속도를 높입니다. 대부분의 회사는 각 개발자가 자체적으로 복제 된 저장소를 가지고있는 "완전히 분산 된"관행에 관심이 있기 때문에 회사에서 가장 일반적인 시나리오 중 하나 일 것입니다.

2- 연결 해제 됨 (또는 원하는 경우 진정으로 배포 됨) : 모든 개발자는 동료 또는 중앙 위치와 앞뒤로 복제되는 자체 저장소를 가지고 있습니다. 고객의 위치로 이동하거나 랩톱을 가지고 집으로 돌아가서 원격 "중앙"에 액세스하지 않고도 지점 전환, 체크 아웃 및 체크인 코드, 기록보기, 주석 실행 등을 계속할 수있는 것이 매우 편리합니다. 섬기는 사람. 그런 다음 사무실로 돌아갈 때마다 몇 번의 클릭만으로 변경 사항 (일반적으로 분기)을 다시 복제 할 수 있습니다.