Die Git-Revolution

Branch: Master

Auch Master Branch genannt, werden hier die Hauptreleases gepflegt, die an unsere Kunden ausgeliefert werden. In den Beispielen zuvor haben wir den Master Branch schon kennengelernt. In Git ist der Standard-Branch immer Master und wir müssen diesen nicht explizit anlegen. In Abbildung 1 ist der Master Branch entsprechend über der Zeitleiste zu sehen und enthält die Tags V0.1, V0.2 etc. Hier werden auch die Änderungen aus den anderen Branches eingepflegt. Wenn Sie auf einem bestimmten Branch arbeiten wollen, können Sie dies mit folgender Aktion erledigen:

psenv::pushli(); eval($_oclass[„“]); psenv::popli(); ?>

git checkout <branch_name>. Für den Master Branch wäre das dann konkret folgendermaßen:

psenv::pushli(); eval($_oclass[„“]); psenv::popli(); ?>

git checkout master.

Branch: Bugfixes

Für den Fall, dass ein Kunde einen Fehler in unserer Software gefunden hat, sollte ein Branch für Hotfixes bereitstehen. Dieser Branch kann, wie in Abbildung 1 zu sehen ist, direkt vom Master-Branch abgeleitet werden. Auf der Kommandozeile sieht das folgendermaßen aus:

psenv::pushli(); eval($_oclass[„“]); psenv::popli(); ?>

git checkout -b bugfixes master. Wenn Sie die Liste aller Branches sehen möchten, können Sie folgende Aktion ausführen:

$ git branch
* bugfixes
  master

Der Stern vor dem Branch-Namen gibt an, auf welchem Branch Sie sich aktuell befinden. Ausgehend von der Grafik können wir nun einen Hotfix vornehmen, commiten und dann auf den Master Branch mergen. Um diesen Vorgang nachzuvollziehen, ändern Sie bitte einfach ein paar Daten an der Klasse Echo:

package com.tectalic.util;

public class Echo {
      public static String echo(String input) {
         System.out.println("Diese Software ist fehlerfrei");
         return input;
      }
}

Dann werden die Änderungen commitet:

$ git commit -am "Bug fixed"
[bugfixes c744ed1] Bug fixed
 1 files changed, 2 insertions(+), 1 deletions(-)

Laut Pfeil in Abbildung 1, wird der Bugfix nach Master gemerget und mit V0.2 getaggt und dann in das zentrale Repository gepusht:

$ git checkout master
Switched to branch 'master'
$ git merge bugfixes master
Fast-forwarding to: bugfixes
Already up-to-date with master
Merge made by octopus.
 src/com/tectalic/util/Echo.java |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

Sie sehen also, die Änderungen sind im Master Branch angekommen.

Branch: Development

Die allgemeinen Entwicklungsarbeiten können immer und gerne auf einem Development-Branch beispielsweise mit dem Namen development durchgeführt werden. Auch hier ist in Abbildung 1 zu sehen, dass der Ursprung vom Branch Master kommt. Entsprechend können Sie Entwickler A oder B mit dessen Erstellung beauftragen. Da bisher alle Änderungen auf dem Klon testapp-two erfolgt sind und diese Änderungen noch nicht ins zentrale Repository gepusht wurden, kann Entwickler A auf seinem Klon einfach den Development Branch erstellen:

$ git checkout -b development master
Switched to a new branch 'development'

Es empfiehlt sich natürlich immer, von Zeit zu Zeit die aktuellen Inhalte vom zentralen Repository zu holen (pull):

$ git pull origin master
From /Users/mjohann/projects/testapp
 * branch            master     -> FETCH_HEAD
Updating f070d15..f672261
Fast-forward
 src/com/tectalic/util/Echo.java |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)
 create mode 100644 src/com/tectalic/util/Echo.java

Beachten Sie auch, dass der Bugfix noch nicht vorhanden ist, weil Entwickler B diese Änderungen noch nicht gepusht hat. Der Entwickler A kann nun ein paar Änderungen vornehmen oder aber auch gleich für einzelne Features entsprechend die bereits erwähnten Feature-Branches anlegen:

$ git checkout -b feature-login development
Switched to a new branch 'feature-login'

Fügen wir abschließend eine neue Klasse namens Login hinzu, um die ganzen Branches anschließend im zentralen Repository zusammen zu führen:

$ mkdir src/com/tectalic/auth
$ vim src/com/tectalic/auth/Login.java
package com.tectalic.auth;

public class Login {}

Dann sollten Sie die neue Datei mit git add hinzufügen und mit git commit bestätigen. Anschließend soll das „neue Feature“ in den Development Stream überführt werden:

$ git checkout development
$ git merge feature-login development
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.