힘내가 왜 과대 광고를 했습니까? … 다른 사람들은 그렇지 않습니까? [닫은]

최근 몇 년 동안, Git 주변의 과대 광고가 크게 증가했습니다. 모두 Git에 대해 알고 있으며, 대안에 대해서는 아무도 모른다.

Mercurial과 같은 다른 것들은 눈에 띄지 않는 것 같습니다. 둘 다 2005 년에 출시되었으며 유사한 기능을 제공합니다. 또한 Mercurial은 일반적으로 사용하기 쉽고 직관적이며 오랫동안 UI를 개선 한 것으로 간주됩니다. 따라서이 방법이 특히 분산 버전 제어를 처음 사용하는 사람들에게 인기있는 대안이라고 가정 할 수 있습니다. 그러나 성공한 Git과 달리 대부분의 사람들에게 알려지지 않은 것 같습니다.

이 포스트의 요점은이 현상을 더 잘 이해하는 것입니다.

Git은 어떻게 케이크의 모든 부분을 가져 옵니까? 그들은 어떻게 든 더 나은 마케팅을 사용 했습니까? 지역 사회가 더 많기 때문에 ... "자세한 것"입니까? "Linus"이름 때문입니까? 괴짜 이미지 때문입니까?

당신의 의견은 무엇입니까?

GitHub 또는 Gitorious 와 같은 서비스 가 큰 요소 라고 생각합니다 . 사람들이 어딘가에서 물건을 호스팅 할 수있는 것이 중요하며 특히 GitHub는 훌륭한 서비스입니다.

수은의 경우 DVCS가 인기를 얻었을 때 그러한 서비스는 없었습니다 (적어도 내가 아는 바는 없었습니다). 당신이 의 Bitbucket 지금 아마 다른 사람을하지만, GitHub의 꽤 많은 시간이 있었다, 그것은 잘 알려진 그리고 그것은 더 나은 가져옵니다.

나는 이것에 대한 많은 답변이 저자가 하나 또는 다른 SCM에 대해들을 때 느끼는 감정에 의존하는 것을 본다. 다른 사람들은 그것이 모두 행운이라고 말합니다. 나는 역사상 행운이 거슬러 올라갈 수 있다고 생각합니다.

나는 역사에 대해 이야기 할 것입니다.

동일한 문제를 해결하기 위해 Git 과 Mercurial 이 동시에 생성되었습니다. 당시 리눅스 커널은 3 년 동안 사용했던 독점 분산 형 SCM 인 BitKeeper의 사용을 중단해야 했습니다. 그 이유는 BitKeeper의 회사 인 BitMover의 CEO 인 Larry McVoy가 Linux 커뮤니티의 누군가가 리버스 엔지니어링을했기 때문에 소프트웨어를 Linux 개발자에게 무료로 제공하지 않기 때문입니다.

이미 존재하는 것에 불만족 한 Linus Torvalds는 곧 새로운 GCM을 시작하여 곧 Git이라고 불렀습니다. 그 후 Matt Mackall은 비슷한 이유로 Mercurial 프로젝트를 시작했습니다.

Matt Mackall은 이러한 프로젝트를 개별적으로 개발 한 후 SCM의 고급 버전을 제시하고 특정 방식으로 벤치마킹하여 Git과 비교했습니다. Linus 는 커널 개발을 위해 Git 대신 Git 을 사용하는 것을 고려 했지만 Mercurial이 수정 세트를 기록하기 위해 Changesets를 사용하고 있다는 사실을 깨달았습니다 . 그는 이것이 BitKeeper가 작동하는 방식에 너무 가까워 두려웠으며 누군가 "BitKeeper 복제본을 만들었습니다"라고 말하는 것을 원하지 않았습니다.

따라서 Git은 Mercurial 대신 Kernel 개발에 사용되었지만 기술적으로 관련이있었습니다. 최종 결과는 Git이 실제로 사용되도록 설계된 곳에서 시작하여 시작되었지만 Mercurial은 처음 큰 FOSS 사용을 찾는 것만 큼 빠르지 않았습니다. 매우 훌륭한 디자인이 제공되었고 Matt Mackall의 인내 덕분에 결국 유명 해졌고 큰 실제 프로젝트에 사용되었습니다.

오늘날 그들은 유명합니다. 가장 유명한 것은 말할 수 없습니다. Google 코드는 최근 Git을 통합 한 반면 오랫동안 Mercurial을 사용했습니다. 정말 크고 유명한 프로젝트 중 하나를 사용합니다.

내 말은 프로젝트를 시작한 이유가 사라지면 인기를 얻는 것이 어렵지만 여전히 가능하다는 것입니다.

Bazaar 는 GNU 세계에서 매우 유명한 또 다른 SCM이지만 GNU 커뮤니티를 만족시키기위한 의도로 만들어 졌기 때문에 그다지 많지 않습니다. 소프트웨어는 종종 제작자가 가고 싶은 곳으로 이동합니다.

반면에 분산 SCM은 확실한 승자입니다. 널리 사용되는 비 분산 SCM이 많지 않습니다.

리누스 토발즈

Linus는 Git의 큰 옹호자이며 수년간 핵심 Linux 그룹으로 크게 홍보했으며 그곳에서 자랐습니다. 나는 이것이 전적으로 Linus가 * nix 커뮤니티에 미치는 영향 때문이라고 생각합니다.

개인적으로 나는 여전히 Subversion을 사용하지만 유틸리티보다는 환경 설정에서 나옵니다.

버전 관리 시스템의 일반적인 문제점은 지점 병합 입니다.

지사와 자유롭게 일하기 위해서는 그것이 얼마나 고통스럽고 일이 얼마나 중요한지를 이해하기 위해 노력 하지 않았을 때 그것을 시험해보아야합니다 .

Linus Torvalds 가이 작업을 올바르게 수행하기 위해 git을 작성했으며 한 가지 상황에서 git을 사용 하여 한 번에 12 개의 분기 를 병합했다는 사실 을 알면 git이 흥미 롭다는 매우 설득력있는 주장입니다.

나는 약 1 년 전에 hg와 git 중 하나를 선택 해야하는 상황에 있었고 위의 병합은 git를 선택하는 중요한 요소 중 하나였습니다. 두 번째는 Eclipse 조직이 git으로 전환했기 때문에 Eclipse 도구는 Java 프로젝트에 적합 할 것으로 예상되었습니다. Eclipse 3.7이 출시되면서 이런 일이 발생했습니다. 우리는 아마도 이것에 대해 6-9 개월 일찍 일어 났을 것입니다.

다른 필요에 따라 hg도 유용 할 수 있습니다. 썬은 매우 신중한 조사 를 통해 VCS로 선택했습니다 . 백서를 찾고 그들의 추론이 무엇인지 확인할 수 있습니다.

편집 : 참고, 나는 Mercurial이 할 수없는 일이 없다고 말하고 있지 않습니다. 이클립스가있는 Java의 경우-우리의 주요 초점입니다-현재 시장력은 Windows에서도 git에 가장 강력합니다. 우리는 어깨에서야합니다. 그들의 발이 아닌 다른 사람들의.

왜 git 또는 mercurial이 더 나은지 말하고 대중적인 유일한 이유를 말하는 대신 커뮤니티에 초점을 맞출 것입니다.

앞에서 강조했듯이 Git 커뮤니티는 매우 크고 거만합니다. 대부분의 소중한 프로그램을 적극적으로 방어 할 것입니다. 내가 본 Git vs Mercurial war의 대부분은 왜 지구상의 모든 사람들이 거룩한 git을 사용하지 않는지 궁금한 git 사람들에 의해 시작되었습니다. whygitisbetterthanx.com 과 같은 사이트 는 소개 에서이 오만을 보여 주며 다른 사람들을 화염으로 씁니다 .

나는 모든 사람들이 이런 식으로 말하는 것은 아니지만 대부분의 사람들은 git people, pro-git website 및 pro-git blogs를 만났을 때 git이 실행 가능한 DVCS로 제공되는 대신 목구멍 아래로 밀려 났다고 느꼈습니다. 체계.

반대로, 다른 DVCS 커뮤니티는 그다지 크지 않습니다. "최고의 DVCS는 무엇입니까?"를 볼 때까지 머큐리얼이 존재한다는 것을 몰랐습니다. SO에 대한 질문. git이 어디에나 나타나는 반면 다른 DVCS는 찾는 데 시간이 걸립니다.

나는 Mercurial이 특히 낮은 프로파일이라고 생각하지 않습니다. Kiln은 Hg를 기반으로하며 현재 Eclipse & Netbeans와 같은 IDE에서 잘 지원되었습니다.

필자가 이야기하는 대부분의 개발자는 더 나은 Windows 지원 때문에 Hg를 선호하는 것 같습니다. 우리가 Linux 개발자라면 다른 이야기 일 수 있습니다.

당신은 또한 "잊혀진 DVCS"인 "바자"를 놓치고 있습니다.

확실히 나는 Linus가 매우 카리스마 넘치는 사람이며 거의 동등하지 않은 알파 괴상한 사람이므로 많은 사람들이 Git에 끌리게된다는 것에 동의합니다. 또한, Git의 "창조 신화"는 Linus가 6 일 동안 Git을 만들고 7 일 또는 그와 비슷한 것을 만들기 위해 노력하는 데 매우 효과적입니다. 제품에 기억에 남는 이야기가 있으면 견인력을 얻는 것이 더 쉽습니다.

그것은 겸손한 의견이지만, git은 두 가지 매개 변수 때문에이 과대 광고를 얻을 수 있습니다.

1. 매우 효율적입니다
2. 사용하는 것이 즐겁습니다 (어떤 종류의 컴퓨터 과학자의 방식으로)

또한 git은 github와 같은 킬러 응용 프로그램을 얻었으며 매우 인기있는 일부 프로젝트에서 사용하기로 결정하여 많은 가시성을 얻었습니다.

여기에는 "베타 괴짜 미디어", "시간이 옳다", "리더를 따르라"라는 세 가지 요소가 있습니다.

베타 eek 미디어

"유쾌한 활동"에 대해 토론 할 수있는 여러 채널이 있습니다. 그들은 분명히 새로운 버전 제어 시스템의 외관을 다룰 것이지만, 더 많은 것을 다루고 있습니다. 왜? Linus Torvalds는 처음에이 글을 썼기 때문에 공개적으로 논쟁을 벌였으며 비트 키퍼에 대한 잘 알려진 문제에 대한 해결책으로 사용했습니다. 효과적으로, lkml에 화염 전쟁이 발생할 때마다 베타 괴짜 미디어가 그것에 관한 기사를 쓸 것입니다. Git 토론은 lkml에서 시작되었으므로 다른 대안보다 더 많은 내용을 다루었습니다. 그리고 버라이어티 처럼 슬래시닷을 읽는 베타 괴짜들은 그것을 먹었습니다. 그 결과로 git은 수은보다 10 배나 많은 기사가 있습니다.

시간이 맞아

기여자가 많은 대규모 오픈 소스 프로젝트에는 중앙 집중식 소스 제어에 문제가 있습니다. 오픈 소스가 커지고 프로젝트에 많은 기여자가있을 가능성이 높아짐에 따라 문제는 더욱 악화됩니다. 리눅스는 아마도 이것으로 고통받는 가장 잘 알려진 프로젝트이지만 다른 것들도 많이 있습니다. 많은 프로젝트가이 시점에 도달하면서 일종의 고급 VCS가 필요했습니다. Git, Mercurial 및 Bazaar가 큰 승자였습니다. 아치와 모노톤은 너무 일찍 시작되어 과대 광고를 놓쳤다.

지도자를 따르십시오

대규모 프로젝트에는 기여하지 않더라도 정기적으로 코드를 체크 아웃하고 빌드하는 팔로어가 있습니다. 추종자들은 자신이 따르는 프로젝트를 가져 오는 데 필요한 도구에 익숙해 지므로 더 많은 도구를 사용할 수 있습니다. 3 대 DVCS의 "큰 추첨"프로젝트를 살펴 보자.

• 힘내 : 리눅스, 펄, jQuery, 루비 온 레일즈, 이클립스, 그놈, KDE, QT, X
• 머큐리얼 : 자바, 모질라, 파이썬
• 바자 : 우분투, 이맥스

Git은 그것을 사용하는 더 많은 "큰 추첨"프로젝트를 가지고 있으므로 더 많은 사람들이 git에 익숙하고 더 많은 git tutorial이 작성되었습니다.

그것은 주로 자기 강화 과대 광고입니다. 힘내가 가장 인기가 많기 때문에 가장 인기가 높아 지므로 인기가 높아집니다.

Git, Hg 및 Bzr은 모두 완벽하게 훌륭한 DVCS 시스템이지만, 많은 사람들이 DVCS를 Git과 동일시하며 DVCS의 모든 멋진 기능이 Git에 고유하다고 생각합니다. 그래서입니다 ((그래서 할 수 바자), 또는 "이 분산되기 때문에 망할 놈이 낫다"그래서 그들은 힘내을 사용하고, "이 문어 병합을 할 수 있기 때문에 망할 놈이 낫다"같은 것들을 힘내을 추천하고, 말을 어떤 따라서, 이름 DVCS ) 또는 "분기 및 병합이 쉬워 지므로 Git이 더 좋습니다"(다시 말하면 이것은 모든 DVCS에 해당됩니다).

슬프게도, 대안이 많이 제공한다고 생각하기 때문에 사람들은 DVCS == Git이라고 생각하기보다는 오히려 고유 한 장점으로 Git을 선택하고 싶습니다.

누군가 특정 DVCS를 지적함으로써 DVCS가 얼마나 영리한지 알게되면 그들은 종종 다른 사람들에게 "이봐, DVCS는 훌륭하다. 당신은 그것들을 사용해야한다"고 말하는 대신 " 나는 DVCS를 DVCS에 대해 배운 것은 훌륭합니다. 사용해야합니다. "

깃 허브. Github는 소셜 코딩의 선구자입니다. 그것은 버전 관리를 많은 관심을 끌 수있는 소셜 플랫폼으로 바꾸 었으며 분명히 Git을 지원합니다. 소셜 미디어 = 더 큰 채택. Bitbucket은 많은 새로운 기능을 얻음에도 불구하고 증기를 얻고 있습니다.

사실 나는 과대 광고가 모든 DSVC에 관한 것이라고 생각합니다.

그러나 git 옹호자들은 더욱 성가 시며 종종 솔직하고 모든 곳에서 그것에 대해 이야기하는 그들의 의견에 더 적극적입니다.

나는 머큐리얼이 git만큼 자주 사용되는 것 같지만 아마도 마이크로 소프트와 다른 대기업들이 지금은 더 많이 사용하고 있다고 생각하지만 머큐리얼을 사용하는 사람들은 종교를 기반으로하는 것이 아니라 빠르게 파악할 수있는 DSVC를 원했을 뿐이다. 따라서 그들은 일부 git 사용자와 같이 사전 활동보다 토론에서 음성이 적고 반응이 좋습니다.

Bazaar는 잘 알려진 프로젝트가 거의없고 Canonical 이외의 다른 대기업도 사용하지 않기 때문에 Bazaar는 많은 이야기를하지 않습니다. 예를 들어 Google (git, mercurial, svn) 및 대규모 오픈 소스 프로젝트와 비교하면 실제로 논의되지 않은 이유를 확인할 수 있습니다. 화석은 개발자의 틈새 시장에 흥미로운 또 다른 것이므로, 제공되는 기능 (내장 위키, 이슈 추적 및 포럼과 같은)을 검색하는 사람들만이 들리는 것이 정상적이고 괜찮습니다.

즉, 우리는 과대 광고주기를 서서히 낮추고 있다고 생각 하며 여러 다른 솔루션을 사용한 많은 개발자가 자신의 요구에 맞는 것을 볼 수 있습니다.

또한 Google Code Hosting 및 SourceForge는 git과 mercurial을 모두 허용하므로 GitHub 기능으로 인해 git을 선택할 때보 다 프로젝트 고유의 선택이되고 있습니다.

실제 전쟁은 없으며 흥미로운 다양한 도구가 있습니다.

이 질문에 대한 답변이 이미 많이 있다는 것을 알고 있지만 조금 더 관점을 추가 할 수 있다고 생각했습니다.

Bazaar는 다양한 용도로 만들어 졌기 때문에 거의 사용했습니다. 내가 사용했던 가장 큰 것은 AllTray 프로젝트였으며, 현재는 유일한 개발자이자 관리자입니다. 바자는 멋지다. 그냥 작동하고 방해가되지 않으며 도움말 페이지 또는 매뉴얼 페이지를 볼 필요가 거의 없습니다. 그러나 몇 가지 단점이 있습니다.

1. 핵심 VCS의 일부가되어야 할 기능은 많지 않습니다. 이중 섹션 히스토리를 수행하거나, 호출기를 통해 긴 출력을 실행하거나, "배치 된"브랜치 (예 : git 스타일 저장소)를 갖는 기능은 플러그인으로 제공됩니다.
2. 많은 플러그인이 그다지 안정적인 것은 아닙니다. 예를 들어, 함께 배치 된 분기 기능은 서버 측에서 제대로 작동하지 않는 것 같습니다 (적어도 작동하지 않은 경우 주어진 경로의 분기가 존재하지 않는다고 말하는 오류가 발생하는 경향이 있습니다) 바로 앞에 당신은 피의 것을 볼 수 있습니다).
3. "복제"작업이 없으므로 분기를 한 번에 하나씩 당깁니다. 새로운 브랜치를 효율적으로 가져올 수 있도록 저장소를 원한다면 추가 작업을 수행해야합니다.
4. 일부 프로젝트의 경우 고통스럽게 느립니다. “bzr branch lp : mysql”을 언젠가 시도하십시오.
5. 후크에 대한 강력한 지원이 부족합니다. 후크를 제공하는 bzr 플러그인을 작성할 수 있지만 서버 측 임의 후크 스크립트를 갖는 표준 방법은 없습니다.

최근 AllTray 개발을 위해 git으로 전환했으며 모든 프로젝트를 git으로 마이그레이션하는 것을 매우 빠르게 고려 하고 있습니다. 로프를 알아내는 데 약간의 선행 시간이 있지만 그만한 가치가있는 것 같습니다. 내가 알아 차린 것들 :

1. git clone 비교적 빠른 조작이며 복제 한 저장소에 존재하는 모든 분기에 대한 정보를 제공합니다.
2. 추가 원격 리포지토리를 추가하는 것은 쉽지 않으므로 원하는 경우 여러 분기가있는 여러 리포지토리를 추적 할 수 있습니다.
3. 프로 힘내 책은 온라인으로 사용할 전자 책 리더를위한 포함한 여러 형식으로 장치 및 그 어려운 읽기 아닙니다.
4. git은 Bazaar보다 확장하기가 훨씬 쉬워 보이므로 특정 API를 사용할 필요가 없습니다. (NB : 이것은 단점과 단점입니다.)
5. git에는 bisection이 내장되어 있으며 해당 기능의 유용성을 충분히 강조 할 수 없습니다.
6. GitHub는 다소 좋습니다.
7. gitosis시스템은 아주 좋은 것입니다. Bazaar의 플러그인이 아닌 다른 방식으로 구현하는 방법조차 확실하지 않으며 효율적인 곳이 어디인지 상상할 수 없습니다.

짧은 이야기 : 나는 bzr을 오랫동안 사용했지만 git은 신속하게 그 위대함을 입증하고 있습니다.

git을 사용하면 개발 할 때 항상 동일한 로컬 디렉토리에 머무르는 경향이 있으며 단순히 분 기간 git checkout branchname을 전환하려고합니다 ( "경량"기능 분기를 항상 사용하므로 이것이 매우 중요한 기능입니다).

Mercurial 문서 및 자습서를 보면 다양한 개발 분야를 처리하는 데 선호되는 방법은 복제하여 새 리포지토리를 만드는 것입니다. 이 튜토리얼 은 예제입니다.

Mercurial에서 git에서와 동일한 작업을 수행 할 수 있다고 생각하지만 어떤 이유로 Mercurial 설명서 (내가 읽은)는 거의 항상 저장소 복제본을 만들어 분기를 표시합니다.

(나는 매일 자식을 사용합니다. 나는 수은에 대한 경험이 거의 없으며, 그것을 가지고 놀았고 몇 가지 튜토리얼을 따랐습니다)

나는 지난 몇 주 동안 내가 보았던 그런 진창이 얼마나 많은지 모르지만, 모두 머큐리 및 / 또는 바자회가 깃보다 객관적으로 낫다는 사실로 생각하는 것 같습니다. 유용성은 일반적인 주제 인 것 같습니다. 네, GV를 배우는 것은 CVS와 Subversion을 사용한 후에 놀랍도록 힘들었지 만이 시점에서 다른 패러다임 전환을 구성하지 않는 한 다른 VCS와 교환하고 싶지 않습니다 . 그리고 기능 표를 가리키면 유연성, 확장 성, 보안 성 또는 노력 이 어느 정도인지 거의 알 수 없습니다. 예를 들어, 기본적으로 git-diff 색상과 호출기가 사용됩니다. 물론 나는 똑같은 diff ... | colordiff | less -R것을 얻을 수 있지만 왜 한 사람이 다른 사람보다 우월한 지 분명해야합니다.

공정하게 말하자면, git vs. 수은 옹호자는 git vs. 그러나 그 이유는 요약하기 쉽습니다.

Git은 프로그래머를위한 버전 관리입니다. Mercurial은 기업용 버전 관리입니다. 중앙 집중화는 특히 개인용 컴퓨터 혁명 이전에 설계되었다는 점을 고려하여 버전 제어를 발명하기위한 적절한 첫 번째 시도였습니다.

프로그래머를위한 버전 관리의 의미는 프로그래머가 일반적으로 학습 용이성보다 유연성을 선호한다는 것입니다. 어쨌든, 우리는 컴퓨터가 훈련되지 않은 것을 할 수있는 유연성을 갖기 위해 난해한 언어를 배우는데 수년을 기꺼이 씁니다. Git은 프로그래머에게 유연성을 제공하지만 유연성을 안전하게 사용하는 방법을 배우는 데 시간이 오래 걸리므로 원하는대로 사용할 수 있습니다. 정책을 시행하기 위해 제한을 둘 수는 있지만 즉시 적용되지는 않습니다. 참고 나는 사용 편의성보다는 학습 용이성이라고 말했다 . 일단 배우면 git은 다른 VCS처럼 사용 하기 쉽고 속도와 기능이 향상되어 더 쉽습니다.

일부 프로그래머는 원하는 것을 수행하기에 충분히 배우고 새로운 방법을 배우지 않습니다. 기업은 이러한 직원을 많이 고용하고 고용하므로 사용하는 도구의 변경 사항이 어느 정도 익숙해지기를 원합니다. 또한 기업은 프로그래머가 업무를 수행 할 수있는 충분한 유연성을 갖기를 원하지만 교육이나 초기 마이그레이션을 어렵게 만들지는 않습니다. 이것은 수은이 들어가는 곳입니다. git의 대부분의 힘을 가지고 있지만 다소 쉬운 마이그레이션 경로입니다.

git이 과대 광고 또는 Linus의 승인으로 인해 인기가 있다고 말하는 것이 공정하다고 생각하지 않습니다. 그것은 아마도 많은 사람들이 그것을 시도 하고 있지만, 그것을 순수하고 단순하게 잘 활용하기 때문에 그것을 고수하고 홍보합니다.

NetBSD 개발은 CVS를 사용하며 이것이 전부입니다.

그것은 말장난에게 잘 어울리는 더 빠르고 더 성가신 이름이 있습니다.

나는 최근에 개인 프로젝트를위한 버전 관리 시스템을 찾고 있었기 때문에 방금 그것들을 시도했습니다. 나는 실제로 명령 줄에 문맹이 있으며 GUI를 사용할 수는 있지만 Git은 명령 줄을 통해 실제로 사용되어야한다는 것을 들었습니다. 솔직히 말하면, 엄청나게 쉽게 집어 들었고, 나는 정말로 그것을 즐기고 있습니다. 문서화는 새로운 기술을 채택하는 데 큰 영향을 미치며 Git은 엄청나게 간단한 문서를 제공합니다. SVN 및 Bazaar와 같은 다른 대안은 훌륭했지만 Git만큼 쉽지 않았습니다. Github은 현재 오픈 소스 이동의 중심이 되었기 때문에 큰 요소입니다. 코드와 프로젝트를 교환 할 수있는 중앙 집중식 위치는 게임 체인저 자체입니다.

그냥 내 2 ¢-대안 대신 gittool 언어 또는 지나치게 학문적 인 고급 언어가 아닌 C로 작성되었으므로 대안을 선택했습니다. 이점은 빠르고 효율적이며 설명 할 수없는 버그 나 동작이 발생하면 실제로 RTFS를 사용할 수 있다는 것입니다. 또한 거대한 인터프리터 / 런타임이 포함되지 않은 작은 자체 호스팅 개발 환경에서 사용할 수 있습니다. 즉, 최신 소스를 가져 와서 rsync하지 않고 git repo에서 직접 가져 와서 이러한 시스템에서 컴파일 할 수 있습니다.

그놈 데스크탑 프로젝트 가 몇 년 전에 svn에서 이전하기로 결정했을 때 왜 GNOME 데스크탑 프로젝트 가 git over hg 및 bzr을 선택 했는지 이해하는 것이 좋습니다. 물론 그 방법에 따라 여러 가지 열렬한 종교 토론이 있었지만이 그놈 위키 페이지 에는 특정 커뮤니티에 적용되는 장단점이 잘 요약되어 있습니다.

애플이 객관적인 C 커뮤니티에 애플을 밀어 넣는 것에 대해 언급 한 것은 말할 것도없고, 최근 Xcode 4에서 새로운 응용 프로그램을 생성했다면, Git 리포지토리를 만들 것인지 자동으로 묻는다는 것을 알게 될 것입니다.

Granted Xcode 4는 몇 달 동안 만 사용되었으며 Gits의 이전 성공에는 영향을 미치지 않지만 Apple이 짧은 시간에 어떻게 물건을 만들 수 있는지 잘 알고 있습니다.

현재 hg (kiln)에서 git (github)로 전환하고 있습니다. 지금은 가마를 1 년 정도 사용했습니다. 나를 위해 hg는 단점이 없습니다. 내가해야 할 모든 것을 할 수 있습니다. 그래서 훌륭합니다.

왜 지금 사용하고 있습니까?

지금 세 가지 이유가 있습니다.

1. gitHub는 훌륭한 요점을 제공합니다
2. gitHub는 훌륭한 소셜 기능을 제공합니다
3. 개발자 프리젠 테이션 및 워크샵을 진행하는 동안 항상 샘플을 hg 및 git에 게시했습니다. 자식에서 나는 hg보다 약 10 배 더 많은 방문자가 있습니다!

세 번째가 가장 중요하다고 생각합니다.

토르스텐

순수한 운, 나는 지금까지 왜 무언가가 효과가 있고 다른 것이 효과가 없는지를 증명하는 것이 거의 불가능하다고 생각합니다. Linus는 다른 멋진 것을 만들 수 있으며 성공하지 못합니다.