Windows (msysGit 포함)에서 git을 얼마 동안 사용해 왔으며 분산 소스 제어라는 아이디어가 마음에 듭니다. 최근에 나는 Mercurial (hg)을보고 있었고 재미있어 보입니다. 그러나 hg와 git의 차이점을 머리로 감쌀 수는 없습니다.
git과 hg를 나란히 비교 한 사람이 있습니까? 팬보이 토론에 뛰어 들지 않고 hg와 git의 차이점을 알고 싶습니다.
답변
이 기사가 도움이 될 수 있습니다.
- Git vs. Mercurial : Please Relax (Git은 MacGyver이고 Mercurial은 James Bond)
- Mercurial과 Git의 차이점
편집 : 유명 인사와 Git 및 Mercurial을 비교하는 것이 추세 인 것 같습니다. 여기 하나 더 있습니다 :
답변
나는 Mercurial에서 일하지만 기본적으로 두 시스템이 동일하다고 생각합니다. 둘 다 동일한 추상화로 작업합니다. 히스토리를 구성하는 일련의 스냅 샷 (변경 세트). 각 변경 세트는 그것이 어디에서 왔는지 (부모 변경 세트) 알고 있으며 많은 자식 변경 세트를 가질 수 있습니다. 최근의 hg-git 확장은 Mercurial과 Git 간의 양방향 브리지를 제공하며 이러한 점을 보여줍니다.
Git은 이력 그래프를 변경하는 데 중점을두고 있지만 Mercurial은 기록 재 작성을 권장하지 않지만 어쨌든 쉽게 할 수 있으며 그렇게 할 때의 결과는 정확하게 예상됩니다 (즉 , 이미 보유한 변경 세트를 수정하면 고객이 변경 세트를 새 것으로 간주합니다. 따라서 Mercurial은 비파괴 명령에 대한 편견 이 있습니다.
경량 지점의 경우 Mercurial은 여러 지점이있는 리포지토리를 지원 했기 때문에 … 항상 생각합니다. 여러 개의 브랜치가있는 Git 리포지토리는 정확히 다음과 같습니다. 단일 리포지토리에 여러 분기 된 개발 가닥이 있습니다. 그런 다음 Git은이 스트랜드에 이름을 추가하고이 이름을 원격으로 쿼리 할 수 있습니다. Mercurial 의 책갈피 확장 기능은 로컬 이름을 추가하며 Mercurial 1.6을 사용하면 밀거나 당길 때 이러한 책갈피를 이동할 수 있습니다.
나는 Linux를 사용하지만 TortoiseHg는 Windows의 Git에 비해 더 빠르며 낫다 (빈약 한 Windows 파일 시스템의 더 나은 사용으로 인해). 두 http://github.com 및 http://bitbucket.org은 (내가 github에 시도하지 않은)의 Bitbucket의 서비스는 위대하고 반응한다 온라인 호스팅 제공합니다.
나는 깨끗하고 우아하다고 느끼기 때문에 Mercurial을 선택했다. 나는 Git과 함께 얻은 쉘 / Perl / Ruby 스크립트에 의해 연기되었다. 무슨 뜻인지 알고 싶다면 git-instaweb.sh
파일을 들여다보십시오 . 루비 스크립트 를 생성하는 쉘 스크립트입니다 . 웹 스크립트를 실행한다고 생각합니다. 쉘 스크립트는 다른 쉘 스크립트를 생성하여 첫 번째 Ruby 스크립트를 시작합니다. 좋은 측정을 위해 약간의 Perl 도 있습니다 .
Mercurial과 Git을 James Bond 및 MacGyver와 비교 하는 블로그 게시물 이 마음에 듭니다. Mercurial은 Git보다 다소 중요하지 않습니다. Mercurial을 사용하는 사람들은 그리 쉽게 감동받지 않는 것 같습니다. 이것은 Linus가 “가장 멋진 병합”이라고 설명한 방식으로 각 시스템이 수행하는 방식에 반영됩니다 . . Git에서는 다음을 수행하여 관련되지 않은 리포지토리와 병합 할 수 있습니다.
git fetch <project-to-union-merge>
GIT_INDEX_FILE=.git/tmp-index git-read-tree FETCH_HEAD
GIT_INDEX_FILE=.git/tmp-index git-checkout-cache -a -u
git-update-cache --add -- (GIT_INDEX_FILE=.git/tmp-index git-ls-files)
cp .git/FETCH_HEAD .git/MERGE_HEAD
git commit
그 명령은 내 눈에 꽤 비 유적으로 보인다. Mercurial에서는 다음을 수행합니다.
hg pull --force <project-to-union-merge>
hg merge
hg commit
Mercurial 명령이 평범하고 전혀 특별하지 않은 방법에 주목하십시오. 유일하게 특이한 것은에 대한 --force
플래그입니다. hg pull
Mercurial은 관련없는 저장소에서 가져올 때 다른 방법으로 중단되기 때문에 필요합니다. Mercurial을 좀 더 우아하게 만드는 것은 이와 같은 차이점입니다.
답변
Git은 플랫폼이고 Mercurial은 “단지”응용 프로그램입니다. Git은 DVCS 응용 프로그램과 함께 제공되는 버전이 지정된 파일 시스템 플랫폼이지만 플랫폼 응용 프로그램의 경우와 마찬가지로 집중적 인 응용 프로그램보다 더 복잡하고 가장자리가 복잡합니다. 그러나 이것은 또한 git의 VCS가 상당히 유연하다는 것을 의미하며 git으로 할 수있는 비 소스 제어 작업의 깊이가 엄청납니다.
그것이 차이점의 본질입니다.
Git은 저장소 형식부터 기초부터 이해하는 것이 가장 좋습니다. Scott Chacon의 Git Talk 는이를위한 훌륭한 입문서입니다. 후드에서 무슨 일이 일어나고 있는지 모르고 git을 사용하려고하면 (기본 기능 만 고수하지 않는 한) 어느 시점에서 혼란스러워집니다. git의 천재는 리포지토리 형식이 실제로 매우 간단하고 git의 전체 작업을 매우 쉽게 이해할 수 있다는 것입니다.
기술 중심의 비교를 위해 개인적으로 본 최고의 기사는 Dustin Sallings입니다.
그는 실제로 두 DVCS를 광범위하게 사용했으며 둘 다 잘 이해했으며 결국 자식을 선호했습니다.
답변
큰 차이점은 Windows에 있습니다. Mercurial은 기본적으로 지원되지만 Git은 지원되지 않습니다. bitbucket.org 를 사용하여 github.com 과 매우 유사한 호스팅을 얻을 수 있습니다 (실제로는 무료 개인 저장소를 얻을 때 더 좋습니다). 나는 msysGit을 잠시 동안 사용하고 있었지만 Mercurial로 옮겨서 매우 기뻤습니다.
답변
기본 연결이 끊긴 개정 제어를 찾고있는 Windows 개발자 인 경우 Hg로 이동하십시오. Hg가 단순하고 Windows 셸과 잘 통합되어 있지만 Git을 이해할 수 없다는 것을 알았습니다. Hg를 다운로드 하고이 자습서 (hginit.com)를 따랐습니다. 10 분 후에 로컬 리포지토리 를 사용하여 프로젝트 작업을 다시 시작했습니다.
답변
“Mercurial vs. Git”에 대한 가장 좋은 설명은 다음과 같습니다.
답변
그들은 거의 동일합니다. 내 관점에서 가장 중요한 차이점은 (하나는 다른 하나의 DVCS를 선택하게 된 이유는) 두 프로그램이 지점을 관리하는 방법입니다.
Mercurial을 사용하여 새 브랜치를 시작하려면 리포지토리 를 다른 디렉토리에 복제하고 개발을 시작하면됩니다. 그런 다음 끌어서 병합합니다. git을 사용하면 사용하려는 새 토픽 브랜치에 이름을 명시 적으로 지정해야 하며 동일한 디렉토리를 사용하여 코딩을 시작 합니다.
간단히 말해서 Mercurial의 각 지점에는 자체 디렉토리가 필요합니다. git에서는 일반적으로 단일 디렉토리에서 작업합니다. Mercurial에서 브랜치 전환은 디렉토리 변경을 의미합니다. git에서 git checkout으로 디렉토리의 내용을 변경하도록 git에게 요청하는 것을 의미합니다.
나는 정직합니다 : Mercurial과 동일한 작업을 수행 할 수 있는지 모르겠지만 일반적으로 웹 프로젝트에서 작업하기 때문에 항상 git과 동일한 디렉토리를 사용하면 나에게 매우 불편한 것처럼 보입니다. -Apache를 구성하고 다시 시작하면 분기마다 파일 시스템이 엉망이되지 않습니다.
편집 : Deestan이 지적했듯이 Hg는 이름이 branches 이며 단일 저장소에 저장할 수 있으며 개발자는 동일한 작업 사본 내에서 분기를 전환 할 수 있습니다. 자식 분기는 Mercurial 명명 된 분기와 정확히 동일하지 않습니다. 어쨌든 git와 같이 영구적이며 분기를 버리지 않습니다. 즉, 병합하지 않더라도 실험 작업에 명명 된 분기를 사용하면 리포지토리에 저장됩니다. 이것이 Hg가 릴리스 브랜치와 같이 실험적인 단기 실행 작업을 위해 클론을 사용하고 장기 실행 작업을 위해 명명 된 브랜치를 사용하도록 권장하는 이유입니다.
많은 Hg 사용자가 지명 된 브랜치보다 클론을 선호하는 이유는 기술적 인 것보다 훨씬 사회적이거나 문화적입니다. 예를 들어, Hg의 마지막 버전에서는 명명 된 분기를 닫고 변경 세트에서 메타 데이터를 재귀 적으로 제거 할 수도 있습니다.
다른 한편으로, git은 영구하지 않고 각 변경 세트에 메타 데이터로 저장되지 않은 “명명 된 브랜치”를 사용하도록 초대합니다.
개인적 관점에서 git의 모델은 지명 된 브랜치의 개념과 깊이 연결되어 있고 같은 디렉토리를 사용하여 브랜치와 다른 브랜치 사이를 전환합니다. hg는 명명 된 분기와 동일한 작업을 수행 할 수는 있지만 개인적으로 너무 좋아하지 않는 복제본을 사용하도록 권장합니다.