Login
Newsletter
Werbung

Do, 29. Januar 2015, 15:00

Git-Tutorium – Teil 2

Im ersten Teil des Git Tutoriums wurden die ersten Schritte mit Git getätigt: Zunächst das Anlegen eines Repositories, dann das Hinzufügen und Committen von Dateien und das Anschauen des Logs. Im zweiten Teil wird nur ein Thema behandelt, und zwar das Branching-Modell von Git.

Dies ist der zweite Teil der Artikel-Reihe. Die anderen Teile finden Sie auf dieser Übersichtsseite.

Allgemeines zum Branching

Ein wichtiges Element von Git und auch anderen Versionsverwaltungsprogrammen ist das Branchen. Das Wort »Branch« lässt sich in diesem Fall am Besten mit »Zweig« übersetzen. Es ist möglich, den aktuellen Entwicklungsstand »abzuzweigen« und daran weiter zu entwickeln. Konkret bedeutet dies, dass quasi eine Kopie vom aktuellen Arbeitsstand erzeugt wird und man dort weitere Commits tätigen kann, ohne dabei die Hauptentwicklungslinie zu berühren. Die Nutzung von Branches ist eine zentrale Eigenschaft von Git, insbesondere in der Software-Entwicklung. In der Praxis sieht das dann meistens so aus, dass einzelne Features in einzelnen Branches entwickelt werden und dann nach und nach in den Haupt-Entwicklungszweig gemergt werden. Häufig ist es allerdings so, dass man auch noch ältere Versionen pflegt, die etwa noch mit Sicherheitsaktualisierungen versorgt werden müssen. So kann man recht einfach von einem Entwicklungszweig auf einen anderen Branch wechseln und dort noch schnell einen Fehler korrigieren. Anschließend kann man wieder zurück wechseln und an seinem Feature weiterarbeiten. Das ganze Vorgehen hilft den Programmierern, zwischen verschiedenen Versionen und Entwicklungslinien zu springen, ohne großen Aufwand betreiben zu müssen.

Im ersten Teil des Tutoriums wurden bereits drei Commits getätigt. Da kein spezieller Branch angegeben worden ist, geschah dies automatisch auf dem Master-Branch. Der Master-Branch ist der Haupt-Zweig, der in vielen Git-Repositories existiert. Dieser wird automatisch angelegt, wenn man in einem leeren Git-Repository den ersten Commit tätigt.

Die aktuellen Commits auf dem Master-Branch

Sujeevan Vijayakumaran

Die aktuellen Commits auf dem Master-Branch

Die ersten drei Commits wurden, wie oben bereits geschrieben, auf den Branch master übertragen. Die Entwicklung verlief bislang geradlinig, sodass keine Abzweigung erstellt wurde.

Beim Arbeiten mit Git bietet es sich je nach Entwicklungsart häufig an, für jedes Feature, welches man implementieren möchte, einen eigenen Branch zu erstellen. Insbesondere deshalb, da oft Features zeitgleich von verschiedenen Entwicklern implementiert werden.

Branches anlegen

Die Beispiel-Webseite besitzt aktuell lediglich eine simple Überschrift. Was fehlt, wäre zum einen ein Inhalt und zum anderen ein kleines Menü. Für beides sollen eigene Branches erstellt werden.

Um sicherzustellen, dass man auf dem richtigen Branch ist, kann man folgenden Befehl ausführen:

$ git branch
* master

Da nur ein Branch aktuell vorhanden ist, wird auch nur der Branch master angezeigt. Das * vor dem Branchnamen signalisiert, dass man sich gerade auf dem Branch befindet.

$ git branch menu

Der oben aufgeführte Befehl erzeugt den neuen Branch menu. Wenn man einen Branch mit dem git branch Befehl erzeugt, wird der Branch zwar angelegt, aber man wechselt nicht automatisch auf diesen Branch. Dies macht ein erneutes Ausführen von git branch deutlich:

$ git branch
* master
  menu

Der Branch menu ist noch identisch mit master

Sujeevan Vijayakumaran

Der Branch menu ist noch identisch mit master

Jetzt werden beide vorhandenen Branches angezeigt. Man befindet sich allerdings immer noch auf dem master-Branch. Zum Wechseln des Branches nutzt man den Befehl git checkout.

$ git checkout menu
Gewechselt zu Branch 'menu'

Beim häufigen Erzeugen und Wechseln zu einem Branch wären die obigen Befehle auf Dauer zu lästig, weil man häufig sofort auf dem neu erstellten Branch wechseln will. Dafür gibt es den kombinierten Befehl:

$ git checkout -b menu
Gewechselt zu einem neuem Branch 'menu'

Dieser Befehl legt nicht nur den Branch menu neu an, sondern wechselt auch direkt auf diesen Branch. Es ist wichtig zu wissen, auf welchem Branch man sich befindet, wenn man den neuen Branch anlegt. Dies ist zwar in diesem Beispiel irrelevant, da nur ein Branch existiert, man sollte es aber stets beachten.

Als Basis des neuen Branch wird der aktuelle Commit des aktuellen Branches genommen. Wenn man sich also auf dem Branch menu befindet und den Branch content erstellt, dann nimmt er als Basis den aktuellsten Commit von menu und nicht master. Um das Beispiel fortzuführen, muss daher der Branch content erzeugt werden.

$ git checkout -b content
Gewechselt zu Branch 'content'

Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung