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.
Hinterlasse einen Kommentar