Login
Login-Name Passwort


 
Newsletter
Werbung

Do, 26. Februar 2015, 15:00

Git Tutorium – Teil 3

Im zweiten Teil des Git-Tutoriums wurde ein Überblick über das Branching-Modell gegeben. Dieser dritte Teil rundet den Einstieg in Git ab, womit man für die gängigsten Aufgaben gewappnet sein sollte. Dies umfasst zum einen das Rebasing und zum anderen das Arbeiten mit Remote-Repositorys.

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

Rebasing

Das Rebasing gehört ebenfalls zum Branching-Modell von Git. Im vorherigen Teil des Tutoriums wurde Branches mit dem git merge Befehl zusammengeführt. Eine andere Art der Zusammenführung von Branches ist das Rebasing.

Beim normalen Mergen werden beide Branches zusammengeführt und gegebenenfalls ein Merge-Commit erzeugt. Anders sieht es beim Rebasing aus: In diesem Fall werden die Commits aus einem Branch einzeln auf den Haupt-Branch angewendet. Ein Unterschied zum normalen Merge ist, dass in der Historie des Repositorys beziehungsweise des Branches keine der vorherigen angelegten Branches mehr sichtbar sind.

Um die Funktionsweise besser zu erläutern, folgt das erste Beispiel, wofür wieder jeweils ein Commit auf zwei Branches gebraucht wird. Zunächst muss man sicherstellen, dass man sich auf dem Branch master befindet, von dem man dann den zweiten Branch namens more_content anlegt.

$ git checkout master
$ git checkout -b more_content

Auf diesem Branch muss man nun in der Datei index.html ein wenig mehr Inhalt hinzufügen. Dazu reicht es, etwa den Lorem-Ipsum Text in dem <p>-Tag zu verdreifachen. Die Änderung kann dann wieder wie gewohnt durch einen Commit übernommen werden.

$ git add index.html
$ git commit -m "Verdreifachung des Lorem-Ipsum-Texts"
[more_content 609f8a4] Verdreifachung des Lorem-Ipsum-Texts
 1 file changed, 6 insertions(+)

Einen Commit auf dem Branch more_content gibt es an dieser Stelle somit auch schon. Jetzt muss man zunächst mit dem Befehl git checkout master wieder zurück auf den Branch master wechseln und dort einen Commit erzeugen.

So sähe die Zusammenführung der Branches bei einem normalen Merge aus

Sujeevan Vijayakumaran

So sähe die Zusammenführung der Branches bei einem normalen Merge aus

In der Datei index.html kann man nun für den ersten Commit in der Navigation folgende Zeile verdreifachen:

<li><a href="#">Link</a></li>

Anschließend kann man den ersten Commit tätigen:

$ git add index.html
$ git commit -m "Navigation um zwei Links erweitert."
[master 8d8d6ce] Navigation um zwei Links erweitert.
 1 file changed, 2 insertions(+)

Im zweiten Teil dieser Artikel-Reihe hätte man an dieser Stelle einen Merge gemacht. Konkret würde bei einem git merge more_content der eine Commit aus dem Branch more_content in den Branch master gemergt und es würde zusätzlich ein weiterer Merge-Commit entstehen.

Den Merge-Commit möchte man beim Rebasen allerdings vermeiden. Ziel des Rebasing ist es, dass man den ursprünglichen Entwicklungsbranch nicht mehr sieht und er dann aussieht wie ein gerader Entwicklungs-Strang. Hier stellt sich natürlich die Frage, was jetzt die genauen Vorteile und auch Nachteile vom Rebasen gegenüber dem Mergen ist. Wie bereits oben im Text erwähnt, werden die Commits einzeln auf dem Branch neu angewendet. Die genaue Funktion wird klarer, wenn man es einmal durchgeführt hat. Hierfür wechselt man zunächst zurück auf den Branch more_content und macht dort den Rebase.

$ git checkout more_content
$ git rebase master
Zunächst wird der Branch zurückgespult, um Ihre Änderungen
darauf neu anzuwenden...
Wende an: Verdreifachung des Lorem-Ipsum-Texts

Wenn man also auf dem Branch more_content ist und die Änderungen aus dem Branch master übernehmen möchte ohne einen Merge-Commit zu haben, dann muss man git rebase master ausführen. Wie man aus der Terminal-Ausgabe ablesen kann, wird der Branch zunächst »zurückgespult«, das heißt, dass in diesem Schritt die gemachten Änderungen vorübergehend zurückgenommen werden. Anschließend übernimmt Git die Commits aus dem anderen Branch, in diesem Fall aus dem Branch master. Zum Schluss werden die Commits vom Branch einzeln wieder angewandt. Da es sich in diesem Beispiel um lediglich einen Commit handelt, wird auch nur dieser angewandt.

Kommentare (Insgesamt: 7 || Alle anzeigen || Kommentieren )
Re: Fehler im Beispiel (serio, Sa, 27. Juni 2015)
Fehler im Beispiel (serio, Sa, 27. Juni 2015)
Re[2]: GUI (PinkyAndBrain Ltd., Mo, 2. März 2015)
Schreibfehler (Mike__, Mo, 2. März 2015)
Re: GUI (gklingler, Mo, 2. März 2015)
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung