Git, Mercurial 및 Bazaar의 상대적인 강점과 약점은 무엇입니까?[닫은]
https://stackoverflow.com/questions/77485
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
여기 사람들은 Git, Mercurial 및 Bazaar의 상대적인 강점과 약점이 무엇이라고 생각합니까?
SVN 및 Perforce와 같은 버전 제어 시스템에 대해 각각을 고려할 때 어떤 문제를 고려해야 합니까?
SVN에서 이러한 분산 버전 제어 시스템 중 하나로 마이그레이션을 계획할 때 어떤 요소를 고려해야 합니까?
해결책
Git은 매우 빠르고 확장성이 뛰어나며 개념이 매우 투명합니다.이것의 단점은 상대적으로 가파른 학습 곡선을 가지고 있다는 것입니다.Win32 포트를 사용할 수 있지만 일류 시민은 아닙니다.Git은 해시를 사용자에게 버전 번호로 노출합니다.이는 단일 해시가 항상 정확히 동일한 콘텐츠를 참조한다는 점에서 보장을 제공합니다.공격자는 탐지되지 않고 기록을 수정할 수 없지만 사용자에게는 번거로울 수 있습니다.Git에는 파일 내용이 파일 간에 이동하는 경우에도 파일 내용을 추적하고 파일을 첫 번째 수준 객체로 보지만 디렉터리는 추적하지 않는 독특한 개념이 있습니다.git의 또 다른 문제는 작업이 많다는 것입니다(예: 리베이스) 기록을 쉽게 수정할 수 있게 해줍니다(어떤 의미에서는 해시가 참조하는 콘텐츠는 절대 변경되지 않지만 해당 해시에 대한 참조는 손실될 수 있음).일부 순수주의자(나 자신 포함)는 그것을 별로 좋아하지 않습니다.
Bazaar는 합리적으로 빠르며(히스토리가 얕은 트리의 경우 매우 빠르지만 현재 히스토리 길이에 따라 확장성이 떨어짐) 기존 SCM(CVS, SVN 등)의 명령줄 인터페이스에 익숙한 사용자가 쉽게 배울 수 있습니다.Win32는 개발 팀에서 최고의 대상으로 간주됩니다.다양한 구성 요소에 대한 플러그형 아키텍처를 갖추고 있으며 저장 형식을 자주 교체합니다.이를 통해 새로운 기능(예: 다양한 개념을 기반으로 한 개정 제어 시스템과의 통합을 위한 향상된 지원)을 도입하고 성능을 향상시킬 수 있습니다.Bazaar 팀은 디렉토리 추적 및 이름 바꾸기 지원을 최고 수준의 기능으로 간주합니다.전역적으로 고유한 개정 ID 식별자는 모든 개정에 사용할 수 있지만 개정을 식별하기 위해 콘텐츠 해시 대신 트리 로컬 revnos(svn 또는 기타 기존 SCM에서 사용하는 것과 유사한 표준 개정 번호)가 사용됩니다.Bazaar는 기록이 로컬 시스템에 복사되는 대신 원격 서버에 보관되고 필요할 때 네트워크를 통해 자동으로 참조되는 "경량 체크아웃"을 지원합니다.현재 이것은 DSCM 중에서 독특합니다.
둘 다 어떤 형태로든 SVN 통합을 사용할 수 있습니다.그러나 bzr-svn은 git-svn보다 훨씬 더 많은 기능을 제공하는데, 그 이유는 주로 해당 목적으로 도입된 백엔드 형식 개정 때문입니다. [2014년 현재 업데이트:타사 상용 제품인 SubGit은 SVN과 Git 간의 양방향 인터페이스를 제공합니다. 이는 충실도 측면에서 bzr-svn과 비슷하고 훨씬 더 세련되었습니다.나 강하게 예산 및 라이센스 제약이 허용되는 경우 git-svn보다 사용을 권장합니다].
나는 Mercurial을 광범위하게 사용하지 않았기 때문에 이에 대해 자세히 설명할 수 없습니다. 단, Git과 마찬가지로 개정판에 대한 콘텐츠 해시 주소 지정이 있다는 점만 제외하면 됩니다.Git과 마찬가지로 디렉터리를 일급 개체로 처리하지 않습니다(그리고 빈 디렉터리를 저장할 수 없습니다).그러나 Git을 제외한 다른 어떤 DSCM보다 빠르며 경쟁사보다 훨씬 더 나은 IDE 통합(특히 Eclipse의 경우)을 제공합니다.성능 특성(Git보다 약간 뒤떨어짐)과 우수한 크로스 플랫폼 및 IDE 지원을 고려할 때 Mercurial은 상당한 수의 win32 중심 또는 IDE 중심 구성원이 있는 팀에 매력적일 수 있습니다.
SVN에서 마이그레이션할 때 한 가지 우려 사항은 SVN의 GUI 프런트엔드 및 IDE 통합이 분산 SCM보다 더 성숙하다는 것입니다.또한 현재 SVN을 통해 사전 커밋 스크립트 자동화를 많이 사용하는 경우(예:커밋을 진행하기 전에 단위 테스트를 통과해야 함) 다음과 유사한 도구를 사용하고 싶을 것입니다. PQM 공유 브랜치에 대한 병합 요청을 자동화합니다.
SVK는 Subversion을 백업 저장소로 사용하고 SVN 중심 도구와 매우 잘 통합되는 DSCM입니다.그러나 이는 다른 주요 DSCM(Darcs 포함)보다 성능 및 확장성 특성이 현저히 떨어지므로 기록 길이나 파일 수 측면에서 규모가 커지기 쉬운 프로젝트에는 피해야 합니다.
[저자 소개:저는 업무용으로 Git과 Perforce를 사용하고 개인 프로젝트와 임베디드 라이브러리로 Bazaar를 사용합니다.내 고용주 조직의 다른 부분에서는 Mercurial을 많이 사용합니다.전생에 나는 SVN을 중심으로 많은 자동화를 구축했습니다.그 전에는 GNU Arch, BitKeeper, CVS 등을 사용한 경험이 있습니다.Git은 처음에는 상당히 불쾌했습니다. 사용자가 선택한 워크플로우에 맞게 구축된 툴킷과 달리 개념이 많은 환경이라는 점에서 GNU Arch처럼 느껴졌습니다. 하지만 그 이후로 Git에 꽤 익숙해졌습니다. 그것].
다른 팁
Ogre 3D 프로젝트의 Steve Streeting은 방금(2009년 9월 28일) 이 주제에 대한 블로그 항목을 게시했는데, 여기서 그는 훌륭하고 손쉬운 작업을 수행했습니다. Git, Mercurial 및 Bazaar의 비교.
결국 그는 세 가지 모두에서 강점과 약점을 찾았지만 확실한 승자는 없었습니다.좋은 점은 무엇을 선택할지 결정하는 데 도움이 되는 훌륭한 테이블을 제공한다는 것입니다.
짧은 글인데 꼭 읽어보시길 추천드립니다.
여기 사람들은 Git, Mercurial 및 Bazaar의 상대적인 강점과 약점이 무엇이라고 생각합니까?
내 생각에는 힘내 강점은 깔끔한 기본 디자인과 매우 풍부한 기능 세트입니다.또한 다중 분기 리포지토리와 분기가 많은 워크플로 관리를 위한 최고의 지원을 제공한다고 생각합니다.매우 빠르고 저장소 크기가 작습니다.
유용한 몇 가지 기능이 있지만 익숙해지려면 약간의 노력이 필요합니다.여기에는 다음이 포함됩니다 보이는 작업 영역과 저장소 데이터베이스 사이의 중간 스테이징 ara(인덱스). 이는 더 복잡한 경우, 증분 커밋 및 더티 트리와의 커밋에서 더 나은 병합 해결을 허용합니다. 감지 일종의 파일 ID를 사용하여 추적하는 대신 유사성 휴리스틱을 사용하여 이름을 바꾸고 복사합니다. 이는 잘 작동하며 전체 이름 바꾸기뿐만 아니라 파일 간의 코드 이동을 따라갈 수 있는 비난(주석)을 허용합니다.
단점 중 하나는 MS Windows 지원이 뒤처지고 완전하지 않다는 것입니다.또 다른 알려진 단점은 Mercurial처럼 잘 문서화되어 있지 않으며 경쟁사보다 사용자 친화적이지 않지만 변경된다는 것입니다.
내 생각에는 수은제 장점은 우수한 성능과 작은 저장소 크기, 우수한 MS Windows 지원에 있습니다.
주요 단점은 내 생각에 로컬 브랜치(단일 저장소의 여러 브랜치)가 여전히 2급 시민이고 이상하고 복잡한 방식으로 태그를 구현한다는 사실입니다.또한 파일 이름 바꾸기를 처리하는 방식은 차선책이었습니다(그러나 이 가능성은 변경되었습니다).Mercurial은 두 개 이상의 부모가 있는 문어 병합을 지원하지 않습니다.
내가 듣고 읽은 내용에 따르면 바자 장점은 파일과 디렉터리 모두의 이름 변경을 추적하여 중앙 집중식 워크플로를 쉽게 지원한다는 것입니다(단점이기도 합니다. 중앙 집중식 개념이 보이지 않는 곳에서 볼 수 있기 때문입니다).
주요 단점은 긴 비선형 기록을 가진 대규모 저장소의 성능 및 저장소 크기(적어도 너무 크지 않은 저장소의 경우 성능이 향상됨), 기본 패러다임이 저장소당 하나의 목장이라는 사실(단, 데이터를 공유하도록 설정할 수 있음)입니다. , 중앙 집중식 개념(그러나 이는 또한 내가 들은 바에 따르면 변경 사항임).
Git은 C, 쉘 스크립트, Perl로 작성되었으며 스크립트가 가능합니다.Mercurial은 C(성능을 위한 핵심)와 Python으로 작성되었으며 확장을 위한 API를 제공합니다.Bazaar는 Python으로 작성되었으며 확장을 위한 API를 제공합니다.
SVN 및 Perforce와 같은 버전 제어 시스템에 대해 각각을 고려할 때 어떤 문제를 고려해야 합니까?
Subversion(SVN), Perforce 또는 ClearCase와 같은 버전 제어 시스템은 중앙 집중식 버전 관리 시스템.Git, Mercurial, Bazaar(Darcs, Monotone 및 BitKeeper도 포함)는 분산 버전 관리 시스템.분산 버전 제어 시스템을 사용하면 훨씬 더 광범위한 작업 흐름이 가능합니다."준비되면 게시"를 사용할 수 있습니다.분기 및 병합과 분기가 많은 워크플로에 대한 지원이 향상되었습니다.쉽게 기여할 수 있도록 커밋 액세스 권한이 있는 사람들을 신뢰할 필요는 없습니다.
SVN에서 이러한 분산 버전 제어 시스템 중 하나로 마이그레이션을 계획할 때 어떤 요소를 고려해야 합니까?
고려해야 할 요소 중 하나는 SVN을 통한 intracting 지원입니다.Git에는 git-svn이 있고 Bazaar에는 bzr-svn이 있으며 Mercurial에는 hgsubversion 확장이 있습니다.
부인 성명: 나는 Git 사용자이자 소규모 기여자이며 Git 메일링 리스트를 관찰하고 참여합니다.나는 Mercurial과 Bazaar의 문서, IRC와 메일링 리스트에 대한 다양한 토론, 다양한 버전 제어 시스템을 비교하는 블로그 게시물과 기사를 통해서만 Mercurial과 Bazaar를 알고 있습니다. Git비교 Git Wiki 페이지).
InfoQ는 좋은 비교.
Mercurial과 Bazaar는 표면적으로 매우 유사합니다.둘 다 오프라인 커밋 및 여러 분기 병합과 같이 기본적인 분산 버전 제어를 제공하며 둘 다 Python으로 작성되었으며 둘 다 git보다 느립니다.코드를 자세히 살펴보면 많은 차이점이 있지만, 일상적인 작업에서는 Mercurial이 좀 더 추진력이 있는 것처럼 보이지만 사실상 동일합니다.
Git은 초보자를 위한 것이 아닙니다.Mercurial과 Bazaar보다 훨씬 빠르며 Linux 커널을 관리하기 위해 작성되었습니다.세 가지 중 가장 빠르며, 상당한 차이로 세 가지 중에서 가장 강력합니다.Git의 로그 및 커밋 조작 도구는 타의 추종을 불허합니다.그러나 사용하기가 가장 복잡하고 위험하기도 합니다.커밋을 잃거나 저장소를 망치는 것은 매우 쉽습니다. 특히 git의 내부 작동 방식을 이해하지 못하는 경우 더욱 그렇습니다.
최근 Python 개발자가 수행한 비교를 살펴보십시오. http://wiki.python.org/moin/Dvcs비교.그들은 세 가지 중요한 이유를 바탕으로 Mercurial을 선택했습니다.
Mercurial을 선택하게 된 데는 세 가지 중요한 이유가 있습니다.
- 소규모 설문 조사에 따르면, 파이썬 개발자는 바자 나 GIT보다 Mercurial 사용에 더 관심이 있습니다.
- Mercurial은 Python으로 작성되었으며, 이는 '스스로 개밥을 먹는' python-dev 경향과 일치합니다.
- Mercurial은 bzr보다 훨씬 빠릅니다(차이는 훨씬 작지만 git보다 느립니다).
- Mercurial은 Bazaar보다 SVN 사용자가 배우기 더 쉽습니다.
나는 한동안 Bazaar를 사용하고 있었는데 매우 마음에 들었지만 그것은 작은 프로젝트에 불과했고 심지어 그때도 꽤 느렸습니다.배우기는 쉽지만 아주 빠르지는 않습니다.그래도 매우 x-플랫폼입니다.
저는 현재 버전 1.6이 사용하는 명령 측면에서 다른 VCS와 훨씬 더 유사해졌기 때문에 제가 많이 좋아하는 Git을 사용하고 있습니다.
내 생각에 DVCS 사용 경험의 주요 차이점은 다음과 같습니다.
- Git은 가장 활발한 커뮤니티를 보유하고 있으며 Git에 대한 기사를 보는 것이 일반적입니다.
- GitHub 정말 바위.Launchpad.net은 괜찮지만 Github의 즐거움만큼 좋은 것은 없습니다.
- Git용 워크플로 도구의 수는 엄청났습니다.여기저기 통합되어 있습니다.Bzr에는 일부가 있지만 거의 많지도 않고 잘 관리되지도 않습니다.
요약하자면 Bzr은 DVCS를 아주 잘 사용했을 때 훌륭했지만 지금은 Git과 Github에 매우 만족합니다.
이는 문맥에 따라 크게 달라지는 큰 질문이므로 작은 텍스트 상자 중 하나에 입력하는 데 많은 시간이 걸립니다.또한 이 세 가지 모두 대부분의 프로그래머가 수행하는 일반적인 작업에 사용될 때 실질적으로 유사해 보이므로 차이점을 이해하는 것조차 상당히 난해한 지식이 필요합니다.
보다 구체적인 질문이 있는 지점까지 이러한 도구에 대한 분석을 세분화할 수 있다면 훨씬 더 나은 답변을 얻을 수 있을 것입니다.
Bazaar는 git보다 배우기 쉽습니다.Git은 github.com에서 훌륭한 지원을 제공합니다.
두 가지를 모두 사용해보고 가장 적합한 것을 결정해야 한다고 생각합니다.
여기 사람들은 Git, Mercurial 및 Bazaar의 상대적인 강점과 약점이 무엇이라고 생각합니까?
이것은 화염 미끼에 접한 매우 공개적인 질문입니다.
Git이 가장 빠르지만 세 가지 모두 충분히 빠릅니다.Bazaar는 가장 유연하며(SVN 리포지토리에 대한 투명한 읽기-쓰기 지원) 사용자 경험에 많은 관심을 기울입니다.Mercurial은 중간 어딘가에 있습니다.
세 가지 시스템 모두 팬보이가 많습니다.저는 개인적으로 Bazaar 팬보이입니다.
SVN 및 Perforce와 같은 버전 제어 시스템에 대해 각각을 고려할 때 어떤 문제를 고려해야 합니까?
전자는 분산 시스템입니다.후자는 중앙 집중식 시스템입니다.또한 Perforce는 독점적인 반면 다른 모든 것은 무료입니다. 연설에서와 같이.
중앙집중형과 분산형은 해당 카테고리에서 언급한 시스템보다 훨씬 더 중요한 선택입니다.
SVN에서 이러한 분산 버전 제어 시스템 중 하나로 마이그레이션을 계획할 때 어떤 요소를 고려해야 합니까?
첫째, TortoiseSVN을 대체할 좋은 대안이 부족합니다.Bazaar는 자체적으로 작업하고 있지만 거북이 변종, 그러나 2008년 9월 기준으로는 아직 없습니다.
그런 다음 분산형 시스템을 사용하는 것이 업무에 어떤 영향을 미칠지 주요 인력에게 교육합니다.
마지막으로 이슈 추적기, 야간 빌드 시스템, 자동화된 테스트 시스템 등과 같은 나머지 시스템과의 통합입니다.
귀하의 주요 문제는 이것이 될 것입니다 분산 SCM은 사용자의 사고방식에 약간의 변화를 요구합니다.사람들이 아이디어에 익숙해지면 기술적 세부 사항과 사용 패턴이 자리를 잡을 것입니다. 그러나 특히 기업 환경에서 초기 장애물을 과소평가하지 마십시오.모든 문제는 사람의 문제라는 것을 기억하십시오.
ddaa.myopenid.com에서 지나가면서 언급했지만 다시 언급할 가치가 있다고 생각합니다.Bazaar는 원격 SVN 저장소를 읽고 쓸 수 있습니다.즉, 나머지 팀이 여전히 Subversion을 사용하는 동안 개념 증명으로 Bazaar를 로컬에서 사용할 수 있습니다.
편집하다:이제 거의 모든 도구에 일부 SVN과 상호 작용하는 방법이 있지만 이제 개인적인 경험이 있습니다. git svn 공장 극도로 잘.나는 딸꾹질을 최소화하면서 몇 달 동안 그것을 사용해 왔습니다.
git에는 Linus Torvalds의 좋은 비디오가 있습니다.그는 Git의 창시자이므로 이것이 그가 홍보하는 내용이지만 비디오에서 그는 분산 SCM이 무엇인지, 그리고 중앙 집중식 SCM보다 나은 이유를 설명합니다.git(수은은 괜찮은 것으로 간주됨)과 cvs/svn/perforce를 비교하는 방법이 많이 있습니다.분산 SCM으로의 마이그레이션에 관한 청중의 질문도 있습니다.
나는 이 자료를 통해 깨달았고 분산형 SCM에 매각되었습니다.그러나 Linus의 노력에도 불구하고 나의 선택은 변덕스럽습니다.그 이유는 bitbucket.org인데, github보다 더 나은(더 관대함) 것을 알았습니다.
여기서 경고의 말씀을 드리고 싶습니다.리누스는 꽤 공격적인 스타일이어서 웃기고 싶어하는 것 같았지만 나는 웃지 않았습니다.그 외에도 분산 SCM을 처음 접하고 SVN에서 전환을 고려하는 경우 비디오가 좋습니다.
DVCS(분산 버전 제어 시스템)는 중앙 집중식 VCS와는 다른 문제를 해결합니다.그것들을 비교하는 것은 망치와 드라이버를 비교하는 것과 같습니다.
중앙 집중식 VCS 시스템은 축복받고 따라서 좋은 하나의 참 근원이 있다는 의도로 설계되었습니다.모든 개발자는 해당 소스에서 작업(체크아웃)한 다음 변경 사항을 추가(커밋)하고 유사하게 Blessed됩니다.CVS, Subversion, ClearCase, Perforce, VisualSourceSafe 및 기타 모든 CVCS 간의 유일한 실제 차이점은 각 제품이 제공하는 워크플로, 성능 및 통합에 있습니다.
분산 VCS 시스템은 하나의 저장소가 다른 저장소와 마찬가지로 우수하다는 의도로 설계되었으며, 한 저장소에서 다른 저장소로 병합하는 것은 또 다른 형태의 의사소통일 뿐입니다.어떤 저장소를 신뢰해야 하는지에 대한 의미론적 값은 소프트웨어 자체가 아닌 프로세스에 의해 외부에서 부여됩니다.
한 가지 유형을 사용하거나 다른 유형을 사용하는 것 사이의 실제 선택은 조직적입니다. 프로젝트나 조직이 중앙 집중식 제어를 원하는 경우 DVCS는 시작이 아닙니다.개발자가 중앙 저장소에 대한 보안 광대역 연결 없이 국가/세계 전역에서 작업해야 한다면 DVCS가 아마도 구원이 될 것입니다.둘 다 필요하면 fsck됩니다.
