Folgendes mag ich an git nicht:
Zunächst denke ich, dass die verteilte Idee der Realität widerspricht. Jeder, der tatsächlich Git benutzt, tut dies zentral, sogar Linus Torvalds. Wenn der Kernel auf verteilte Weise verwaltet würde, würde dies bedeuten, dass ich die "offiziellen" Kernelquellen nicht herunterladen könnte - es würde keine geben - ich müsste mich entscheiden, ob ich Linus 'Version oder Joes Version möchte. oder Bills Version. Das wäre natürlich lächerlich, und deshalb gibt es eine offizielle Definition, die Linus mithilfe eines zentralisierten Workflows steuert.
Wenn Sie akzeptieren, dass Sie eine zentralisierte Definition Ihrer Inhalte wünschen, wird deutlich, dass die Server- und Client-Rollen völlig unterschiedlich sind, sodass das Dogma, dass Client- und Server-Software identisch sein sollten, rein einschränkend wird. Das Dogma , dass die Client- und Server - Daten sollten gleich sein wird einfach lächerlich, vor allem in einer Code - Basis , dass die 15 Jahre der Geschichte bekam , dass niemand kümmert sich um , aber jeder zu Klon haben würde.
Was wir eigentlich mit all dem alten Zeug machen wollen, ist es in einen Schrank zu stecken und zu vergessen, dass es da ist, genau wie jedes normale VCS. Die Tatsache, dass Git jeden Tag alles über das Netzwerk hin und her schleppt, ist sehr gefährlich, weil es Sie nervt, es zu beschneiden. Dieses Beschneiden ist mit vielen langwierigen Entscheidungen verbunden und kann schief gehen. Die Leute werden wahrscheinlich eine ganze Reihe von Schnappschuss-Repos von verschiedenen Punkten in der Geschichte behalten, aber war das nicht das, wofür die Quellcodeverwaltung gedacht war? Dieses Problem gab es erst, als jemand das verteilte Modell erfand.
Git ermutigt die Leute aktiv, die Geschichte neu zu schreiben, und das Obige ist wahrscheinlich ein Grund dafür. Jedes normale VCS macht das Umschreiben des Verlaufs für alle außer den Administratoren unmöglich und stellt sicher, dass die Administratoren keinen Grund haben, darüber nachzudenken. Korrigieren Sie mich, wenn ich falsch liege, aber soweit ich weiß, bietet git normalen Benutzern keine Möglichkeit, Schreibzugriff zu gewähren, sondern verbietet ihnen, den Verlauf neu zu schreiben. Das bedeutet, dass jeder Entwickler mit Groll (oder der immer noch mit der Lernkurve zu kämpfen hatte) die gesamte Codebasis in den Papierkorb werfen kann. Wie ziehen wir das fest? Nun, entweder erstellen Sie regelmäßig Backups des gesamten Verlaufs, dh Sie halten den Verlauf im Quadrat, oder Sie verbieten den Schreibzugriff auf alle außer einigen armen Leuten, die alle Unterschiede per E-Mail erhalten und von Hand zusammenführen würden.
Nehmen wir ein Beispiel für ein gut finanziertes, großes Projekt und sehen, wie Git für sie funktioniert: Android. Ich habe mich einmal entschlossen, mit dem Android-System selbst zu spielen. Ich fand heraus, dass ich eine Reihe von Skripten namens Repo verwenden sollte, um an ihren Git zu kommen. Einige Repos werden auf dem Client und einige auf dem Server ausgeführt, aber beide veranschaulichen aufgrund ihrer Existenz die Tatsache, dass Git in beiden Funktionen unvollständig ist. Was passierte ist, dass ich ungefähr eine Woche lang nicht in der Lage war, die Quellen zu ziehen und dann ganz aufgab. Ich hätte eine wirklich große Datenmenge aus verschiedenen Repositorys abrufen müssen, aber der Server war mit Leuten wie mir völlig überlastet. Repo hatte eine Zeitüberschreitung und konnte nicht dort weitermachen, wo die Zeitüberschreitung abgelaufen war. Wenn Git so verteilbar ist, hättest du gedacht, dass sie ' Ich habe eine Art Peer-to-Peer-Aktion durchgeführt, um die Belastung dieses einen Servers zu verringern. Git ist verteilbar, aber kein Server. Git + Repo ist ein Server, aber Repo ist nicht verteilbar, da es sich nur um eine Ad-hoc-Sammlung von Hacks handelt.
Ein ähnliches Beispiel für die Unzulänglichkeit von git ist gitolite (und sein Vorfahr, der anscheinend nicht so gut funktioniert hat). Gitolite beschreibt seine Aufgabe darin, die Bereitstellung eines git-Servers zu vereinfachen. Wiederum beweist die bloße Existenz dieser Sache, dass Git kein Server ist, genauso wenig wie es ein Client ist. Darüber hinaus wird es niemals so sein, denn wenn es zu einem der beiden werden würde, würde es seine Grundprinzipien verraten.
Selbst wenn Sie an das verteilte Ding glauben würden, wäre Git immer noch ein Chaos. Was ist zum Beispiel eine Niederlassung? Sie sagen, dass Sie implizit jedes Mal einen Zweig erstellen, wenn Sie ein Repository klonen, aber das kann nicht dasselbe sein wie ein Zweig in einem einzelnen Repository. Das sind also mindestens zwei verschiedene Dinge, die als Zweige bezeichnet werden. Sie können aber auch ein Repo zurückspulen und einfach mit der Bearbeitung beginnen. Ist das wie die zweite Art von Zweig oder wieder etwas anderes? Vielleicht hängt es davon ab, welche Art von Repo Sie haben - oh ja - anscheinend ist das Repo auch kein sehr klares Konzept. Es gibt normale und nackte. Sie können nicht zu einem normalen Teil wechseln, da der nackte Teil möglicherweise nicht mehr mit dem Quellbaum synchronisiert ist. Aber Sie können nicht zu einem Nackten importieren, weil sie nicht daran gedacht haben. Sie müssen also zu einem normalen cvsimportieren, Klonen Sie das auf eine nackte, die Entwickler getroffen haben, und cvsexportieren Sie das auf eine CVS-Arbeitskopie, die noch in cvs eingecheckt werden muss. Wer kann gestört werden? Woher kamen all diese Komplikationen? Aus der verteilten Idee selbst. Am Ende habe ich Gitolite fallen lassen, weil es mir noch mehr dieser Einschränkungen auferlegte.
Git sagt, dass die Verzweigung leicht sein sollte, aber viele Unternehmen haben bereits ein ernstes Problem mit betrügerischen Zweigen, so dass ich gedacht hätte, dass die Verzweigung eine wichtige Entscheidung mit strenger Überwachung sein sollte. Hier scheint Perforce wirklich ...
In der Not brauchen Sie selten Zweige, weil Sie Änderungssätze auf sehr agile Weise jonglieren können. Der übliche Workflow besteht beispielsweise darin, dass Sie mit der letzten bekannten guten Version auf der Hauptleitung synchronisieren und dann Ihre Funktion schreiben. Wenn Sie versuchen, eine Datei zu ändern, wird der Unterschied dieser Datei zu Ihrem "Standard-Änderungssatz" hinzugefügt. Wenn Sie versuchen, das Änderungsset einzuchecken, wird automatisch versucht, die Nachrichten von der Hauptzeile in Ihr Änderungsset einzufügen (effektiv neu zu gründen) und dann festgeschrieben. Dieser Workflow wird erzwungen, ohne dass Sie ihn verstehen müssen. Mainline sammelt so eine Änderungshistorie, durch die Sie sich später ganz einfach durcharbeiten können. Angenommen, Sie möchten eine alte zurücksetzen, z. B. die vor der vorletzten. Sie synchronisieren mit dem Moment vor der Änderung, markieren die betroffenen Dateien als Teil des Änderungssatzes. Synchronisiere mit dem Moment danach und verschmelze mit "immer meins". (Da war etwas sehr Interessantes: Synchronisieren bedeutet nicht, dasselbe zu haben - wenn eine Datei bearbeitet werden kann (dh in einem aktiven Änderungssatz), wird sie nicht von der Synchronisierung blockiert, sondern als zum Auflösen fällig markiert.) Jetzt haben Sie eine Änderungsliste, die die beleidigende rückgängig macht. Wenn Sie die nachfolgenden Nachrichten zusammenführen, haben Sie eine Änderungsliste, die Sie über die Hauptlinie legen können, um den gewünschten Effekt zu erzielen. Zu keinem Zeitpunkt haben wir eine Geschichte neu geschrieben. Wenn Sie die nachfolgenden Nachrichten zusammenführen, haben Sie eine Änderungsliste, die Sie über die Hauptlinie legen können, um den gewünschten Effekt zu erzielen. Zu keinem Zeitpunkt haben wir eine Geschichte neu geschrieben. Wenn Sie die nachfolgenden Nachrichten zusammenführen, haben Sie eine Änderungsliste, die Sie über die Hauptlinie legen können, um den gewünschten Effekt zu erzielen. Zu keinem Zeitpunkt haben wir eine Geschichte neu geschrieben.
Angenommen, in der Mitte dieses Prozesses läuft jemand auf Sie zu und fordert Sie auf, alles fallen zu lassen und einen Fehler zu beheben. Sie geben Ihrer Standard-Änderungsliste einfach einen Namen (tatsächlich eine Nummer), "setzen" sie dann aus, beheben den Fehler in der jetzt leeren Standard-Änderungsliste, schreiben sie fest und setzen die benannte Änderungsliste fort. Es ist typisch, dass mehrere Änderungslisten gleichzeitig angehalten werden, wenn Sie verschiedene Dinge ausprobieren. Es ist einfach und privat. Sie erhalten das, was Sie wirklich von einem Zweigregime wollen, ohne die Versuchung zu haben, die Verschmelzung mit der Hauptlinie hinauszuschieben oder zu verzögern.
Ich nehme an, es wäre theoretisch möglich, etwas Ähnliches in git zu tun, aber git macht praktisch alles möglich, anstatt einen Workflow zu behaupten, den wir gutheißen. Das zentralisierte Modell ist eine Reihe gültiger Vereinfachungen in Bezug auf das verteilte Modell, bei dem es sich um eine ungültige Verallgemeinerung handelt. Es ist so übergeneralisiert, dass es im Grunde erwartet, dass Sie die Quellcodeverwaltung darüber hinaus implementieren, wie es Repo tut.
Die andere Sache ist die Replikation. In git ist alles möglich, also musst du es selbst herausfinden. Zwangsläufig erhalten Sie einen effektiv zustandslosen Cache. Die einzige Konfiguration, die es wissen muss, ist, wo sich der Master befindet, und die Clients können nach eigenem Ermessen entweder auf den Master oder den Cache zeigen. Das ist ein fünfminütiger Job und es kann nichts schief gehen.
Sie haben auch Trigger und anpassbare Formulare, um Codeüberprüfungen, Bugzilla-Referenzen usw. zu bestätigen, und natürlich haben Sie Zweige, wenn Sie sie tatsächlich benötigen. Es ist kein klarer Fall, aber es ist nah und es ist kinderleicht einzurichten und zu warten.
Alles in allem denke ich, wenn Sie wissen, dass Sie zentral arbeiten werden, was jeder tut, können Sie auch ein Tool verwenden, das unter diesem Gesichtspunkt entwickelt wurde. Git wird überbewertet, weil Linus 'furchterregender Witz zusammen mit der Tendenz der Menschen, einander wie Schafe zu folgen, aber seine Hauptaufgabe dem gesunden Menschenverstand nicht wirklich standhält, und indem er ihm folgt, bindet Git seine eigenen Hände mit Die beiden großen Dogmen, dass (a) die Software und (b) die Daten sowohl auf dem Client als auch auf dem Server gleich sein müssen, machen das bei der zentralen Arbeit immer kompliziert und lahm.