it-swarm-eu.dev

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

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

Andere wie Mercurial scheinen unbemerkt zu bleiben. Beide wurden 2005 veröffentlicht und bieten ähnliche Funktionen. Darüber hinaus gilt Mercurial im Allgemeinen als einfacher zu bedienen, intuitiver und hatte lange Zeit bessere Benutzeroberflächen. Daher kann davon ausgegangen werden, dass dies eine beliebte Alternative ist, insbesondere für diejenigen, die neu in der verteilten Versionskontrolle sind. Dennoch scheint es den meisten Menschen 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 den ganzen 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?

127
dagnelies

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 keinen, den ich kannte). Sie haben Bitbucket jetzt und wahrscheinlich andere, aber GitHub ist schon seit einiger Zeit dort, es ist bekannt und es wird immer besser.

87
deadsven

Ich sehe viele Antworten darauf, die auf den Gefühlen beruhen, die der Autor hatte, als er von dem einen oder anderen SCM hörte. Andere sagen, es sei alles reines Glück gewesen. Ich glaube, Glück kann in der Geschichte zurückverfolgt werden.

Ich werde über die Geschichte sprechen.

Git und Mercurial wurden gleichzeitig erstellt, um das gleiche Problem zu lösen. Damals musste der Linux-Kernel die Verwendung von BitKeeper einstellen, einem proprietären verteilten SCM, das er seit 3 ​​Jahren verwendet. Der Grund dafür war, dass Larry McVoy, CEO von BitMover, dem Unternehmen hinter BitKeeper, seine Software nicht mehr kostenlos an Linux-Entwickler weitergab, weil jemand aus der Linux-Community sie rückentwickelt hatte.

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

Nachdem Matt Mackall einige Zeit damit verbracht hatte, diese Projekte separat zu entwickeln, präsentierte er eine erweiterte Version seines SCM und verglich sie auf eine bestimmte Weise, indem er sie mit Git verglich (das selbst erst ein paar Wochen alt war). Linus erwog, es anstelle von Git zu verwenden für die Kernel-Entwicklung, ließ jedoch die Idee fallen, als er feststellte, dass Mercurial verwendete Änderungssätze, um Revisionsänderungen zu protokollieren . Er befürchtete, dass dies der Arbeitsweise von BitKeeper zu nahe kam, und er wollte mit Sicherheit nichts, was jemanden dazu bringen könnte, zu sagen: "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 zunächst dort eingesetzt wurde, wo es verwendet werden sollte, während Mercurial nicht so schnell seine erste große FOSS-Verwendung 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, reale Projekte verwendet.

Heute sind beide berühmt. Welches am bekanntesten ist, kann man nicht sagen. Google Code hat Git erst kürzlich integriert, während Mercurial lange Zeit verwendet wurde. Viele wirklich große und berühmte Projekte verwenden entweder.

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 Welt GNU] sehr berühmt ist, aber nicht so sehr außerhalb davon, weil es war Entwickelt mit der Absicht, die GNU Community) zufrieden zu stellen. Software geht oft dahin, wo ihre Entwickler hin wollen, und nicht weiter.

Auf der anderen Seite sind verteilte SCMs klare Gewinner. Ich sehe nicht viele weit verbreitete nicht verteilte SCMs da draußen.

86
Thaddee Tyl

Linus Torvalds

Linus ist ein großer Verfechter von Git und hat es jahrelang stark in der Linux-Kerngruppe beworben und es ist von dort gewachsen. Ich glaube, das liegt ausschließlich an Linus 'Einfluss auf die * nix-Community.

Persönlich verwende ich immer noch Subversion, aber das ist eher eine Präferenz als ein Dienstprogramm.

77
Justin Shield

Der übliche Schmerzpunkt beim Versionskontrollsystem ist Zusammenführen von Zweigen.

Sie müssen es versucht 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 war vor ungefähr einem Jahr in der Situation, dass ich mich zwischen hg und git entscheiden musste, und die obige Verschmelzung war ein wichtiger Faktor bei der Auswahl von git. Das zweite war, dass die Eclipse-Organisation auf Git umgestellt hat, 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 alt früh darauf.

Für unterschiedliche Bedürfnisse kann hg genauso nützlich sein. Sun wählte es für ihr VCS basierend auf einer sehr sorgfältigen Untersuchung. Vielleicht möchten Sie die White Papers finden und sehen, was ihre Gründe waren.


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

34
user1249

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

Wie ich früher hervorgehoben , ist die Git-Community sehr laut und arrogant. Die meisten werden ihr kostbares Programm energisch verteidigen. Die meisten der Kriege zwischen Git und Mercurial, die ich gesehen habe, wurden von Git-Leuten begonnen, die sich fragten, warum nicht jeder auf der Erde den heiligen Git benutzt. Websites wie whygitisbetterthanx.com zeigen diese Arroganz sogar in der Einleitung, die geschrieben wurde, um andere zu ködern.

Ich sage nicht, dass jeder so ist, aber die meiste Zeit, wenn ich auf Git-Leute, Pro-Git-Websites und Pro-Git-Blogs gestoßen bin, hatte ich das Gefühl, dass Git in meinen Hals geschoben wird, anstatt als brauchbares DVCS angeboten zu werden System.


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

23
TheLQ

Ich denke nicht, dass Mercurial besonders unauffällig ist. Kiln basiert auf Hg und IDEs wie Eclipse & Netbeans werden seit einiger Zeit gut unterstützt.

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 es eine andere Geschichte sein.

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

Natürlich stimme ich zu, dass Linus ein sehr charismatischer Typ und ein Alpha-Nerd ist, der seinesgleichen sucht, so dass sich viele Leute aus diesem Grund 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 erstellen und sich auf dem siebten auszuruhen - oder so ähnlich. Wenn ein Produkt eine unvergessliche Geschichte hat, ist es einfacher, Traktion zu erlangen.

14
mcottle

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 Art sehr spezifische Art von Informatiker)

Außerdem bekam git eine Killer-App wie Github, und einige sehr beliebte Projekte entschieden sich dafür, sie zu verwenden, was ihr viel Sichtbarkeit verlieh.

13
Thibault J

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

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

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

Wenn jemand herausfindet, wie clever DVCS sind, indem er auf ein bestimmtes DVCS verweist, sagt er oft nicht zu anderen: "Hey, DVCS sind großartig, du solltest sie verwenden", sondern "das DVCS, das - I von DVCS gelernt hat ist großartig, du solltest es verwenden ".

12
jalf

Hier spielen drei Faktoren eine Rolle: "Beta-Geek-Medien", "Die Zeit ist reif" und "Folgen Sie dem Führer".

Beta Geek Media

Es gibt eine Reihe von Kanälen, in denen über "geeky Aktivitäten" diskutiert wird. Sie würden sicherlich das Erscheinungsbild eines neuen Versionskontrollsystems abdecken, aber sie decken git mehr ab. Warum? Weil Linus Torvalds es anfangs schrieb, öffentlich darüber diskutierte und es als Lösung für sein bekanntes Problem mit Bitkeeper verwendete. Tatsächlich schreiben die Beta-Geek-Medien jedes Mal, wenn es einen Flammenkrieg auf lkml gibt, einen Artikel darüber. Die Git-Diskussion begann mit lkml, sodass mehr Berichterstattung als bei anderen Alternativen möglich war. 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 hat wie Mercurial.

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 haben die Hype-Welle verpasst.

Folgen sie den Anführer

Große Projekte haben Follower, die den Code regelmäßig überprüfen und erstellen, auch wenn sie keinen Beitrag leisten. Die Follower werden mit den Tools vertraut, die zum Abrufen des Projekts erforderlich sind, damit diese Tools besser genutzt werden können. 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 hat mehr "Big Draw" -Projekte, daher sind mehr Leute mit Git vertraut, es gibt mehr Git-Tutorials.

12
Sean McMillan

Github. Github ist ein Pionier in der sozialen Kodierung. Es hat die Versionskontrolle zu einer sozialen Plattform gemacht, die viel Aufmerksamkeit auf sich gezogen hat, und es unterstützt offensichtlich nur Git. Social Media = größere Akzeptanz. Bitbucket gewinnt Steam, obwohl es viele neue Funktionen gibt, was es zu einem wahrscheinlichen Rivalen macht :)

11
DelvarWorld

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

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

Ich vermute, dass Mercurial weit verbreitet ist, sicherlich genauso oft wie Git, vielleicht sogar häufiger (Microsoft und andere große Unternehmen verwenden es jetzt), aber die Leute, die Mercurial verwenden, wollten meistens nur einen DSVC, den sie schnell verstehen können, und nicht etwas, auf das sie eine Religion stützen können. Daher sind sie in Diskussionen am wenigsten lautstark und reaktiver als proaktiv wie einige Git-Benutzer.

Über Bazaar wird sicherlich nicht viel gesprochen, da es nur von wenigen großen bekannten Projekten verwendet wird und keine anderen großen Unternehmen als Canonical dafür bekannt sind. Wenn Sie zum Beispiel mit Google (git, Mercurial, svn) und großen Open-Source-Projekten vergleichen, können Sie 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 gut für sie, nur von denen gehört zu werden, die nach den von ihnen bereitgestellten Funktionen suchen (wie eingebettetes Wiki, Issue-Tracking und Forum).

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

Außerdem ermöglichen Google Code Hosting und SourceForge jetzt sowohl Git als auch Mercurial, sodass es aufgrund der GitHub-Funktionen zu einer projektspezifischeren Wahl wird als zuvor, als Sie sich für Git entschieden haben.

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

7
Klaim

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

Ich habe Bazaar so ziemlich benutzt, seit es für verschiedene Dinge geschaffen wurde. Das größte, wofür ich es verwendet habe, war das AllTray-Projekt, für das ich (derzeit) der einzige Entwickler und Betreuer bin. Basar ist schön. Es funktioniert einfach, es bleibt mir aus dem Weg und ich muss fast nie auf eine Hilfeseite oder die Manpage schauen. Das heißt, es gibt einige Nachteile:

  1. Eine Menge Funktionen, die es haben sollte und die wohl Teil des Kern-VCS sein sollten, sind es nicht. Dinge wie die Fähigkeit, eine Halbierung des Verlaufs durchzuführen, eine lange Ausgabe über einen Pager auszuführen oder "kolokalisierte" Zweige (z. B. Repositorys im Git-Stil) zu haben, werden als Plugins bereitgestellt.
  2. Viele der Plugins sind nicht so stabil. Zum Beispiel scheint die Funktionalität für kolokalisierte Zweige auf der Serverseite nicht gut zu funktionieren (zumindest habe ich sie nie zum Laufen gebracht. Es besteht die Tendenz, dass der Zweig am angegebenen Pfad nicht vorhanden ist, wenn er vorhanden ist genau dort vor dir und du kannst das blutige Ding sehen).
  3. Es gibt keine "Klon" -Operation, Sie ziehen nacheinander Zweige. Sie müssen zusätzliche Arbeit leisten, wenn Sie ein Repository haben möchten, damit Sie effizient neue Zweige abrufen können.
  4. Bei einigen Projekten ist es schmerzhaft langsam. Versuchen Sie einmal "bzr branch lp: mysql".
  5. Es fehlt eine starke Unterstützung für Haken; Sie können bzr-Plugins schreiben, die Hooks bereitstellen, aber es gibt keine Standardmethode für serverseitige beliebige Hook-Skripte.

Ich bin kürzlich für die AllTray-Entwicklung zu git gewechselt und denke sehr schnell darüber nach, all meine Projekte auf git zu migrieren. Es gibt etwas mehr Zeit im Voraus, um die Seile kennenzulernen, aber es scheint sich zu lohnen. Einige Dinge, die mir aufgefallen sind:

  1. git clone 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 problemlos möglich. Auf Wunsch können Sie daher viele verschiedene Repositorys mit mehreren Zweigen verfolgen.
  3. Das Buch Pro Git ist online verfügbar und in mehreren Formaten, auch für eBook-Reader-Geräte - und es ist nicht schwer zu lesen.
  4. git scheint viel einfacher zu erweitern zu sein als Bazaar, und Sie müssen keine bestimmte API verwenden, um dies zu tun. (NB: Dies ist sowohl ein Vorteil als auch ein Nachteil.)
  5. in Git ist eine Halbierung integriert, und ich kann die Nützlichkeit dieser Funktion nicht genug betonen.
  6. GitHub ist eher nett.
  7. Das gitosis System ist auch ziemlich nett. Ich bin mir nicht einmal sicher, wie man das anders als als ein 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 beweist mir schnell seine Großartigkeit.

6
Michael Trausch

Wenn Sie git verwenden, bleiben Sie bei der Entwicklung immer im selben lokalen Verzeichnis und führen einfach git checkout branchname zum Wechseln zwischen Zweigen (ich verwende ständig "leichte" Feature-Zweige, daher ist dies ein sehr wichtiges Feature für mich).

In der Mercurial-Dokumentation und den Tutorials 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 die Verzweigung, indem Sie einen Repository-Klon erstellen.

(Ich benutze git täglich. Ich habe wenig Erfahrung mit Mercurial, ich habe damit gespielt und ein paar Tutorials befolgt.)

5
codeape

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 allgemeines Thema zu sein. Ja, Git zu lernen war nach der Verwendung von CVS und Subversion überraschend schwierig, aber an diesem Punkt würde ich es nicht gegen ein anderes VCS eintauschen wollen, es sei denn, es wäre ein anderes Paradigmenwechsel. Und wenn ich auf eine Tabelle mit Funktionen zeige, kann ich nur sehr wenig darüber sagen, wie flexibel, erweiterbar, sicher oder mühelos es ist. Zum Beispiel verwendet standardmäßig git-diff Farben und einen Pager. Sicher kann ich das gleiche mit diff ... | colordiff | less -R Oder so bekommen, aber es sollte offensichtlich sein, warum einer dem anderen überlegen ist.

4
l0b0

Um fair zu sein, ich denke, die Befürworter von Git vs. Mercurial sind im Vergleich zu den Befürwortern von Git vs. Centralized sehr selten. 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 angemessener erster Versuch, die Versionskontrolle zu erfinden, insbesondere angesichts der Tatsache, 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 einfacher Lernfähigkeit 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 bietet Programmierern die Flexibilität, es nach Belieben zu verwenden, wobei es länger dauert, bis sie lernen, wie sie diese Flexibilität sicher nutzen können. Es ermöglicht die Einführung von Einschränkungen zur Durchsetzung von Richtlinien, ist jedoch nicht sofort einsatzbereit. Beachten Sie, dass ich die Leichtigkeit von Lernen anstelle der Leichtigkeit von Verwenden sagte. Sobald Sie es gelernt haben, ist git so einfach zu verwenden 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 Änderungen an den von ihnen verwendeten Tools ein gewisses Maß an Vertrautheit aufweisen. Unternehmen möchten auch, dass ihre Programmierer genügend Flexibilität haben, um ihre Arbeit zu erledigen, aber nicht so sehr, dass sie Schulungen oder die anfängliche Migration erschweren. Hier passt Mercurial ins Spiel. 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 viele Leute versuchen es, aber sie bleiben dabei und fördern es, weil es für sie schlicht und einfach gut funktioniert.

3
Karl Bielefeldt

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

2

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

2

Ich habe kürzlich nach einem Versionskontrollsystem für persönliche Projekte gesucht, also habe ich nur ein paar davon ausprobiert. Ich bin praktisch Analphabet in der Kommandozeile, und ich hatte gehört, dass Git, obwohl GUIs verfügbar waren, eigentlich über die Kommandozeile verwendet werden sollte, was mich etwas zögerlich machte. Ehrlich gesagt war es lächerlich einfach, es aufzunehmen, und ich genieße es wirklich. Die Dokumentation ist ein wichtiger Faktor bei der Einführung einer neuen Technologie, und Git verfügt über eine 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 wichtiger Faktor, da es derzeit für die Open-Source-Bewegung so zentral geworden ist. Ein (ironischerweise) zentraler Ort zum Austausch von Code und Projekten ist an sich schon ein Spielveränderer.

1

Nur meine 2 ¢ - Ich habe Git gegenüber den Alternativen gewählt, weil es in C geschrieben ist und nicht in einer Radtool-Sprache oder einer übermäßig akademischen Hochsprache. Die Vorteile sind, dass es schnell und effizient ist und dass ich tatsächlich RTFS kann, wenn ich auf Fehler oder Verhaltensweisen stoße, die ich nicht erklären kann. Es macht es auch möglich, in winzigen selbst gehosteten Entwicklungsumgebungen zu verwenden, die keine gigantischen Interpreter/Laufzeiten enthalten, was bedeutet, dass ich direkt aus einem Git-Repo ziehen und auf solchen Systemen kompilieren kann, anstatt die neueste Quelle an anderer Stelle abrufen und rsync.

Es könnte Sie interessieren, warum das GNOME-Desktop-Projekt git gegenüber hg und bzr gewählt 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, die sie für diese bestimmte Community hatten, gut zusammen.

1
calum_b

Ganz zu schweigen von Apple hat sich jetzt damit befasst, es an die Objective C-Community weiterzuleiten. Wenn Sie kürzlich eine neue Anwendung in Xcode 4 erstellt haben, haben Sie bemerkt, dass Sie automatisch gefragt werden, ob Sie dies tun möchte ein Git Repo machen.

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 kann Dinge in kurzer Zeit herstellen.

0
tutts