Mercurial과 Git의 차이점은 무엇입니까?
저는 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은 이러한 가닥에 이름을 추가하고 이러한 이름을 원격으로 쿼리 할 수 있습니다. 책갈피 의욕에 대한 확장은 지역 이름을 추가하고, 당신이 / 풀을 누르면 의욕 1.6, 당신은 주변이 책갈피를 이동할 수 있습니다 ..
나는 Linux를 사용하지만 TortoiseHg는 Windows의 Git보다 빠르고 낫습니다 (불량한 Windows 파일 시스템을 더 잘 사용하기 때문에). http://github.com 과 http://bitbucket.org 는 모두 온라인 호스팅을 제공하며 Bitbucket의 서비스는 훌륭하고 응답 성이 뛰어납니다 (github를 시도하지 않았습니다).
Mercurial은 깨끗하고 우아하기 때문에 선택했습니다. Git에서 얻은 shell / Perl / Ruby 스크립트 때문에 미루 었습니다. 내가 의미하는 바를 알고 싶다면 git-instaweb.sh파일을 살펴보십시오 . 웹 서버를 실행하는 Ruby 스크립트 를 생성하는 쉘 스크립트입니다 . 쉘 스크립트는 첫 번째 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을 사용하려고하면 어느 시점에서 혼란 스러울 것입니다 (매우 기본적인 기능 만 고수하지 않는 한). 일상적인 프로그래밍 루틴을위한 DVCS 만 있으면 어리석게 들릴 수 있지만, git의 천재성은 저장소 형식이 실제로 매우 간단하고 git의 전체 작업을 매우 쉽게 이해할 수 있다는 것입니다.
좀 더 기술 지향적 인 비교를 위해 개인적으로 본 최고의 기사는 Dustin Sallings의 다음과 같습니다.
He has actually used both DVCSs extensively and understands them both well – and ended up preferring git.
The big difference is on Windows. Mercurial is supported natively, Git isn't. You can get very similar hosting to github.com with bitbucket.org (actually even better as you get a free private repository). I was using msysGit for a while but moved to Mercurial and been very happy with it.
If you are a Windows developer looking for basic disconnected revision control, go with Hg. I found Git to be incomprehensible while Hg was simple and well integrated with the Windows shell. I downloaded Hg and followed this tutorial (hginit.com) - ten minutes later I had a local repo and was back to work on my project.
I think the best description about "Mercurial vs. Git" is:
"Git is Wesley Snipes. Mercurial is Denzel Washington"
They are almost identical. The most important difference, from my point of view (I mean, the reason that got me to choose one DVCS over the other) is how the two programs manage branches.
To start a new branch, with Mercurial, you simply clone the repository to another directory and start developing. Then, you pull and merge. With git, you have to explicitly give a name to the new topic branch you want to use, then you start coding using the same directory.
In short, each branch in Mercurial needs its own directory; in git you usually work in on single directory. Switching branches in Mercurial means changing directories; in git, it means asking git to change the directory's content with git checkout.
I'm honest: I don't know if it's possible to do the same with Mercurial, but since I usually work on web projects, using always the same directory with git seems much confortable to me, since I don't have to re-configure Apache and restart it and I don't mess my filesystem everytime I branch.
Edit: As Deestan noted, Hg has named branches, which can be stored in a single repository and allow the developer to switch branches within the same working copy. git branches are not exactly the same as Mercurial named branches, anyway: they are permanent and not throw away branches, like in git. That means that if you use a named branch for experimental tasks even if you decide to never merge it it will be stored in the repository. That's the reason why Hg encourages to use clones for experimental, short-running tasks and named branches for long-running tasks, like for release branches.
The reason why a lot of Hg users prefere clones over named branch is much more social or cultural than technical. For example, with last versions of Hg, it's even possible to close a named branch and recursively remove metadata from changesets.
On the other side, git invites to use "named branches" which are not permanent and are not stored as metadata on each changeset.
From my personal point of view, then, git's model is deeply linked to the concept of named branches and switch between a branch and another withing the same directory; hg can do the same with named branches, but yet it encourages the use of clones, which I personally don't like too much.
There's one huge difference between git and mercurial; the way the represent each commit. git represents commits as snapshots, while mercurial represents them as diffs.
What does this means in practice? Well, many operations are faster in git, such as switching to another commit, comparing commits, etc. Specially if these commits are far away.
AFAIK there's no advantage of mercurial's approach.
Nothing. They both do the same, both perform about equally. The only reason you should choose one over the other is if you help out with a project that already uses one..
The other possible reason for choosing one is an application or service which only supports one of the system.. For example, I pretty much chose to learn git because of github..
Also google's comparison (though it's a bit old, done in 2008)
http://code.google.com/p/support/wiki/DVCSAnalysis
If I understand them correctly (and I'm far from an expert on each) they fundamentally each have a different philosophy. I first used mercurial for 9 months. Now I've used git for 6.
hg is version control software. It's main goal is to track versions of a piece of software.
git is a time based file system. It's goal is to add another dimension to a file system. Most have files and folders, git adds time. That it happens to work awesome as a VCS is a byproduct of its design.
In hg, there's a history of the entire project it's always trying to maintain. By default I believe hg wants all changes to all objects by all users when pushing and pulling.
In git there's just a pool of objects and these tracking files (branches/heads) that determine which set of those objects represent the tree of files in a particular state. When pushing or pulling git only sends the objects needed for the the particular branches you are pushing or pulling, which is a small subset of all objects.
As far as git is concerned there is no "1 project". You could have 50 projects all in the same repo and git wouldn't care. Each one could be managed separately in the same repo and live fine.
Hg's concept of branches is branches off the main project or branches off branches etc. Git has no such concept. A branch in git is just a state of the tree, everything is a branch in git. Which branch is official, current, or newest has no meaning in git.
I don't know if that made any sense. If I could draw pictures hg might look like this where each commit is a o
o---o---o
/
o---o---o---o---o---o---o---o
\ /
o---o---o
A tree with a single root and branches coming off of it. While git can do that and often people use it that way that's not enforced. A git picture, if there is such a thing, could easily look like this
o---o---o---o---o
o---o---o---o
\
o---o
o---o---o---o
In fact in some ways it doesn't even make sense to show branches in git.
One thing that is very confusing for the discussion, git and mercurial both have something called a "branch" but they are not remotely the same things. A branch in mercurial comes about when there are conflicts between different repos. A branch in git is apparently similar to a clone in hg. But a clone, while it might give similar behavior is most definitely not the same. Consider me trying these in git vs hg using the chromium repo which is rather large.
$ time git checkout -b some-new-branch
Switched to new branch 'some-new-branch'
real 0m1.759s
user 0m1.596s
sys 0m0.144s
And now in hg using clone
$ 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
Both of those are hot runs. Ie, I ran them twice and this is the second run. hg clone is the actually the same as git-new-workdir. Both of those make an entirely new working dir almost as though you had typed cp -r project project-clone. That's not the same as making a new branch in git. It's far more heavy weight. If there is true equivalent of git's branching in hg I don't know what it is.
I understand at some level hg and git might be able to do similar things. If so then there is a still a huge difference in the workflow they lead you to. In git, the typical workflow is to create a branch for every feature.
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
That just created 3 branches, each based off a branch called master. (I'm sure there's some way in git to make those 1 line each instead of 2)
Now to work on one I just do
git checkout fix-game-save-bug
and start working. Commit things, etc. Switching between branches even in a project as big as chrome is nearly instantaneous. I actually don't know how to do that in hg. It's not part of any tutorials I've read.
One other big difference. Git's stage.
Git has this idea of a stage. You can think of it as a hidden folder. When you commit you only commit what's on the stage, not the changes in your working tree. That might sound strange. If you want to commit all the changes in your working tree you'd do git commit -a which adds all the modified files to the stage and then commits them.
What's the point of the stage then? You can easily separate your commits. Imagine you edited joypad.cpp and gamesave.cpp and you want to commit them separately
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 even has commands to decide which particular lines in the same file you want to copy to the stage so you can split up those commits separately as well. Why would you want to do that? Because as separate commits others can pull only the ones they want or if there was an issue they can revert just the commit that had the issue.
There is a dynamic comparison chart over at the versioncontrolblog where you can compare several different version control systems.
Here is a comparison table between git, hg and bzr.
There are quite significant differences when it comes to working with branches (especially short-term ones).
It is explained in this article (BranchingExplained) which compares Mercurial with Git.
Are there any Windows-based collaborators on your project?
Because if there are, the Git-for-Windows GUI seems awkward, difficult, unfriendly.
Mercurial-on-Windows, by contrast, is a no-brainer.
One thing to notice between mercurial of bitbucket.org and git of github is, mercurial can have as many private repositories as you want, but github you have to upgrade to a paid account. So, that's why I go for bitbucket which uses mercurial.
Sometime last year I evaluated both git and hg for my own use, and decided to go with hg. I felt it looked like a cleaner solution, and worked better on more platforms at the time. It was mostly a toss-up, though.
More recently, I started using git because of git-svn and the ability to act as a Subversion client. This won me over and I've now switched completely to git. I think it's got a slightly higher learning curve (especially if you need to poke around the insides), but it really is a great system. I'm going to go read those two comparison articles that John posted now.
I'm currently in the process of migrating from SVN to a DVCS (while blogging about my findings, my first real blogging effort...), and I've done a bit of research (=googling). As far as I can see you can do most of the things with both packages. It seems like git has a few more or better implemented advanced features, I do feel that the integration with windows is a bit better for mercurial, with TortoiseHg. I know there's Git Cheetah as well (I tried both), but the mercurial solution just feels more robust.
Seeing how they're both open-source (right?) I don't think either will be lacking important features. If something is important, people will ask for it, people will code it.
I think that for common practices, Git and Mercurial are more than sufficient. They both have big projects that use them (Git -> linux kernel, Mercurial -> Mozilla foundation projects, both among others of course), so I don't think either are really lacking something.
That being said, I am interested in what other people say about this, as it would make a great source for my blogging efforts ;-)
There is a great and exhaustive comparison tables and charts on git, Mercurial and Bazaar over at InfoQ's guide about DVCS.
I realize this isn't a part of the answer, but on that note, I also think the availability of stable plugins for platforms like NetBeans and Eclipse play a part in which tool is a better fit for the task, or rather, which tool is the best fit for "you". That is, unless you really want to do it the CLI-way.
Both Eclipse (and everything based on it) and NetBeans sometimes have issues with remote file systems (such as SSH) and external updates of files; which is yet another reason why you want whatever you choose to work "seamlessly".
I'm trying to answer this question for myself right now too .. and I've boiled down the candidates to Git or Mercurial .. thank you all for providing useful inputs on this topic without going religious.
Yet another interesting comparison of mercurial and git: Mercurial vs Git. Main focus is on internals and their influence on branching process.
If you are interested in a performance comparison of Mercurial and Git have a look at this article. The conclusion is:
Git and Mercurial both turn in good numbers but make an interesting trade-off between speed and repository size. Mercurial is fast with both adds and modifications, and keeps repository growth under control at the same time. Git is also fast, but its repository grows very quickly with modified files until you repack — and those repacks can be very slow. But the packed repository is much smaller than Mercurial's.
The mercurial website has a great description of the similarities and differences between the two systems, explaining the differences of vocabulary and underlying concepts. As a long time git user, it really helped my understand the Mercurial mindset.
If you are migrating from SVN, use Mercurial as its syntax is MUCH more understandable for SVN users. Other than that, you can't go wrong with either. But do check GIT tutorial and HGinit before selecting one of them.
This link may help you to understand the difference http://www.techtatva.com/2010/09/git-mercurial-and-bazaar-a-comparison/
Some people think that VCS systems have to be complicated. They encourage inventing terms and concepts on the field. They would probably think that numerous PhDs on the subject would be interesting. Among those are probably the ones that designed Git.
Mercurial is designed with a different mentality. Developers should not care much about VCS, and they should instead spend their time on their main function: software engineering. Mercurial allows users to use and happily abuse the system without letting them make any non-recoverable mistakes.
Any professional tool must come with a clearly designed and intuitive CLI. Mercurial users can do most of the work by issuing simple commands without any strange options. In Git double dash, crazy options are the norm. Mercurial has a substantial advantage if you are a CLI person (and to be honest, any self-respecting Software Engineer should be).
To give an example, suppose you do a commit by mistake. You forgot to edit some files. To undo you action in Mercurial you simply type:
$ hg rollback
You then get a message that the system undos your last transaction.
In Git you have to type:
$ git reset --soft HEAD^
So ok suppose you have an idea what reset is about. But in addition you have to know what "--soft" and "--hard" resets are (any intuitive guesses?). Oh and of course don't forget the '^' character in the end! (now what in Ritchie's name is that...)
Mercurial's integration with 3rd party tools like kdiff3 and meld is much better as well. Generate your patches merge your branches without much fuss. Mercurial also includes a simple http server that you activate by typing
hg serve
And let others browse your repository.
The bottom line is, Git does what Mercurial does, in a much more complicated way and with a far inferior CLI. Use Git if you want to turn the VCS of your project into a scientific-research field. Use Mercurial if you want to get the VCS job done without caring much about it, and focus on your real tasks.
참고URL : https://stackoverflow.com/questions/35837/what-is-the-difference-between-mercurial-and-git
'Development Tip' 카테고리의 다른 글
| Ruby에서 임의의 문자열을 생성하는 방법 (0) | 2020.09.29 |
|---|---|
| Java에서 문자열을 어떻게 비교합니까? (0) | 2020.09.29 |
| 내 Android 애플리케이션에서 충돌 데이터를 얻으려면 어떻게해야합니까? (0) | 2020.09.29 |
| 피아노 키보드를 컴퓨터 키보드로 사용 (0) | 2020.09.29 |
| 색상이 다른 표준 Android 버튼 (0) | 2020.09.29 |