Warum ohne Push-in-Git committen?

Ich fange an, Git zu lernen. Ich habe mit GitKraken herumgespielt und hoffe, dass die Verwendung einer GUI ein praktikabler Weg zum Speichern und Teilen von Dingen ist. Ich bevorzuge GUIs gegenüber der Kommandozeile.

Jetzt verstehe ich, in der GUI muss ich stage Dateien, dann commit sie und dann push, um sie hochzuladen. Aber warum sind push und commit zwei verschiedene dinge? Warum wollte nur commit lokal, ohne den folgenden Upload, um Dateien synchron zu halten?

Ein paar (konkrete) Gründe. TLDR in Fettschrift.

Der erste Grund ist, dass Sie möglicherweise nicht auf die Fernbedienung drücken könnenda Sie nicht mit dem Internet verbunden sind.

Der zweite Grund ist, dass Commits manchmal noch nicht gepusht werden können. Zum Beispiel praktiziere ich TDD. Nachdem ich einen fehlgeschlagenen Test festgeschrieben habe (was ich tue), möchte ich ihn nicht auf die Remote übertragen, da mein Team dann möglicherweise eine fehlgeschlagene Testsuite hinzuzieht. Eine weitere gängige Praxis besteht darin, diese Commits zu quetschen, bevor sie veröffentlicht werden, damit es so aussieht, als wäre das Feature ein einziger Commit.

Der dritte Grund ist, dass es sich um ein persönliches Projekt handelt, das Sie mit niemandem teilen möchten, und so gibt es überhaupt keine Fernbedienung, auf die man drücken kann. Sie müssen keine Fernbedienung mit einem Git-Repo haben.

Der vierte Grund ist, dass Sie möglicherweise mehrere Fernbedienungen haben (im Allgemeinen steht die verteilte Semantik im Weg).. Wie würde Git nach dem Commit wissen, auf welche Fernbedienung Sie pushen möchten? Alle von ihnen? Eine bestimmte? Bestimmte zwei von sieben? Das Pushen muss aus Git-Perspektive explizit sein, da Git semantisch ein verteiltes VCS ist. Weitere Einzelheiten finden Sie in der Antwort von Poke.

PS Dies ist für die Frage nicht relevant, aber die Befehlszeilen-Shells (einschließlich Bash) sind äußerst leistungsfähige Schnittstellen, sobald Sie gelernt haben, sie zu verwenden. Nachdem Sie sich mit diesen Tools vertraut gemacht haben, ist ihre Verwendung viel schneller als jede GUI, die Sie finden werden. Dies hat damit zu tun, dass Sie leistungsstarke Aktionen mit Tastenanschlägen anstelle der Maus ausführen können und dass es unbegrenzt an Ihre Bedürfnisse angepasst werden kann.

Git ist ein verteiltes Versionskontrollsystem. Insofern gibt es keine einzel zentrales Repository, wie bei Subversion oder sogar CVS. Wenn es also einen einzigen Befehl zum Commit und Push gäbe, wohin würde dieser Commit gehen? Was wäre das Remote-Repository?

In Git gibt es kein zentrales Repository. Es gibt nicht einmal eine Hierarchie in Repositories. Für ein lokales Repository beliebig anderes Repository ist ein entferntes Repository, mit dem es interagieren kann. Und das lokale Repository ist nur ein mögliches entferntes Repository für jedes andere Repository.

Lokal und entfernt sind also nur Standpunkte relativ zu Ihrem aktuellen Standort: Das lokale Repository ist immer das aktuelle Repository, und jedes andere Repository ist ein entferntes Repository, mit dem Sie interagieren können.

Wenn Sie mit Git arbeiten, interagieren Sie mit Ihrem lokalen Repository: Sie übertragen alle Ihre Änderungen lokal. Dies hat viele Vorteile und Anwendungsfälle, auf die ich hier nicht näher eingehen werde, aber im Wesentlichen ist es das, was die Versionskontrolle verteilt, da das lokale Repository alle Informationen hat, die vollständige Historie.

Wenn Sie also dieses lokale Repository haben, das den vollständigen Verlauf und alle Änderungen enthält, benötigen Sie eine Möglichkeit, mit anderen Repositorys zu interagieren, damit Sie den Verlauf teilen können. Die beiden Möglichkeiten, dies zu tun, sind Push und Pull (oder Abrufen). Da bei verteilten Repositories jedes Repository gleich ist, kann jedes Repository von einem anderen pushen oder pullen (vorausgesetzt, sie haben Zugriff).

Am Ende müssen Commit und Push separate Schritte sein, da einer mit dem (lokalen) Repository interagiert, während der andere ein bewusster Schritt ist, um Änderungen mit einem Remote-Repository zu teilen.

Eine andere Antwort: Es gibt keinen guten Grund

Früher (wie vor fünf Jahren – alte Geschichte nach heutigen Maßstäben des Gedächtnisses) waren die Leute manchmal nicht mit dem Internet verbunden! Und sie wollten weiterarbeiten! Also verpflichteten sie sich einfach, während sie arbeiteten. Wenn die Verbindung hergestellt war, gingen sie weiter und pushten alle ihre Commits. Git wurde mit diesem als primärem Paradigma entworfen.

Springen Sie all diese Epochen in die Gegenwart und siehe da, die Mechanik der Versionierung unserer Software hat sich nicht (viel) geändert.

Einige Leute haben argumentiert, dass Sie alle Ihre Commits lokal halten, bis Sie überzeugt sind, dass Ihr Code robust ist. Ich bewundere ihre Instinkte: Schützen Sie den Haupt-Repository-Code; halte es so fehlerlos wie möglich. Ja, natürlich, bitte!

Aber Git bietet einen Mechanismus, der viel besser für nicht so perfekten Code funktioniert, nämlich Branches. Erstellen Sie einen Zweig, arbeiten Sie daran (die ganze Zeit Commits pushen), bis Sie zufrieden sind, und führen Sie dann diesen Zweig mit dem Hauptzweig zusammen. Wenn Ihrem Computer etwas passiert (Festplattencrash, verschütteter Kaffee, Diebstahl usw.), ist Ihre gesamte Arbeit auf diese Weise immer noch gesichert. Das ist einer der Punkte der Versionskontrolle, richtig?

Wieder andere haben argumentiert, dass man in einem stark verteilten Entwicklungssystem spezifizieren muss, wo und wie Commits zu pushen sind. Dies ist sicherlich eine Option, aber ich habe dies noch nicht in der Praxis gesehen. Ich kann mir nicht vorstellen, dass ein Unternehmen zu seinen Entwicklern sagt: „Geht da raus und jeder von euch behält seine eigene Kopie des Codes. Wir lassen euch nach Belieben voneinander schieben und ziehen und hoffen, dass nichts schief geht oder gerät verwirrend.” Ja. Es ist so viel einfacher, ein Bitbucket- oder Github-Konto einzurichten und allen zu sagen: “Verwenden Sie dies als Ihren Ursprung!”

Also um es gleich vorweg zu nehmen: pushen Sie einfach bei jedem Commit. Es gibt keinen Nachteil, dies zu tun, und es besteht eine geringe Chance, Arbeit zu verlieren, wenn Sie dies nicht tun.

Sie dienen unterschiedlichen Zwecken. Jeder Commit sollte einen isolierten Aspekt des Codes ändern; benennen Sie beispielsweise eine Variable um, ersetzen Sie Aufrufe einer Funktion durch Aufrufe einer anderen oder korrigieren Sie einfach einen Tippfehler in einem Kommentar. Betrachten Sie sie als Rollback-Punkte; Wenn ich meine Meinung über den Ansatz, den ich hier gewählt habe, ändere, kann ich dann eine kleine Gruppe von Commits löschen und diese anderen, nicht verwandten Änderungen trotzdem beibehalten?

Ein Push sollte nur erfolgen, wenn Ihre Reihe von Commits einen neuen stabilen Punkt in der Entwicklung erreicht, der ausreichend getestet wurde, um mit Ihren Kollegen oder Mitarbeitern geteilt zu werden.

Es ist nicht unmöglich oder ungewöhnlich, für jeden Commit einen Push zu machen, wenn Sie zB an der Behebung kleinerer Fehler arbeiten. Aber oft ist es sinnvoll, individuelle Änderungen vorzunehmen, wenn Sie sich einem größeren Ziel nähern, und nur dann zu pushen, wenn Sie glauben, dass Sie dieses Ziel erreicht haben.