Mercurial과 Git의 차이점은 무엇입니까?
Windows(msysGit)에서 Git을 사용한 지 꽤 됐는데 분산 소스 컨트롤이라는 아이디어가 마음에 들어요.최근에 Mercurial(hg)을 보고 있는데 신기해 보여요.그러나 나는 hg와 git의 차이를 이해할 수 없다.
git과 hg를 나란히 비교한 사람이 있나요?팬보이 토론에 뛰어들 필요 없이 hg와 git의 차이점을 알고 싶습니다.
다음의 문서를 참조해 주세요.
- Git vs. Mercurial: 긴장을 푸십시오(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에 상당하는 파일 시스템보다 빠르고 좋은 것 같습니다.http://github.com과 http://bitbucket.org은 모두 온라인 호스팅을 제공하고 있으며, Bitbucket의 서비스는 훌륭하고 응답성이 뛰어납니다(Github을 사용해 본 적이 없습니다).
깔끔하고 우아한 느낌으로 머큐리얼을 선택했습니다.Git에서 얻은 셸/페를/루비의 스크립트에 끌렸습니다.내 말이 무슨 뜻인지 알고 싶다면 파일을 한번 보세요.이것은 웹 서버를 실행하는 Ruby 스크립트를 생성하는 셸 스크립트입니다.셸 스크립트는 다른 셸 스크립트를 생성하여 첫 번째 Ruby 스크립트를 실행합니다.Perl도 조금 있어요.
Mercurial과 Git을 James Bond와 MacGyver와 비교한 블로그 투고가 마음에 듭니다.Mercurial은 Git보다 다소 저자세입니다.내가 보기엔 머큐리얼을 사용하는 사람들은 그렇게 쉽게 감동하지 않는 것 같아.이것은 각 시스템이 어떻게 라이너스가 "역대 가장 멋진 병합!"이라고 묘사한 것을 수행하는지 반영된다.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이 중단되기 때문에 필요합니다.이런 차이가 머큐리알을 더 우아하게 보이게 한다.
Git은 플랫폼이고 Mercurial은 어플리케이션일 뿐입니다.Git은 DVCS 앱과 함께 배송되는 버전화된 파일 시스템 플랫폼이지만, 플랫폼 앱의 경우 일반적인 경우처럼 포커스 앱보다 복잡하고 엣지가 거칠다.하지만 이것은 또한 Git의 VCS가 매우 유연하다는 것을 의미하며, git으로 할 수 있는 소스 제어 이외의 작업이 매우 많다는 것을 의미합니다.
그것이 차이의 본질이다.
Git은 저장소 형식부터 처음부터 가장 잘 이해됩니다.Scott Chacon의 Git Talk는 이를 위한 훌륭한 입문서이다.만약 당신이 후드 아래에서 무슨 일이 일어나고 있는지 모른 채 git을 사용하려고 한다면, 당신은 어느 순간 혼란스러워질 것입니다(매우 기본적인 기능만을 고집하지 않는 한).매일의 프로그래밍 루틴을 위한 DVCS만 있으면 바보같이 들릴지 모르지만, git의 천재성은 저장소 포맷이 실제로 매우 단순하고 git의 전체 조작을 매우 쉽게 이해할 수 있다는 것입니다.
좀 더 기술적인 비교를 위해 개인적으로 본 최고의 기사는 Dustin Sallings입니다.
그는 실제로 두 개의 DVCS를 폭넓게 사용해 왔고 둘 다 잘 이해했고 결국 git를 선호하게 되었다.
큰 차이는 Windows에 있습니다.Mercurial은 네이티브로 지원되지만 Git은 지원되지 않습니다.bitbucket.org을 사용하면 github.com과 매우 유사한 호스팅을 할 수 있습니다(실제로 무료 개인 저장소를 얻을수록 더 좋습니다).한동안 msysGit을 사용하다가 Mercurial로 옮겨서 매우 만족했습니다.
기본적인 절단 리비전 제어를 필요로 하는 Windows 개발자는 Hg를 선택합니다.Hg는 단순하고 Windows 쉘과 잘 통합되어 있는 반면 Git은 이해할 수 없다는 것을 알았습니다.저는 Hg를 다운로드하여 이 튜토리얼(hginit.com)을 따라 했습니다.10분 후에 로컬 레포(repo)가 있어서 다시 프로젝트에 착수했습니다.
나는 "Mercurial vs"에 대한 가장 좋은 설명이 있다고 생각한다.Git"은 다음과 같습니다.
"깃은 웨슬리 스나입스입니다.머큐럴은 덴젤 워싱턴입니다.
그들은 거의 같다.가장 중요한 차이점은 두 프로그램이 브랜치를 관리하는 방식입니다(즉, 어떤 DVCS를 선택하게 된 이유).
Mercurial을 사용하여 새 분기를 시작하려면 저장소를 다른 디렉토리에 복제하고 개발을 시작하십시오.그런 다음, 끌어당기고 병합합니다.git에서는, 사용하고 싶은 새로운 토픽 브랜치에 명시적으로 이름을 붙이고 나서, 같은 디렉토리를 사용해 코딩을 개시합니다.
즉, Mercurial의 각 브랜치에는 독자적인 디렉토리가 필요합니다.git에서는 보통 단일 디렉토리에서 작업합니다.Mercurial에서 브랜치 전환은 디렉토리를 변경하는 것을 의미하며, git에서는 git checkout에서 git 디렉토리의 내용을 변경하도록 git에게 요청하는 것을 의미합니다.
저는 정직합니다.Mercurial에서도 같은 작업을 할 수 있을지는 모르겠지만, 저는 보통 웹 프로젝트를 하기 때문에, 같은 디렉토리를 git과 함께 사용하는 것이 매우 편리할 것 같습니다.Apache를 재구성하거나 재시작할 필요도 없고, 브랜치를 할 때마다 파일 시스템을 망가뜨리는 일도 없기 때문입니다.
Edit: Deestan이 지적한 바와 같이 Hg는 브랜치를 명명하여 단일 저장소에 저장할 수 있으며 개발자는 동일한 작업 복사본 내에서 브랜치를 전환할 수 있습니다.어쨌든 git 브랜치는 Mercurial 이름 있는 브랜치와 완전히 동일하지는 않습니다.git처럼 영구적인 브랜치를 버리지 않습니다.즉, 이름 있는 브랜치를 실험 태스크에 사용하면 Marge하지 않기로 결정한 경우에도 해당 브랜치는 저장소에 브랜치가 저장소에 저장됩니다.그렇기 때문에 Hg는 실험적인 단기 작업에는 클론을 사용하고 릴리스 브랜치 등 장기 작업에는 브랜치를 지정하도록 권장하고 있습니다.
많은 HG 사용자가 명명된 지점보다 클론을 선호하는 이유는 기술보다는 훨씬 더 사회적 또는 문화적입니다.예를 들어 마지막 버전의 Hg에서는 지정된 분기를 닫고 변경 집합에서 메타데이터를 반복적으로 제거할 수도 있습니다.
반면 git은 영구적이지 않고 각 변경사항 집합에 메타데이터로 저장되지 않는 "이름 있는 분기"를 사용하도록 초대합니다.
제 개인적인 관점에서 보면, git의 모델은 이름 있는 브랜치의 개념과 밀접하게 관련되어 있고, 같은 디렉토리를 가진 브랜치와 다른 브랜치를 전환할 수 있습니다.hg는 이름 있는 브랜치에 대해서도 같은 작업을 할 수 있지만, 저는 개인적으로 클론의 사용을 장려하고 있습니다.
git와 mercurial 사이에는 하나의 큰 차이가 있다.그것은 각각을 나타내는 방식이다.git은 커밋을 스냅샷으로 나타내며 mercurial은 diff로 나타냅니다.
이것은 실제로 무엇을 의미합니까?글쎄요, 다른 커밋으로 전환하거나 커밋을 비교하는 등 많은 작업이 git에서 더 빠릅니다.특히 이 약속들이 멀리 있다면.
AFAIK는 수은주 접근법의 장점이 없다.
아무 것도 없어요.둘 다 똑같이 하고, 둘 다 거의 똑같이 합니다.다른 프로젝트보다 하나를 선택해야 하는 유일한 이유는 이미 하나를 사용하고 있는 프로젝트를 지원하는 경우입니다.
또 다른 가능한 이유는 시스템 중 하나만을 지원하는 애플리케이션 또는 서비스입니다.예를 들어, 나는 gitub 때문에 git를 배우기로 거의 선택했다.
또한 구글의 비교(2008년에 완료)
http://code.google.com/p/support/wiki/DVCSAnalysis
내가 그것들을 올바르게 이해한다면(그리고 나는 각각의 전문가와는 거리가 멀다), 그들은 근본적으로 서로 다른 철학을 가지고 있다.나는 처음에 9개월 동안 수은주를 사용했다.이제 git를 6개 사용했어요.
hg는 버전 제어 소프트웨어입니다.주요 목표는 소프트웨어 버전을 추적하는 것입니다.
git은 시간 기반 파일 시스템입니다.파일 시스템에 다른 차원을 추가하는 것이 목표입니다.대부분은 파일과 폴더를 가지고 있고 git은 시간을 더한다.VCS는 설계의 부산물입니다.
hg에는 항상 유지하려고 하는 프로젝트 전체의 역사가 있습니다.디폴트로는 밀고 당길 때 모든 사용자가 모든 오브젝트를 변경하기를 원합니다.
git에는 특정 상태의 파일 트리를 나타내는 오브젝트 세트를 결정하는 오브젝트 풀과 트래킹 파일(브랜치/헤드)이 있습니다.push 또는 pulling git은 모든 오브젝트의 작은 서브셋인 특정 브랜치에 필요한 오브젝트만 보냅니다.
git에 관한 한 "1개의 프로젝트"는 없습니다.50개의 프로젝트를 모두 같은 레포에 넣을 수 있지만, git은 상관하지 않습니다.각각은 같은 레포에서 개별적으로 관리되어 잘 살 수 있었다.
Hg의 브랜치 컨셉은 메인 프로젝트의 브랜치 또는 브랜치 등의 브랜치입니다.Git에는 그런 개념이 없다.git의 브랜치는 트리의 상태일 뿐이며, 모든 것은 git의 브랜치입니다.공식, 최신, 최신 중 어느 브랜치가 git에 의미가 없습니다.
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★ 수 hg이다, hg이다, 수 .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의 클론과 유사합니다.하지만 클론은 비슷한 행동을 할 수 있지만, 대부분 같지는 않습니다.크롬 repo를 사용하여 git vs 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-new-workdir를 사용하다두 가지 모두 '다 하다'를 입력한 새로운 디르입니다.cp -r project project-clone그것은 git에 새로운 브랜치를 만드는 것과는 다릅니다.훨씬 더 무거워요.한 것이 나는 인지 모른다.hg git 의 의 、 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
일을 시작합시다.커밋 등크롬만 한 프로젝트에서도 지점 간 전환은 거의 순식간에 이루어집니다.사실 어떻게 하는지 모르겠어요.제가 읽은 튜토리얼의 일부가 아닙니다.
또 다른 큰 차이점이 있습니다.Git의 무대.
Git git git git git git git git git git 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에는, 같은 파일의 어느 특정의 행을 스테이지에 카피할지를 결정하는 커맨드도 준비되어 있기 때문에, 커밋을 개별적으로 분할할 수도 있습니다.왜 그렇게 하고 싶어 하는데?다른 커밋은 다른 커밋으로 원하는 커밋만 가져올 수 있습니다.또한 문제가 발생한 커밋만 되돌릴 수 있습니다.
version controlblog에는 여러 가지 다른 버전 제어 시스템을 비교할 수 있는 동적 비교 차트가 있습니다.
지점(특히 단기 지점)과 관련된 작업에는 상당한 차이가 있습니다.
Mercurial과 Git을 비교한 이 기사(Branching Descried)에 설명되어 있습니다.
프로젝트에 Windows 기반 공동작업자가 있습니까?
만약 있다면, Git-for-Windows GUI는 어색하고, 어렵고, 불친절해 보이기 때문이다.
반면 Windows에서의 Mercurial-on-Windows는 쉬운 일입니다.
bitbucket.org의 mercurial과 github의 git 사이에서 주목할 점은 mercurial은 원하는 만큼 개인 저장소를 가질 수 있지만 github은 유료 계정으로 업그레이드해야 한다는 것입니다.그래서 저는 수은을 사용한 비트버킷을 선택하게 되었습니다.
작년 언젠가 나는 git과 hg를 모두 내 자신의 용도로 평가하여 hg로 결정했다.보다 깔끔한 솔루션이라고 느꼈고, 그 당시에는 더 많은 플랫폼에서 더 잘 작동했습니다.하지만 대부분 엎치락뒤치락이었다.
최근에는 git-svn과 Subversion 클라이언트의 기능 때문에 git을 사용하기 시작했습니다.이것이 나를 설득했고, 나는 이제 완전히 git로 전환했다.조금 더 높은 학습 곡선을 가지고 있다고 생각합니다(특히 속을 들여다볼 필요가 있는 경우). 하지만 정말 훌륭한 시스템입니다.저는 지금 존이 올린 두 개의 비교 기사를 읽으러 갑니다.
저는 현재 SVN에서 DVCS로 이행하고 있으며(제 조사결과에 대한 블로그 작성 중, 첫 번째 블로그 작성 등), 약간의 조사(=구글링)를 하고 있습니다.제가 보기에는 두 패키지로 대부분의 작업을 할 수 있습니다.git에는 몇 가지 고급 기능이 더 있거나 더 잘 구현되어 있는 것 같습니다만, TortoiseHg와의 통합이 머큐리얼에 있어서 조금 더 좋다고 생각합니다.Git Cheetah도 있다는 것을 알고 있습니다만(둘 다 시도해 보았습니다), Mercurial 솔루션이 더 견고하게 느껴집니다.
둘 다 오픈 소스인 것을 알 수 있습니다(맞습니까?).둘 다 중요한 기능이 부족하지 않을 것 같아요.중요한 게 있으면 사람들이 요청하고 암호를 만들 거야
일반적인 프랙티스라면 Git과 Mercurial로도 충분하다고 생각합니다.둘 다 이들을 사용하는 큰 프로젝트(Git -> Linux 커널, Mercurial -> Mozilla Foundation 프로젝트 등)를 가지고 있기 때문에 둘 다 부족하다고는 생각하지 않습니다.
그렇지만, 제 블로그 활동의 훌륭한 소스가 될 수 있기 때문에, 다른 사람의 의견에도 흥미가 있습니다.
DVCS에 대한 InfoQ의 가이드에는 git, Mercurial, Baza에 대한 훌륭하고 포괄적인 비교표와 차트가 있습니다.
이것이 해답의 일부가 아닌 것은 알지만, NetBeans나 Eclipse와 같은 플랫폼에 안정된 플러그인을 사용할 수 있는 것은 어떤 툴이 작업에 더 적합한지, 혹은 어떤 툴이 "귀사"에 가장 적합한지에 대한 부분이라고 생각합니다.즉, CLI 방식으로 실행할 필요가 없는 한 그렇게 할 수 있습니다.
Eclipse(및 이에 기반한 모든 것)와 NetBeans 모두 리모트 파일 시스템(SSH 등)과 파일의 외부 업데이트에 문제가 발생할 수 있습니다.이것은, 「심리스하게」 동작하도록 선택하는 또 다른 이유입니다.
나도 지금 이 질문에 답하려고 노력 중이야.후보자를 Git 또는 Mercurial로 압축했습니다.종교에 얽매이지 않고 이 주제에 대해 유익한 의견을 제공해 주셔서 감사합니다.
그러나 수은과 git의 또 다른 흥미로운 비교:Mercurial vs Git.주요 초점은 내부와 분기 프로세스에 대한 내부 영향입니다.
만약 당신이 Mercurial과 Git의 성능 비교에 관심이 있다면 이 기사를 보세요.결론은 다음과 같습니다.
Git과 Mercurial은 둘 다 좋은 수를 가지고 있지만 속도와 저장소 크기 사이에서 흥미로운 균형을 이룬다.Mercurial은 추가 및 수정이 모두 빠르며 동시에 저장소 증가를 억제합니다.Git도 빠르지만, 리패킹할 때까지 파일을 수정하면 저장소가 매우 빠르게 커집니다.그리고 리패킹은 매우 느릴 수 있습니다.하지만 꽉 찬 저장소는 머큐리얼 저장소보다 훨씬 작습니다.
이 머큐리얼 웹사이트에는 어휘와 기본 개념의 차이를 설명하면서 두 시스템 간의 유사점과 차이점에 대한 훌륭한 설명이 있다.오랜 git 사용자로서 Mercurial 마인드를 이해하는 데 큰 도움이 되었습니다.
SVN에서 이행하는 경우 Mercurial 구문을 SVN 사용자가 훨씬 쉽게 이해할 수 있으므로 Mercurial을 사용하십시오.그것 말고는 틀릴 수 없어요.단, GIT 튜토리얼과 HGinit 중 하나를 선택하기 전에 확인하시기 바랍니다.
이 링크는 차이를 이해하는 데 도움이 될 수 있습니다.http://www.techtatva.com/2010/09/git-mercurial-and-bazaar-a-comparison/
VCS 시스템이 복잡해야 한다고 생각하는 사람도 있습니다.그들은 현장에서 용어와 개념을 발명할 것을 장려한다.그들은 아마도 그 주제에 대한 수많은 박사학위가 흥미로울 것이라고 생각할 것이다.그 중에는 Git을 디자인한 것도 있을 것입니다.
Mercurial은 다른 사고방식으로 설계되었다.개발자는 VCS에 크게 신경 쓰지 말고 주요 기능인 소프트웨어 엔지니어링에 시간을 할애해야 합니다.Mercurial은 사용자가 복구할 수 없는 실수를 저지르지 않고 시스템을 사용하고 악용할 수 있도록 합니다.
모든 프로페셔널 툴에는 명확한 설계와 직관적인 CLI가 필요합니다.Mercurial 사용자는 이상한 옵션 없이 간단한 명령어를 발행하여 대부분의 작업을 수행할 수 있습니다.Git 더블 대시에서는 크레이지 옵션이 표준입니다.CLI 담당자라면 Mercurial이 상당히 유리합니다(솔직히 말하면 자존심이 강한 소프트웨어 엔지니어는 누구나 필요합니다).
예를 들어 실수로 커밋을 실행했다고 가정합니다.일부 파일을 편집하지 않았습니다.Mercurial에서 작업을 취소하려면 다음과 같이 입력합니다.
$ hg rollback
그러면 시스템이 마지막 트랜잭션을 취소했다는 메시지가 나타납니다.
Git에서 다음을 입력해야 합니다.
$ git reset --soft HEAD^
그럼 리셋에 대해 알고 있다고 가정해 보겠습니다.또, 「--soft」리셋과 「--hard」리셋에 대해서도 알고 있을 필요가 있습니다(직감적인 추측은 없습니까?).아, 그리고 물론 마지막에 '^'자를 잊지 마세요! (리치의 이름은...)
Mercurial은 kdiff3 및 meld와 같은 서드파티 툴과의 통합도 훨씬 우수합니다.패치를 생성해, 브랜치를 큰 부담 없이 결합할 수 있습니다.Mercurial에는 다음과 같이 입력하여 활성화하는 단순한 http 서버도 포함되어 있습니다.
hg serve
또한 다른 사용자가 저장소를 탐색할 수 있습니다.
결론은 Git은 Mercurial이 하는 일을 훨씬 더 복잡한 방법으로 훨씬 열등한 CLI로 수행합니다.프로젝트의 VCS를 과학 연구 필드로 전환하려면 Git을 사용하십시오.VCS 작업을 크게 신경 쓰지 않고 실제 작업에 집중하려면 Mercurial을 사용합니다.
언급URL : https://stackoverflow.com/questions/35837/what-is-the-difference-between-mercurial-and-git
'programing' 카테고리의 다른 글
| .format(또는 f-string)을 사용하는 동안 문자열 내에서 컬리브레이스({}) 문자를 이스케이프하려면 어떻게 해야 합니까? (0) | 2023.04.16 |
|---|---|
| 'git diff'가 호출기를 사용하지 않도록 하려면 어떻게 해야 합니까? (0) | 2023.04.16 |
| Git 저장소의 이름을 변경하려면 어떻게 해야 합니까? (0) | 2023.04.16 |
| POI API를 사용하여 Excel에 백분율 값 표시 (0) | 2023.04.16 |
| 어떻게 하면 Excel의 따옴표를 대체 공식으로 바꿀 수 있을까요? (0) | 2023.04.16 |