Die Git-Revolution

Abschlussarbeiten

Jetzt gibt es ein neues Feature und einen Bugfix. Im zentralen Repository ist davon aber noch nichts angekommen. Also pushen Entwickler A und B ihre Änderungen und wir beginnen mit den Abschlussarbeiten für Release V0.3:

$ git push origin development
Counting objects: 12, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (8/8), 655 bytes, done.
Total 8 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (8/8), done.
To /Users/mjohann/projects/testapp.git
 * [new branch]      development -> development

Damit ist der Development Branch endlich auch „zentral“ verfügbar. Nun folgt Entwickler B:

$ git push origin master
Counting objects: 14, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (8/8), 693 bytes, done.
Total 8 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (8/8), done.
To /Users/mjohann/projects/testapp.git
   f672261..6ae670d  master -> master

Entwickler B soll die neue Version bereitstellen (inklusive Bugfix und Login-Feature). Dazu muss er erstmal sein lokales Repository updaten (pull):

$ git pull
remote: Counting objects: 12, done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 8 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (8/8), done.
From /Users/mjohann/projects/testapp
 * [new branch]      development -> origin/development
Already up-to-date.

Aha, hier ist ein neuer Branch namens development angekommen. Dann wollen wir mal mergen:

$ git checkout master (Der Übersicht halber)
$ git merge development master
Already up-to-date with master
Merge made by octopus.
 src/com/tectalic/auth/Login.java |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)
 create mode 100644 src/com/tectalic/auth/Login.java

Hier ist das neue Feature angekommen. Der Bugfix liegt schon auf master, sodass Entwickler B nun die Version taggen kann:

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

git tag -a V0.3 -m „Bugfixes and Loginfeature“. Mit git log können Sie sich nochmal die gesamte Historie ausgeben lassen.

Fazit

Mit Git ist besonders der Umgang mit Branches und Merges ein Kinderspiel. Der Artikel konnte lediglich an der Oberfläche kratzen und hat keinesfalls einen vollständigen Überblick zum verteilten Versionskontrollsystem Git gegeben. Wer beispielsweise unter Windows arbeiten muss, kann mit Tortoise-Git entsprechend komfortabel vorgehen wie mit Subversion. Auch kennt Git eine Möglichkeit, Subversion Repositories nach Git zu migrieren. Die weiteren Schritte sollten nun die Installation von Git und das Erstellen eines Accounts bei http://www.github.com sein. Manchmal haben Nutzer von Subversion Verständnisprobleme, wenn Sie nach Git wechseln wollen. In diesem Fall hilft es, sich komplett gedanklich von Subversion zu befreien und sich ernsthaft mit den Grundlagen von Git zu befassen. Eine Suche bei Ihrem Suchmaschinenbetreiber listet zudem eine große Auswahl an Tutorials und Informationen auf, um Ihnen den Umstieg weiter zu vereinfachen.