Git und GitHub für Windows mit Sourcetree, Teil 2: Stages, Commit und Push

In dieser Fortsetzung des ersten Teils (Git und GitHub für Windows mit Sourcetree, Teil 1: Grundlagen) möchte ich zeigen, wie man die allererste Datei bearbeitet, im lokalen Repository speichert und danach zu GitHub überträgt.

Wir rufen uns zunächst die Startseite von Sourcetree in Erinnerung, nachdem wir unser erstes Repository geklont haben.

Wenn wir auf „Open in Explorer“ klicken, öffnet sich das bekannte Explorer-Fenster im Verzeichnis des angelegten Repositorys/Projektes.

Momentan befindet sich dort erst die Datei „README.md“. Wir öffnen diese direkt mit einem Editor ihrer Wahl.

Im Editor sehen wir, dass es sich um eine simple Textdatei mit speziellen Formatierungsanweisungen handelt. Das Gatter „#“ kennzeichnet dabei zum Beispiel eine Überschrift erster Ebene.

Wir ergänzen jetzt den Text um einen beliebigen Text (hier: Hello World!) und speichern diesen.

Und jetzt vollzieht sich ein elementarer Schritt in Git bzw. Sourcetree. Wenn wir auf die Software blicken, sehen wir, dass sich etwas geändert hat.

Sourcetree hat erkannt, dass sich die Datei „README.md“ geändert hat. Und wenn wir den Namen der Datei im Feld „Unstanged files“ anklicken, sehen wir oben rechts die zeilenweise registrierten Änderungen.

Wir können sehen, dass die Zeile „A nice description.“ entfernt wurde, dann wurde die Zeile „A nice description. Hello World!“ hinzugefügt. Git registriert Änderungen im Code immer zeilenweise und nicht zeichenweise, daher die auf den ersten Blick umständliche Darstellung.

Exkurs: die Zustände in Git

In Git gibt es drei Bereiche (oder Zustände), in denen Änderungen an Dateien verfolgt werden: unstaged, staged und committed.

Unstaged: Hier werden alle Änderungen angezeigt, die seit dem letzten Commit an einer Datei vorgenommen wurden, aber noch nicht zum Staging-Bereich hinzugefügt wurden.

Staged: Hier werden Änderungen angezeigt, die mit dem Befehl „git add“ (oder dem Äquivalent in Sourcetree) zum Staging-Bereich hinzugefügt wurden, aber noch nicht zum Commit vorgesehen sind.

Committed: Hier werden alle Änderungen gespeichert, die mit dem Befehl „git commit“ (oder dem Äquivalent in Sourcetree) vorgenommen wurden und somit in der Git-History festgehalten sind.

Der Unterschied zwischen den Bereichen ist also, ob Änderungen noch gespeichert oder nur vorgesehen sind. Durch das Hinzufügen zum Staging-Bereich kann man einzelne Änderungen separat commiten und somit die Git-History übersichtlicher gestalten.

Zu Beginn des Arbeitens mit Git wird sich unweigerlich auf die Frage auftun: „Warum gibt es einen Staging-Bereich, warum committe ich nicht sofort?“

Die Antwort erschließt sich, wenn man einen kompletten Arbeitstag mit Git hinter sich gebracht hat:

Der Staging-Bereich in Git ermöglicht es Entwicklern, bestimmte Änderungen an ihren Dateien zu wählen und separat von anderen Änderungen zu commiten. Dadurch kann man gezielter arbeiten und Änderungen besser organisieren.

Ein weiterer Vorteil des Staging-Bereichs ist die Möglichkeit, Änderungen zu überprüfen und sicherzustellen, dass sie korrekt sind, bevor sie endgültig commitet werden. Auf diese Weise kann man sichergehen, dass man keine unerwünschten Änderungen in das Repository hochlädt und die Versionsgeschichte des Projektes sauber bleibt.

Der Staging-Bereich ein wichtiges Werkzeug ist, um Änderungen effektiv und sicher in Git zu managen.

Mit „Stage all“, „Stage selected“ oder dem Pluszeichen neben dem Dateinamen befördern wir jetzt die Datei „README.md“ aus dem „Unstanged“ Bereich in den „Staged“ Bereich. Die Unterschiede in der Datei sind weiterhin einsehbar.

Übrigens können wir mit „Unstage all“, „Unstaged Selected“ oder dem Minuszeichen neben dem Dateinamen die Datei wieder in den Zustand/Bereich „Unstaged“ zurückversetzen. Probieren Sie es aus, es kann nichts passieren. Befördern Sie die Datei aber danach wieder in den Bereich „Staged“, denn wir sind noch nicht fertig mit unserem kleinen Workflow.

Schreiben Sie jetzt einen Kommentar in das untere Feld. Dies ist wichtig, um später noch zu wissen, warum Sie welche Änderungen veranlasst haben, und drücken Sie „Commit“.

Wie Sie sehen, ist die Software nach wenigen Augenblicken in den Bereich „History“ gesprungen. Diese Commit-History hilft Ihnen, die Branches- (der Begriff wird später noch erklärt) und den Commit-Verlauf zu visualisieren. Er hilft, die jüngsten Git-Aktionen im Projektarchiv zu überprüfen, und zeigt, wer wann welche Codeänderungen vorgenommen hat, sodass es einfach ist, herauszufinden, wann ein Fehler eingeführt wurde und zu einer früheren Version zurückzukehren.

Der finale Schritt wird jetzt sein, diese über den Commit erfolgten Änderungen auf GitHub online zu stellen (im Jargon von GitHub: pushen). Dazu gibt es den Button „Push“ in der Menüleiste von Sourcetree. Hier ist bereits eine kleine 1 zu sehen, die sich auf die einzelne zu pushende Datei „README.md“ bezieht.

Nach einem „Push“ erscheint ein schwebendes Fenster, das nach weiteren Angaben fragt. Wir können jetzt vorerst die Default-Einstellungen übernehmen und erneut „Push“ drücken.

Der History-Bereich hat sich scheinbar nicht geändert. Aber beim genauen Betrachten ist zu erkennen, die Markierung “origin/HEAD” in der History eine Position nach oben gerutscht ist. Das “origin/HEAD” bedeutet, dass es sich um den aktuellen Commit des entfernten Repositorys handelt, auf das unser lokales Repository verweist. Das remote Repository in GitHub und das lokale Repository auf unserer Festplatte befinden sich jetzt also wieder auf dem selben Stand.

Und um zu prüfen, ob die Änderungen tatsächlich korrekt bei GitHub angekommen sind, öffnen wir den Browser und öffnen das Repository. Wie wir sehen, hat sich der Text der README.md-Datei geändert. Und das wollten wir erreichen.

Zusammenfassung: Wir haben gelernt, wie wir eine Datei in unserem eigenen, lokalen Repository speichern und wie diese Datei dann auf GitHub übertragen werden.

Vorschau: Im nächsten Beitrag beschäftigen wir uns mit dem Thema, was passiert, wenn mehrere Personen parallel an einer Datei arbeiten. Wer gewinnt? Wie wird entschieden, was übernommen wird?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert