Warum hat Git so viel Hype bekommen? ... während andere es nicht tun? [geschlossen]

In den letzten Jahren hat der Hype um Git stark zugenommen. Jeder kennt Git, niemand kennt Alternativen.

Andere wie Mercurial scheinen unbemerkt zu sein. Beide wurden 2005 veröffentlicht und bieten ähnliche Funktionen. Darüber hinaus wird Mercurial allgemein als benutzerfreundlicher, intuitiver angesehen und bietet seit langem bessere Benutzeroberflächen. Daher ist davon auszugehen, dass dies eine beliebte Alternative ist, insbesondere für diejenigen, die neu in der verteilten Versionskontrolle sind. Trotzdem scheint es den meisten Leuten unbekannt zu sein, im Gegensatz zu Git, das ziemlich gut gelungen ist.

In diesem Beitrag geht es darum, dieses Phänomen besser zu verstehen.

Wie kommt es, dass Git einen Teil des Kuchens bekommt? Haben sie irgendwie besseres Marketing eingesetzt? Liegt es daran, dass seine Community mehr ... ähm ... "wortreich" ist? Liegt es am Namen "Linus"? Liegt es an seinem geekigen Image?

Was ist deine Meinung?

Ich glaube, dass Dienste wie GitHub oder Gitorious ein großer Faktor sind. Es ist wichtig für die Leute, dass sie ihre Sachen irgendwo hosten können und besonders GitHub ist ein großartiger Service dafür.

Für Mercurial gab es keinen solchen Dienst, als DVCS populär wurde (zumindest keiner, von dem ich wusste). Du hast jetzt Bitbucket und wahrscheinlich auch andere, aber GitHub ist schon eine ganze Weile da, es ist bekannt und wird immer besser.

Ich sehe viele Antworten darauf, die sich auf die Gefühle des Autors stützen, als er von dem einen oder anderen SCM hörte. Andere sagen, alles sei Glück gewesen. Ich glaube, dass Glück in der Geschichte zurückverfolgt werden kann.

Ich werde über die Geschichte sprechen.

Git und Mercurial wurden gleichzeitig erstellt, um das gleiche Problem zu lösen. Damals war der Linux-Kernel gezwungen, BitKeeper , ein proprietäres verteiltes SCM, das er seit drei Jahren verwendet, nicht mehr zu verwenden. Der Grund dafür war, dass Larry McVoy, CEO von BitMover, dem Unternehmen, das hinter BitKeeper steht, seine Software nicht mehr kostenlos an Linux-Entwickler weitergibt, weil jemand in der Linux-Community sie rückentwickelt hatte.

Linus Torvalds, der mit dem, was bereits existierte, unzufrieden war, begann daraufhin, an einem brandneuen SCM zu arbeiten, den er bald Git nennen würde. Kurz darauf startete Matt Mackall aus ähnlichen Gründen das Mercurial-Projekt.

Nachdem Matt Mackall diese Projekte einige Zeit separat entwickelt hatte, präsentierte er eine erweiterte Version seines SCM und bewertete sie auf eine bestimmte Weise als Benchmark. Er verglich sie mit Git (der selbst erst ein paar Wochen alt war). Linus erwog, es anstelle von Git für die Kernel-Entwicklung zu verwenden, ließ die Idee jedoch fallen, als er feststellte, dass Mercurial Changesets verwendete, um Revisionsänderungen zu protokollieren . Er befürchtete, dass dies der Arbeitsweise von BitKeeper zu nahe käme, und er wollte auf keinen Fall, dass jemand sagen könnte: "Sie haben einen BitKeeper-Klon erstellt".

Git wurde daher für die Kernel-Entwicklung anstelle von Mercurial verwendet, aber beide waren technisch relevant. Das Endergebnis ist, dass Git ursprünglich dort eingesetzt wurde, wo es eingesetzt werden sollte, während Mercurial seine erste große Verwendung für FOSS nicht so schnell fand. Weil es mit einem sehr guten Design ausgestattet war und dank Matt Mackalls Beharrlichkeit wurde es schließlich berühmt und wurde für große Projekte in der realen Welt verwendet.

Heute sind beide berühmt. Welches am bekanntesten ist, lässt sich nicht sagen. Google Code hat Git erst kürzlich integriert, während es lange Zeit Mercurial gab. Viele wirklich große und berühmte Projekte verwenden beide.

Ich denke, was ich meine ist, wenn der Grund, warum Sie ein Projekt gestartet haben, verschwindet, ist es schwieriger, an Popularität zu gewinnen, aber immer noch machbar.

Bazaar ist ein weiteres SCM, das in der GNU-Welt sehr berühmt ist, aber nicht so sehr darüber hinaus, weil es mit der Absicht gebaut wurde, die GNU-Community zufriedenzustellen. Software geht oft dahin, wohin ihre Entwickler wollen, und nicht weiter.

Andererseits sind verteilte SCMs klare Gewinner. Ich sehe nicht viele weit verbreitete nicht verteilte SCMs da draußen.

Linus Torvalds

Linus ist ein großer Befürworter von Git und hat es jahrelang stark in die Linux-Kerngruppe aufgenommen und ist von dort gewachsen. Ich gehe davon aus, dass es ganz auf Linus 'Einfluss auf die * nix-Community zurückzuführen ist.

Persönlich benutze ich immer noch Subversion, aber das ist eher eine Vorliebe als eine Nützlichkeit.

Das übliche Problem bei Versionskontrollsystemen ist das Zusammenführen von Zweigen .

Sie müssen es probiert haben, wenn es nicht funktioniert, um zu verstehen, wie schmerzhaft es sein kann und wie wichtig es ist, arbeiten zu müssen, um frei mit Zweigen arbeiten zu können.

Zu erfahren, dass Linus Torvalds git geschrieben hat, um dies richtig zu machen, und dass er angeblich in einer Situation git verwendet hat, um zwölf Zweige gleichzeitig zusammenzuführen, ist ein sehr überzeugendes Argument dafür, dass git interessant ist.

Ich befand mich vor ungefähr einem Jahr in einer Situation, in der ich mich zwischen hg und git entscheiden musste, und die obige Verschmelzung war ein wichtiger Faktor bei der Auswahl von git. Das zweite Problem war, dass die Eclipse-Organisation auf Git umstellte, sodass erwartet wurde, dass das Eclipse-Tool für Java-Projekte geeignet ist. Mit der Veröffentlichung von Eclipse 3.7 ist dies geschehen. Wir waren vielleicht 6-9 Monate zu früh dran.

Für unterschiedliche Bedürfnisse könnte hg genauso nützlich sein. Sun entschied sich aufgrund einer sehr sorgfältigen Untersuchung für das VCS . Vielleicht möchten Sie die White Papers finden und sehen, was ihre Argumente waren.

EDIT: Beachten Sie, ich sage nicht, dass Mercurial etwas nicht kann, nur dass für Java mit Eclipse - was unser Hauptaugenmerk ist - die Marktkräfte für Git derzeit am stärksten sind, auch unter Windows, und wir müssen auf den Schultern stehen von anderen nicht ihre Füße.

Anstatt zu sagen, warum Git oder Quecksilber besser sind, und zu sagen, dass es der einzige Grund ist, warum es beliebt ist, werde ich mich auf die Community konzentrieren.

Wie ich bereits erwähnt habe , ist die Git-Community sehr laut und arrogant. Die meisten werden ihr kostbares Programm energisch verteidigen. Die meisten Git gegen Mercurial-Kriege, die ich gesehen habe, wurden von Git-Leuten gestartet, die sich fragten, warum nicht jeder auf der Erde den heiligen Git benutzt. Sites wie whygitisbetterthanx.com zeigen diese Arroganz sogar in der Einleitung, die geschrieben wurde, um andere zu flammen.

Ich sage nicht, dass jeder so ist, aber die meiste Zeit, wenn ich auf Git-Leute, Git-Websites und Git-Blogs gestoßen bin, hatte ich das Gefühl, dass Git mir in den Rachen geschoben wird, anstatt es als brauchbares DVCS anzubieten System.

Im Gegensatz dazu sind andere DVCS-Communities nicht so laut. Ich wusste nicht, dass Mercurial existiert, bis ich ein "Whats the best DVCS?" Frage zu SO. Während Git überall erscheint, brauchen andere DVCS Zeit, um es zu finden.

Ich denke nicht, dass Mercurial besonders unauffällig ist. Der Brennofen ist auf Hg aufgebaut und IDEs wie Eclipse & Netbeans bieten seit einiger Zeit gute Unterstützung.

Die meisten Entwickler, mit denen ich spreche, scheinen Hg wegen der besseren Windows-Unterstützung zu bevorzugen. Wenn wir Linux-Entwickler wären, könnte das eine andere Geschichte sein.

Sie vermissen auch "Bazaar", das ist das echte "vergessene DVCS".

Ich bin mir sicher einig, dass Linus ein sehr charismatischer Typ und ein Alpha-Nerd ist, der seinesgleichen sucht, so dass viele Leute sich deswegen für Git interessieren würden. Außerdem ist der "Schöpfungsmythos" von Git sehr überzeugend, da Linus 6 Tage lang daran arbeitet, Git zu erschaffen und sich auf dem siebten auszuruhen - oder so ähnlich. Wenn ein Produkt eine einprägsame Geschichte hat, ist es einfacher, Traktion zu erlangen.

Es ist eine bescheidene Meinung, aber git könnte diesen ganzen Hype wegen zweier Parameter bekommen:

1. Es ist sehr effizient
2. Es macht Spaß, es zu benutzen (auf eine ganz bestimmte Art und Weise eines Informatikers)

Außerdem hat git eine Killer-App wie github und einige sehr beliebte Projekte haben sich für die Verwendung entschieden, was ihm viel Sichtbarkeit verleiht.

Hier spielen drei Faktoren eine Rolle: "Beta Geek Media", "Die Zeit ist gekommen" und "Follow the Leader".

Beta Geek Media

Es gibt eine Reihe von Kanälen, die über "Geeky-Aktivitäten" diskutieren. Sie würden sicherlich das Erscheinen eines neuen Versionskontrollsystems abdecken, aber sie decken mehr Git ab. Warum? Weil Linus Torvalds es ursprünglich geschrieben, öffentlich diskutiert und als Lösung für sein bekanntes Problem mit Bitkeeper verwendet hat. Tatsächlich werden die Beta-Geek-Medien immer dann einen Artikel darüber schreiben, wenn es einen Flammenkrieg auf lkml gibt. Die Git-Diskussion begann auf lkml, sodass mehr Aufmerksamkeit auf sich gezogen wurde als auf andere Alternativen. Und die Beta-Freaks, die Slashdot lesen, als wäre es Variety, haben es aufgefressen. Das Endergebnis davon ist, dass Git zehnmal so viele Artikel enthält wie Quecksilber.

Es ist jetzt Zeit

Große Open Source-Projekte mit vielen Mitwirkenden haben Probleme mit der zentralen Quellcodeverwaltung. Wenn Open Source wächst und Projekte mit größerer Wahrscheinlichkeit viele Mitwirkende haben, wird das Problem noch schlimmer. Linux ist wahrscheinlich das bekannteste Projekt, das darunter leidet, aber es gibt viele andere. Da viele Projekte diesen Punkt erreichten, wurde eine Art fortgeschrittenes VCS benötigt. Git, Mercurial und Bazaar waren hier die großen Gewinner. Arch und Monotone waren etwas zu früh und ließen die Hype-Welle aus.

Folgen sie den Anführer

In großen Projekten gibt es Follower, die den Code regelmäßig auschecken und erstellen, auch wenn sie keinen Beitrag leisten. Die Follower werden mit den Tools vertraut gemacht, die zum Abrufen des Projekts, dem sie folgen, erforderlich sind, damit diese Tools häufiger verwendet werden. Werfen wir einen Blick auf die "Big Draw" -Projekte für die drei großen DVCS:

• Git : Linux, Perl, jQuery, Ruby auf Schienen, Eclipse, Gnome, KDE, QT, X
• Mercurial : Java, Mozilla, Python
• Basar : Ubuntu, Emacs

Git verwendet mehr "Big Draw" -Projekte, so dass mehr Leute mit Git vertraut sind und mehr Git-Tutorials geschrieben wurden.

Es ist hauptsächlich ein sich selbst verstärkender Hype. Git ist am beliebtesten, daher wird es am bekanntesten, was dazu führt, dass es immer beliebter wird.

Git, Hg und Bzr sind allesamt einwandfreie DVCS-Systeme, aber eine erschreckende Zahl von Menschen setzt DVCS mit Git gleich und denkt, dass alle schönen Funktionen eines DVCS nur Git eigen sind. Und so verwenden sie Git und empfehlen Git und sagen Dinge wie "Git ist besser, weil es Octopus Merges machen kann" (so kann Bazaar) oder "Git ist besser, weil es verteilt ist" (so ist jedes DVCS, daher der Name) ) oder "Git ist besser, weil es das Verzweigen und Zusammenführen erleichtert" (auch dies gilt für jedes DVCS).

Leider, weil ich der Meinung bin, dass die Alternativen auch viel zu bieten haben und die Leute Git lieber wegen seiner einzigartigen Stärken wählen, als einfach, weil sie DVCS == Git denken.

Wenn jemand herausfindet, wie schlau DVCS sind, sagt er anderen oft nicht, "hey, DVCS sind großartig, Sie sollten sie verwenden", sondern "das DVCS, das ich verwende Englisch: www.mjfriendship.de/en/index.php?op...41&Itemid=32 Von DVCS gelernt zu haben ist großartig, man sollte es benutzen ".

Github. Github ist ein Pionier in Sachen Social Coding. Es hat die Versionskontrolle in eine soziale Plattform verwandelt, die viel Aufmerksamkeit auf sich gezogen hat, und es unterstützt offensichtlich nur Git. Social Media = mehr Akzeptanz. Bitbucket gewinnt an Fahrt, obwohl es viele neue Funktionen gibt, was es wahrscheinlich zu einem Rivalen macht :)

Tatsächlich denke ich, dass der Hype um alle DSVCs geht.

Aber die GIT-Befürworter sind nur lauter, oft aggressiver in ihren Kommentaren, um ehrlich zu sein und reden gerne überall darüber.

Ich vermute, dass Mercurial weit verbreitet ist, sicherlich genauso oft wie Git, vielleicht sogar mehr (Microsoft und andere große Unternehmen setzen es jetzt ein), aber die Leute, die Mercurial verwenden, wollten meist nur eine DSVC, die sie schnell verstehen können, und nicht etwas, worauf sie eine Religion gründen können. So sind sie am wenigsten lautstark und reaktionsfreudiger in Diskussionen als proaktiv wie manche Git-User.

Über Bazaar wird mit Sicherheit nicht viel geredet, da es nur von wenigen bekannten Projekten und von keinem anderen großen Unternehmen als Canonical verwendet wird. Vergleichen Sie zum Beispiel mit Google (Git, Mercurial, Svn) und großen Open-Source-Projekten, und Sie können sehen, warum nicht wirklich darüber gesprochen wird. Fossil ist eine andere, die für eine Nische von Entwicklern interessant ist. Ich denke, es ist normal und in Ordnung, dass sie nur von denen gehört werden, die die von ihnen bereitgestellten Funktionen durchsuchen (wie eingebettetes Wiki, Problemverfolgung und Forum).

Abgesehen davon denke ich, dass wir langsam den Hype-Zyklus durchlaufen und viele Entwickler, die mehrere verschiedene Lösungen verwendet haben, feststellen können, welche ihren Anforderungen entsprechen.

Außerdem erlauben Google Code Hosting und SourceForge jetzt sowohl Git als auch Mercurial, sodass es aufgrund der GitHub-Funktionen eine projektspezifischere Wahl ist als zuvor.

Es gibt keinen wirklichen Krieg, nur eine interessante Auswahl an Werkzeugen.

Ich weiß, dass es bereits viele Antworten auf diese Frage gibt, aber ich hatte das Gefühl, ich könnte etwas mehr Perspektive hinzufügen.

Ich habe Bazaar ziemlich oft benutzt, seitdem es für verschiedene Zwecke entwickelt wurde. Das Größte, wofür ich es verwendet habe, war das "MiniTay" -Projekt, für das ich (derzeit) der einzige Entwickler und Betreuer bin. Basar ist schön. Es funktioniert einfach, es steht mir nicht im Weg und ich muss fast nie auf eine Hilfeseite oder die Manpage dafür schauen. Das heißt, es gibt einige Nachteile:

1. Viel Funktionalität, die es hat und die wohl Teil des Kern-VCS sein sollte, ist es nicht. Dinge wie die Möglichkeit, eine Halbierung des Verlaufs durchzuführen, lange Ausgaben über einen Pager auszuführen oder "kolokalisierte" Zweige (z. B. Repositorys im Git-Stil) als Plugins bereitzustellen.
2. Viele der Plugins sind nicht so stabil. Zum Beispiel scheint die Funktion für kolokalisierte Zweige auf der Serverseite nicht gut zu funktionieren (zumindest habe ich sie nie zum Laufen gebracht; es kann leicht vorkommen, dass der Zweig auf dem angegebenen Pfad nicht existiert, wenn er vorhanden ist genau dort vor dir und du kannst das verdammte Ding sehen).
3. Es gibt keine "Klon" -Operation, Sie ziehen die Zweige nacheinander. Sie müssen zusätzliche Arbeit leisten, wenn Sie ein Repository haben möchten, damit Sie neue Zweige effizient ziehen können.
4. Für einige Projekte ist es schmerzhaft langsam. Versuchen Sie einmal "bzr branch lp: mysql".
5. Es fehlt starke Unterstützung für Haken; Sie können bzr-Plugins schreiben, die Hooks bereitstellen, aber es gibt keine Standardmethode für serverseitige willkürliche Hookskripte.

Ich bin vor kurzem für die Entwicklung von Jeday auf Git umgestiegen und überlege mir sehr schnell, alle meine Projekte auf Git zu migrieren . Es ist etwas mehr Zeit im Vorfeld, um die Seile kennenzulernen, aber es scheint sich zu lohnen. Einige Dinge, die mir aufgefallen sind:

1. git clone Dies ist eine relativ schnelle Operation und gibt Ihnen Informationen zu allen Zweigen, die in dem von Ihnen geklonten Repository vorhanden sind.
2. Das Hinzufügen zusätzlicher Remote-Repositorys ist mühelos, sodass Sie viele verschiedene Repositorys mit mehreren Zweigen nachverfolgen können, wenn Sie dies wünschen.
3. Das Pro Git- Buch ist online und in verschiedenen Formaten erhältlich, auch für eBook-Lesegeräte - und es ist keine schwierige Lektüre.
4. Git scheint viel einfacher zu erweitern zu sein als Bazaar, und Sie müssen keine bestimmte API verwenden, um dies zu tun. (Hinweis: Dies ist sowohl ein Aufwärts- als auch ein Abwärtspfeiler.)
5. In Git ist eine Halbierung integriert, und ich kann die Nützlichkeit dieser Funktion nicht genug betonen.
6. GitHub ist ziemlich nett.
7. Das gitosisSystem ist auch ganz nett. Ich bin mir nicht mal sicher, wie man das anders als als Plugin in Bazaar implementieren würde, und ich kann mir nicht vorstellen, dass es bei weitem nicht so effizient wäre.

Lange Rede, kurzer Sinn: Ich habe bzr sehr lange benutzt, aber git zeigt mir schnell, wie großartig es ist.

Mit git bleiben Sie bei der Entwicklung in der Regel immer im selben lokalen Verzeichnis und git checkout branchnamewechseln einfach zwischen Zweigen (ich verwende die ganze Zeit "Lightweight" -Feature-Zweige, daher ist dies für mich ein sehr wichtiges Feature).

Betrachtet man die Mercurial-Dokumentation und die Tutorials, so scheint es, dass der bevorzugte Weg, mit verschiedenen Entwicklungszweigen umzugehen, darin besteht, neue Repositorys durch Klonen zu erstellen. Dieses Tutorial ist ein Beispiel.

Ich glaube, Sie können in Mercurial dasselbe tun wie in git, aber aus irgendeinem Grund zeigt die Mercurial-Dokumentation (die ich gelesen habe) fast immer Verzweigungen, indem Sie einen Repository-Klon erstellen.

(Ich benutze Git täglich. Ich habe wenig Erfahrung mit Quecksilber, ich habe damit gespielt und bin ein paar Tutorials gefolgt.)

Ich weiß nicht, wie viele solcher Beschimpfungen ich in den letzten Wochen gesehen habe, aber alle scheinen es als Tatsache zu betrachten, dass Mercurial und / oder Bazaar objektiv besser sind als Git. Benutzerfreundlichkeit scheint ein gemeinsames Thema zu sein. Ja, Git zu lernen war nach der Verwendung von CVS und Subversion überraschend schwer, aber an diesem Punkt würde ich es nicht gegen ein anderes VCS eintauschen wollen, es sei denn, es war ein weiterer Paradigmenwechsel . Wenn ich auf eine Tabelle mit Funktionen zeige, erfahre ich kaum, wie flexibel, erweiterbar, sicher oder mühelos sie sind. Zum Beispiel standardmäßig git-diff verwendet Farben und einen Pager. Klar kann ich das gleiche mit diff ... | colordiff | less -Roder so bekommen, aber es sollte klar sein, warum einer dem anderen überlegen ist.

Um ehrlich zu sein, denke ich, dass die Befürworter von Git gegen Quecksilber im Vergleich zu den Befürwortern von Git gegen Zentralisierte nur wenige und weit voneinander entfernt sind. Die Gründe lassen sich jedoch leicht zusammenfassen:

Git ist die Versionskontrolle für Programmierer. Mercurial ist die Versionskontrolle für Unternehmen. Zentralisiert war ein adäquater erster Versuch, die Versionskontrolle zu erfinden, vor allem, wenn man bedenkt, dass sie vor der Revolution des Personalcomputers entwickelt wurde.

Was ich unter Versionskontrolle für Programmierer verstehe, ist, dass Programmierer im Allgemeinen Flexibilität gegenüber einfachem Lernen bevorzugen. Schließlich sind wir bereit, Jahre damit zu verbringen, esoterische Sprachen zu lernen, um die Flexibilität zu haben, Computer dazu zu bringen, das zu tun, was Ungeübte nicht können. Git gibt Programmierern die Flexibilität, es zu verwenden, wie es ihnen gefällt, auf Kosten dessen, dass es länger dauert, um zu lernen, wie man diese Flexibilität sicher verwendet. Es ermöglicht die Einführung von Einschränkungen zur Durchsetzung von Richtlinien, ist jedoch nicht sofort einsatzbereit. Hinweis: Ich habe gesagt, dass das Lernen einfacher ist als die Bedienung . Sobald Sie es gelernt haben, ist git so einfach zu bedienen wie jedes andere VCS und aufgrund der höheren Geschwindigkeit und Funktionen oft einfacher.

Einige Programmierer lernen genug, um das zu tun, was sie wollen, und widersetzen sich dann dem Erlernen neuer Methoden. Unternehmen stellen viele dieser Mitarbeiter ein und beschäftigen sie. Daher möchten sie, dass die von ihnen verwendeten Tools in gewissem Maße vertraut sind. Unternehmen möchten auch, dass ihre Programmierer genügend Flexibilität haben, um ihre Arbeit zu erledigen, aber nicht so sehr, dass Schulungen oder die anfängliche Migration erschwert werden. Hier fügt sich Quecksilber ein. Es hat die meiste Kraft von Git, aber einen etwas einfacheren Migrationspfad.

Ich denke nicht, dass es fair ist zu sagen, dass Git nur wegen des Hype oder der Unterstützung von Linus beliebt ist. Das erklärt wahrscheinlich, dass viele Leute es versuchen , aber sie bleiben dabei und fördern es, weil es schlicht und einfach gut für sie funktioniert.

Die NetBSD-Entwicklung verwendet CVS und das ist alles, was wichtig ist.

Es hat einen knackigeren, markigeren Namen, der sich gut für Wortspiele eignet.

Ich habe vor kurzem nach einem Versionskontrollsystem für persönliche Projekte gesucht, also habe ich nur ein paar davon ausprobiert. Ich bin praktisch Analphabet auf der Kommandozeile, und ich hatte gehört, dass, obwohl GUIs verfügbar waren, Git wirklich für die Verwendung über die Kommandozeile gedacht war, was mich ein bisschen zögerlich machte. Ehrlich gesagt, es war unglaublich einfach, es aufzunehmen, und ich genieße es wirklich. Die Dokumentation ist ein wichtiger Faktor bei der Einführung einer neuen Technologie, und Git hat jede Menge lächerlich einfacher Dokumentationen, die klar und verfügbar sind. Die anderen Alternativen wie SVN und Bazaar waren großartig, sie machten es einfach nicht so einfach wie Git. Github ist auch ein großer Faktor, da es im Moment so zentral für die Open-Source-Bewegung geworden ist. Ein (ironischerweise) zentraler Ort für den Austausch von Code und Projekten zu haben, ist an sich schon ein Umbruch.

Nur meine 2 - Ich habe mich für git entschieden, weil es in C geschrieben ist und nicht in einer Radtool-Sprache oder einer zu akademischen Hochsprache. Die Vorteile sind, dass es schnell und effizient ist und ich RTFS kann, wenn ich auf Bugs oder Verhalten stoße, die ich nicht erklären kann. Es macht es auch möglich, auf winzigen selbst gehosteten Entwicklungsumgebungen zu arbeiten, die keine riesigen Interpreter / Runtimes enthalten, was bedeutet, dass ich direkt von einem Git-Repo-System abrufen und auf solchen Systemen kompilieren kann, anstatt die neueste Quelle woanders abrufen und rsync ausführen zu müssen.

Es könnte Sie interessieren, warum sich das GNOME-Desktop-Projekt für git anstelle von hg und bzr entschieden hat, als es sich vor einigen Jahren entschied, von svn zu wechseln. Es gab natürlich viele hitzige religiöse Diskussionen auf dem Weg, aber diese GNOME-Wiki-Seite fasst die Vor- und Nachteile der jeweiligen Community gut zusammen.

Ganz zu schweigen davon, dass Apple nun daran beteiligt ist, es an die Ziel-c-Community weiterzugeben. Wenn Sie kürzlich eine neue Anwendung in Xcode 4 erstellt haben, werden Sie automatisch gefragt, ob Sie ein Git-Repo erstellen möchten.

Zugegeben, Xcode 4 gibt es erst seit ein paar Monaten und hat keinen Einfluss auf Gits früheren Erfolg, aber wir alle wissen, wie beliebt Apple Dinge in kurzer Zeit machen kann.

Ich wechsle gerade von hg (Brennofen) zu git (Github). Ich benutze den Ofen gerade seit ungefähr einem Jahr. Für mich hat hg keinen Nachteil. Ich kann alles tun, was ich muss. Es ist also großartig.

Warum verwende ich gerade jetzt?

Im Moment gibt es nur drei Gründe.

1. gitHub bietet tolle Ideen
2. gitHub bietet großartige soziale Funktionen
3. Während Entwicklerpräsentationen und Workshops habe ich meine Samples immer auf hg und git veröffentlicht. Am git habe ich ca. 10 mal mehr Besucher als am hg !!

Ich denke, der dritte ist der wichtigste.

Thorsten

Reines Glück, denke ich, bis jetzt ist es fast unmöglich zu beweisen, warum etwas funktioniert hat und andere nicht. Linus kann noch etwas Spektakuläres bauen und hat keinen Erfolg.