Mercurial과 Git의 차이점은 무엇입니까?
https://stackoverflow.com/questions/35837
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
저는 Windows(msysGit 포함)에서 한동안 git을 사용해 왔으며 분산 소스 제어라는 아이디어를 좋아합니다.최근에 Mercurial(hg)을 살펴보았는데 흥미로웠습니다.그러나 hg와 git의 차이점에 대해 머리를 감쌀 수는 없습니다.
git과 hg를 나란히 비교한 사람이 있습니까?나는 팬보이 토론에 뛰어들지 않고도 hg와 git의 차이점을 알고 싶습니다.
해결책
다음 기사가 도움이 될 수 있습니다.
- Git 대수은제:긴장을 풀어주세요 (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 온라인 호스팅을 제공하며 Bitbucket의 서비스는 훌륭하고 반응이 빠릅니다(Github을 사용해 본 적이 없습니다).
나는 깨끗하고 우아한 느낌 때문에 Mercurial을 선택했습니다. Git에서 얻은 쉘/Perl/Ruby 스크립트 때문에 망설였습니다.살짝 구경해 보세요 git-instaweb.sh 파일 내가 무슨 말을 하는지 알고 싶다면:이것은 껍데기 생성하는 스크립트 루비 내 생각에 웹서버를 실행하는 스크립트입니다.쉘 스크립트는 첫 번째 Ruby 스크립트를 실행하기 위해 또 다른 쉘 스크립트를 생성합니다.약간의 것도 있습니다 펄, 좋은 측정을 위해.
나는 블로그 게시물 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을 사용하려고 하면 어느 시점에서는 혼란에 빠지게 될 것입니다(아주 기본적인 기능만 고수하지 않는 한).여러분이 원하는 것이 일상적인 프로그래밍 루틴을 위한 DVCS뿐이라면 이것은 어리석게 들릴 수도 있지만, git의 천재성은 저장소 형식이 실제로 매우 간단하고 ~할 수 있다 git의 전체 작업을 아주 쉽게 이해합니다.
좀 더 기술적 중심의 비교를 위해 제가 개인적으로 본 최고의 기사는 Dustin Sallings의 다음과 같습니다.
그는 실제로 두 DVCS를 광범위하게 사용했으며 둘 다 잘 이해하고 있으며 결국 git을 선호하게 되었습니다.
가장 큰 차이점은 Windows에 있습니다.Mercurial은 기본적으로 지원되지만 Git은 지원되지 않습니다.당신은 매우 유사한 호스팅을 얻을 수 있습니다 github.com ~와 함께 bitbucket.org (실제로 무료 개인 저장소를 얻으면 훨씬 더 좋습니다).나는 한동안 msysGit을 사용하고 있었지만 Mercurial로 전환하여 매우 만족했습니다.
기본적인 연결 해제 개정 제어를 원하는 Windows 개발자라면 Hg를 선택하세요.Hg는 간단하고 Windows 셸과 잘 통합되어 있는 반면 Git은 이해하기 어렵다는 것을 알았습니다.Hg를 다운로드하고 팔로우했습니다. 이 튜토리얼(hginit.com) - 10분 후에 로컬 저장소가 생겼고 다시 프로젝트 작업에 착수했습니다.
내 생각에 "Mercurial vs. Mercurial"에 대한 가장 좋은 설명은 다음과 같습니다.힘내"는 다음과 같습니다
그들은 거의 동일합니다.내 관점에서 볼 때 가장 중요한 차이점은(다른 DVCS보다 하나의 DVCS를 선택하게 된 이유) 두 프로그램이 분기를 관리하는 방법입니다.
Mercurial을 사용하여 새 브랜치를 시작하려면 저장소를 복제하기만 하면 됩니다. 다른 디렉토리로 그리고 개발을 시작하세요.그런 다음 당겨서 병합합니다.git을 사용하면 사용하려는 새 주제 브랜치에 명시적으로 이름을 지정한 다음 코딩을 시작해야 합니다. 동일한 디렉토리를 사용하여.
간단히 말해서 Mercurial의 각 분기에는 자체 디렉토리가 필요합니다.git에서는 일반적으로 단일 디렉토리에서 작업합니다.Mercurial에서 분기를 전환한다는 것은 디렉터리를 변경한다는 의미입니다.git에서는 git checkout을 사용하여 디렉토리의 내용을 변경하도록 git에 요청하는 것을 의미합니다.
나는 정직 해:Mercurial을 사용하여 동일한 작업을 수행하는 것이 가능한지는 모르겠지만 일반적으로 웹 프로젝트 작업을 하기 때문에 git에서 항상 동일한 디렉토리를 사용하는 것이 훨씬 편해 보입니다. Apache를 다시 구성하고 다시 시작할 필요가 없기 때문입니다. 그리고 분기할 때마다 파일 시스템을 엉망으로 만들지 않습니다.
편집하다:Deestan이 언급했듯이 Hg는 명명된 가지, 단일 저장소에 저장될 수 있으며 개발자가 동일한 작업 복사본 내에서 분기를 전환할 수 있습니다.어쨌든 git 브랜치는 Mercurial 명명된 브랜치와 정확히 동일하지 않습니다.그것들은 영구적이며 git처럼 가지를 버리지 않습니다.즉, 병합하지 않기로 결정하더라도 실험 작업에 명명된 분기를 사용하면 저장소에 저장된다는 의미입니다.이것이 바로 Hg가 실험적인 단기 실행 작업에는 클론을 사용하고 릴리스 분기와 같은 장기 실행 작업에는 명명된 분기를 사용하도록 권장하는 이유입니다.
많은 Hg 사용자가 명명된 분기보다 클론을 선호하는 이유는 기술적인 것보다 훨씬 사회적이거나 문화적인 것입니다.예를 들어 Hg의 최신 버전에서는 명명된 분기를 닫고 변경 집합에서 메타데이터를 반복적으로 제거하는 것도 가능합니다.
반면에 git은 영구적이지 않고 각 변경 세트에 메타데이터로 저장되지 않는 "명명된 분기"를 사용하도록 초대합니다.
내 개인적인 관점에서 보면 git의 모델은 명명된 분기 개념과 깊이 연결되어 있으며 동일한 디렉터리 내에서 분기와 다른 분기 사이를 전환합니다.hg는 명명된 브랜치에 대해 동일한 작업을 수행할 수 있지만 개인적으로 별로 좋아하지 않는 클론 사용을 권장합니다.
하나 있어요 거대한 사이의 차이 자식 그리고 수은제;각 커밋을 나타내는 방식. 자식 커밋을 스냅샷으로 나타내는 반면 수은제 그것들을 diff로 표현합니다.
이것이 실제로 무엇을 의미합니까?글쎄, 다른 커밋으로 전환, 커밋 비교 등과 같은 많은 작업이 git에서 더 빠릅니다.특히 이러한 커밋이 멀리 떨어져 있는 경우에는 더욱 그렇습니다.
AFAIK 수은 접근 방식에는 이점이 없습니다.
아무것도 아님.둘 다 동일한 작업을 수행하고 거의 동일한 성능을 발휘합니다.다른 것보다 하나를 선택해야 하는 유일한 이유는 이미 하나를 사용하는 프로젝트에 도움을 주는 경우입니다.
하나를 선택하는 또 다른 가능한 이유는 시스템 중 하나만 지원하는 응용 프로그램이나 서비스입니다.예를 들어, 저는 다음과 같은 이유로 git을 배우기로 결정했습니다. 깃허브..
또한 Google의 비교(약간 오래되었지만 2008년에 수행됨)
내가 그것들을 올바르게 이해한다면(그리고 나는 각각에 대한 전문가와는 거리가 멀다) 근본적으로 각각은 다른 철학을 가지고 있습니다.나는 처음으로 수은을 9개월 동안 사용했습니다.이제 6에 git을 사용했습니다.
hg는 버전 관리 소프트웨어입니다.주요 목표는 소프트웨어 버전을 추적하는 것입니다.
git은 시간 기반 파일 시스템입니다.목표는 파일 시스템에 또 다른 차원을 추가하는 것입니다.대부분 파일과 폴더가 있으며 git은 시간을 추가합니다.VCS가 설계의 부산물이기 때문에 훌륭하게 작동합니다.
hg에는 항상 유지하려고 노력하는 전체 프로젝트의 기록이 있습니다.기본적으로 나는 hg가 밀고 당길 때 모든 사용자가 모든 개체에 대한 모든 변경을 원한다고 믿습니다.
git에는 개체 풀과 특정 상태의 파일 트리를 나타내는 개체 집합을 결정하는 추적 파일(분기/헤드)만 있습니다.밀거나 당길 때 git은 밀거나 당기는 특정 가지에 필요한 개체만 보냅니다. 이는 모든 개체의 작은 하위 집합입니다.
git에 관한 한 "1 프로젝트"는 없습니다.동일한 저장소에 50개의 프로젝트가 모두 있을 수 있으며 git은 신경 쓰지 않을 것입니다.각각은 동일한 리포지토리에서 별도로 관리될 수 있으며 잘 작동할 수 있습니다.
Hg의 분기 개념은 메인 프로젝트에서 분기하거나 분기 등에서 분기하는 것입니다.Git에는 그런 개념이 없습니다.git의 브랜치는 트리의 상태일 뿐이고 모든 것이 git의 브랜치입니다.어떤 브랜치가 공식인지, 현재인지, 최신인지는 git에서는 의미가 없습니다.
그게 말이 되는지 모르겠어요.그림을 그릴 수 있다면 각 커밋이 다음과 같이 보일 것입니다. o
o---o---o
/
o---o---o---o---o---o---o---o
\ /
o---o---o
하나의 뿌리와 가지가 나오는 나무.git은 그렇게 할 수 있지만 사람들은 종종 강제되지 않는 방식으로 사용합니다.git 그림이 있다면 쉽게 다음과 같이 보일 수 있습니다.
o---o---o---o---o
o---o---o---o
\
o---o
o---o---o---o
실제로 어떤 면에서는 git에서 브랜치를 표시하는 것이 의미가 없습니다.
토론에서 매우 혼란스러운 점 중 하나는 git과 mercurial 둘 다 "브랜치"라는 것을 가지고 있지만 원격으로 동일한 것은 아닙니다.Mercurial의 분기는 서로 다른 저장소 간에 충돌이 있을 때 발생합니다.git의 브랜치는 분명히 hg의 클론과 유사합니다.그러나 클론은 유사한 동작을 제공할 수 있지만 확실히 동일하지는 않습니다.다소 큰 크롬 저장소를 사용하여 git 대 hg에서 이것을 시도해 보는 것을 고려해 보십시오.
$ time git checkout -b some-new-branch
Switched to new branch 'some-new-branch'
real 0m1.759s
user 0m1.596s
sys 0m0.144s
이제 hg에서 클론을 사용하여
$ time hg clone project/ some-clone/
updating to branch default
29387 files updated, 0 files merged, 0 files removed, 0 files unresolved.
real 0m58.196s
user 0m19.901s
sys 0m8.957
둘 다 핫런입니다.즉, 두 번 실행했고 이번이 두 번째 실행입니다.hg clone은 실제로 git-new-workdir과 동일합니다.둘 다 마치 입력한 것처럼 완전히 새로운 작업 디렉토리를 만듭니다. cp -r project project-clone.이는 git에서 새 브랜치를 만드는 것과는 다릅니다.무게가 훨씬 더 무겁습니다.hg에 git의 분기와 동등한 기능이 있다면 그것이 무엇인지 모르겠습니다.
나는 어느 정도 hg와 git을 이해합니다. ~할 것 같다 비슷한 일을 할 수 있습니다.그렇다면 그들이 안내하는 작업 흐름에는 여전히 큰 차이가 있습니다.git에서 일반적인 작업흐름은 모든 기능에 대한 브랜치를 생성하는 것입니다.
git checkout master
git checkout -b add-2nd-joypad-support
git checkout master
git checkout -b fix-game-save-bug
git checkout master
git checkout -b add-a-star-support
방금 3개의 브랜치를 생성했는데, 각 브랜치는 마스터라는 브랜치를 기반으로 합니다.(git에서 2줄 대신 1줄을 만드는 방법이 있다고 확신합니다.)
이제 한 가지 작업을 하려고 합니다.
git checkout fix-game-save-bug
그리고 일을 시작하세요.커밋 등을 수행합니다.크롬만큼 큰 프로젝트에서도 브랜치 간 전환은 거의 즉각적입니다.실제로 hg에서 어떻게 하는지 모르겠습니다.내가 읽은 튜토리얼의 일부가 아닙니다.
또 다른 큰 차이점이 있습니다.Git의 무대.
Git에는 무대에 대한 아이디어가 있습니다.숨겨진 폴더라고 생각하시면 됩니다.커밋하면 스테이지에 있는 내용만 커밋하고 작업 트리의 변경 사항은 커밋하지 않습니다.이상하게 들릴 수도 있습니다.작업 트리의 모든 변경 사항을 커밋하려면 다음을 수행하십시오. git commit -a 수정된 모든 파일을 스테이지에 추가한 다음 커밋합니다.
그렇다면 무대의 의미는 무엇입니까?커밋을 쉽게 분리할 수 있습니다.Joypad.cpp와 gamesave.cpp를 편집했고 그것들을 별도로 커밋하고 싶다고 상상해 보세요.
git add joypad.cpp // copies to stage
git commit -m "added 2nd joypad support"
git add gamesave.cpp // copies to stage
git commit -m "fixed game save bug"
Git에는 동일한 파일에서 스테이지에 복사할 특정 라인을 결정하는 명령도 있으므로 해당 커밋을 별도로 분할할 수도 있습니다.왜 그렇게 하고 싶나요?별도의 커밋을 통해 다른 사람들은 원하는 커밋만 가져올 수 있고, 문제가 있는 경우 문제가 있는 커밋만 되돌릴 수 있기 때문입니다.
versioncontrolblog에는 여러 가지 버전 제어 시스템을 비교할 수 있는 동적 비교 차트가 있습니다.
지점 작업(특히 단기 지점)에 있어서는 상당한 차이가 있습니다.
에 설명되어 있습니다. 이 기사(분기 설명) Mercurial과 Git을 비교합니다.
프로젝트에 Windows 기반 공동 작업자가 있습니까?
왜냐하면 Git-for-Windows GUI가 어색하고, 어렵고, 비우호적으로 보이기 때문입니다.
대조적으로 Mercurial-on-Windows는 생각할 필요도 없습니다.
bitbucket.org의 mercurial과 github의 git 사이에서 주목해야 할 점은 mercurial은 원하는 만큼 많은 개인 저장소를 가질 수 있지만 github에서는 유료 계정으로 업그레이드해야 한다는 것입니다.그래서 저는 수은을 사용하는 bitbucket을 선택합니다.
작년에 나는 내 용도로 git과 hg를 모두 평가하고 hg를 사용하기로 결정했습니다.나는 그것이 더 깔끔한 솔루션처럼 보였고 당시 더 많은 플랫폼에서 더 잘 작동한다고 느꼈습니다.하지만 대부분은 던지기였습니다.
최근에는 git-svn과 Subversion 클라이언트 역할을 하는 기능 때문에 git을 사용하기 시작했습니다.이것이 나를 이겼고 이제 완전히 git으로 전환했습니다.나는 학습 곡선이 약간 더 높다고 생각하지만(특히 내부를 살펴봐야 하는 경우) 정말 훌륭한 시스템입니다.나는 지금 John이 게시한 두 비교 기사를 읽으러 갈 것입니다.
저는 현재 SVN에서 DVCS로 마이그레이션하는 중입니다(내 발견에 대해 블로그를 작성하는 동안, 첫 번째 실제 블로그 활동...). 약간의 조사(=인터넷 검색)를 수행했습니다.내가 아는 한 두 패키지 모두에서 대부분의 작업을 수행할 수 있습니다.GIT가 구현 된 고급 기능을 몇 가지 또는 더 잘 가지고있는 것처럼 보이며, Windows와의 통합은 Tortoisehg와 함께 Mercurial에게는 조금 더 좋다고 생각합니다.Git Cheetah도 있다는 것을 알고 있지만(둘 다 시도했습니다) 수은 솔루션이 더 강력하다고 느껴집니다.
둘 다 오픈 소스인 것을 보면(맞죠?) 둘 다 중요한 기능이 부족하지는 않을 것 같습니다.중요한 것이 있으면 사람들은 그것을 요구하고 코딩합니다.
일반적인 관행에는 Git과 Mercurial이면 충분하다고 생각합니다.둘 다 이를 사용하는 큰 프로젝트(Git -> Linux 커널, Mercurial -> Mozilla 기초 프로젝트, 물론 둘 다)를 가지고 있으므로 둘 다 실제로 뭔가 부족하다고 생각하지 않습니다.
즉, 나는 다른 사람들이 이것에 대해 말하는 것에 관심이 있습니다. 왜냐하면 그것이 내 블로그 활동에 훌륭한 소스가 될 것이기 때문입니다 ;-)
git, Mercurial 및 Bazaar에는 훌륭하고 철저한 비교표와 차트가 있습니다. DVCS에 대한 InfoQ 가이드.
나는 이것이 대답의 일부가 아니라는 것을 알고 있지만 NetBeans 및 Eclipse와 같은 플랫폼을 위한 안정적인 플러그인의 가용성이 어떤 도구가 작업에 더 적합한지 또는 어떤 도구가 더 적합한지에 영향을 미친다고 생각합니다. "당신"에게 가장 잘 어울리는 단어입니다.즉, 당신이 아니면 정말 CLI 방식으로 하고 싶습니다.
Eclipse(및 이를 기반으로 하는 모든 것)와 NetBeans 모두 원격 파일 시스템(예: SSH) 및 파일의 외부 업데이트에 문제가 있는 경우가 있습니다.이것이 무엇을 선택하든 "원활하게" 작동하기를 원하는 또 다른 이유입니다.
나도 지금 이 질문에 답하려고 노력 중이야..그리고 후보를 Git이나 Mercurial로 압축했습니다..종교적인 생각 없이 이 주제에 대해 유용한 의견을 제공해 주신 모든 분들께 감사드립니다.
Mercurial과 git의 또 다른 흥미로운 비교는 다음과 같습니다. 머큐리얼과 힘내.주요 초점은 내부 요소와 분기 프로세스에 미치는 영향에 있습니다.
Mercurial과 Git의 성능 비교에 관심이 있다면 다음을 살펴보세요. 이 기사.결론은 다음과 같습니다
Git과 Mercurial은 둘 다 좋은 수치를 보이지만 속도와 저장소 크기 사이에서 흥미로운 균형을 이루고 있습니다.Mercurial은 추가 및 수정 속도가 빠르며 동시에 저장소 증가를 제어합니다.Git도 빠르지만 리포지토리는 다시 압축할 때까지 수정된 파일로 인해 매우 빠르게 증가하며 이러한 다시 압축은 매우 느릴 수 있습니다.그러나 압축된 저장소는 Mercurial의 저장소보다 훨씬 작습니다.
머큐리얼 웹사이트에는 유사점과 차이점에 대한 훌륭한 설명 두 시스템 간의 어휘와 기본 개념의 차이점을 설명합니다.오랫동안 git 사용자로서 Mercurial 사고방식을 이해하는 데 큰 도움이 되었습니다.
이 링크는 차이점을 이해하는 데 도움이 될 수 있습니다.http://www.techtatva.com/2010/09/git-mercurial-and-bazaar-a-comparison/
어떤 사람들은 VCS 시스템이 복잡해야 한다고 생각합니다.그들은 현장에서 용어와 개념을 고안하도록 장려합니다.그들은 아마도 그 주제에 관한 수많은 박사 학위가 흥미로울 것이라고 생각할 것입니다.그 중에는 아마도 Git을 디자인한 사람들도 있을 것입니다.
Mercurial은 다른 사고방식으로 설계되었습니다.개발자는 VCS에 크게 신경을 쓰지 말고 다음과 같은 주요 기능에 시간을 투자해야 합니다.소프트웨어 공학.Mercurial을 사용하면 사용자는 복구 불가능한 실수를 저지르지 않고 시스템을 사용하고 남용할 수 있습니다.
모든 전문 도구에는 명확하게 설계되고 직관적인 CLI가 함께 제공되어야 합니다.Mercurial 사용자는 이상한 옵션 없이 간단한 명령을 실행하여 대부분의 작업을 수행할 수 있습니다.Git 이중 대시에서는 미친 옵션이 표준입니다.Mercurial은 CLI 사용자인 경우 상당한 이점을 제공합니다(솔직히 말해서 자존심이 강한 소프트웨어 엔지니어라면 누구나 그래야 합니다).
예를 들어, 실수로 커밋을 했다고 가정해 보겠습니다.일부 파일을 편집하는 것을 잊었습니다.Mercurial에서 작업을 취소하려면 다음을 입력하면 됩니다.
$ hg rollback
그런 다음 시스템이 마지막 거래를 취소한다는 메시지를 받게 됩니다.
Git에서는 다음을 입력해야 합니다.
$ git reset --soft HEAD^
그럼 당신이 재설정이 무엇인지 알고 있다고 가정해 봅시다.그러나 또한 "--soft" 및 "--hard" 재설정이 무엇인지 알아야 합니다(직관적으로 추측할 수 있습니까?).아, 물론 끝에 '^' 문자도 잊지 마세요!(이제 리치 이름이 뭐죠...)
kdiff3 및 meld와 같은 타사 도구와 Mercurial의 통합도 훨씬 좋습니다.별다른 소란 없이 패치를 생성하고 브랜치를 병합하세요.Mercurial에는 다음을 입력하여 활성화할 수 있는 간단한 http 서버도 포함되어 있습니다.
hg serve
그리고 다른 사람들이 귀하의 저장소를 탐색할 수 있도록 하십시오.
결론은 Git이 Mercurial이 수행하는 작업을 훨씬 더 복잡한 방식과 훨씬 낮은 CLI를 사용하여 수행한다는 것입니다.프로젝트의 VCS를 과학 연구 분야로 전환하려면 Git을 사용하세요.VCS 작업을 크게 신경 쓰지 않고 완료하고 실제 작업에 집중하려면 Mercurial을 사용하십시오.
