Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Geleitwort
Vorwort
1 Hello iPhone
2 Die Reise nach iOS
3 Sehen und anfassen
4 Alles unter Kontrolle
5 Daten, Tabellen und Controller
6 Models, Layer, Animationen
7 Programmieren, aber sicher
8 Datenserialisierung und Internetzugriff
9 Multimedia
10 Jahrmarkt der Nützlichkeiten
Stichwort

Buch bestellen
Ihre Meinung?

Spacer
Apps programmieren für iPhone und iPad von Klaus M. Rodewig, Clemens Wagner
Das umfassende Handbuch
Buch: Apps programmieren für iPhone und iPad

Apps programmieren für iPhone und iPad
Rheinwerk Computing
1172 S., geb., mit DVD
49,90 Euro, ISBN 978-3-8362-2734-6
Pfeil 10 Jahrmarkt der Nützlichkeiten
Pfeil 10.1 Ein Rundgang durch Xcode
Pfeil 10.1.1 Die Navigatorspalte
Pfeil 10.1.2 Der Utilitybereich
Pfeil 10.1.3 Der Editor
Pfeil 10.1.4 Autovervollständigung und Code-Schnipsel
Pfeil 10.1.5 Tastaturkurzbefehle
Pfeil 10.1.6 Tabs und Fenster
Pfeil 10.1.7 Simulatoren und Dokumentation nachladen
Pfeil 10.1.8 No Country for Old Man-Pages
Pfeil 10.1.9 Projekte dokumentieren
Pfeil 10.1.10 Snapshots
Pfeil 10.2 Refactoring
Pfeil 10.2.1 Refactorings in Xcode
Pfeil 10.2.2 Methoden auslagern
Pfeil 10.2.3 Oberklassen erzeugen und Methoden verschieben
Pfeil 10.3 Der Organizer
Pfeil 10.3.1 Die Geräteverwaltung
Pfeil 10.3.2 Archive und die Archivverwaltung
Pfeil 10.3.3 Projektverwaltung
Pfeil 10.4 Das Buildsystem
Pfeil 10.4.1 Workspaces, Projekte und Targets
Pfeil 10.4.2 Klassen in Bibliotheken auslagern
Pfeil 10.4.3 Bibliotheken wiederverwenden
Pfeil 10.4.4 Konfigurationen
Pfeil 10.4.5 Targets
Pfeil 10.4.6 Schemata
Pfeil 10.5 Ad-hoc-Distributionen
Pfeil 10.5.1 Geräteregistrierung
Pfeil 10.5.2 App-Installation über das iPhone-Konfigurationsprogramm
Pfeil 10.5.3 Ad-hoc-Distributionen über einen Webserver
Pfeil 10.6 Versionsverwaltung mit Git
Pfeil 10.6.1 Lokale Git-Repositorys
Pfeil 10.6.2 Arbeiten mit verteilten Git-Repositorys
Pfeil 10.6.3 Git-Integration in Xcode
Pfeil 10.6.4 Einbindung existierender Git-Repositorys
Pfeil 10.6.5 GitX
Pfeil 10.6.6 SourceTree
Pfeil 10.6.7 Das Kommandozeilenprogramm von Git
Pfeil 10.6.8 Der eigene Git-Server

Rheinwerk Computing - Zum Seitenanfang

10.6Versionsverwaltung mit GitZur nächsten Überschrift

Xcode unterstützt seit dem Upgrade auf Version 4 die Versionsverwaltung Git. Nachdem gefühlte Jahrzehnte lang die Versionsverwaltung CVS der De-facto-Standard war, haben sich mittlerweile Subversion (svn) und Git als die neuen Standards etabliert.

Auch wenn es im Jahre 2012 noch immer Entwickler gibt, die das manuelle Kopieren und Archivieren von Quelltextdateien im Dateisystem für eine Versionsverwaltung halten, gehört es mittlerweile zu einer allgemein gesicherten Erkenntnis, dass ernsthafte Softwareentwicklung ohne Versionsverwaltung nicht möglich ist. Nicht zuletzt die Bemühungen um einen sicheren Softwareentwicklungsprozess (siehe Kapitel 7, »Programmieren, aber sicher«) erfordern den Einsatz einer Versionsverwaltung, um Änderungen im Code transparent nachverfolgen zu können.

Darüber hinaus ist es bei verteilten Projekten unumgänglich, die Arbeit verschiedener Entwickler über eine Versionsverwaltung zusammenzuführen und zu koordinieren. Der flächendeckende Einsatz einer Versionsverwaltung ist auch durch die unzähligen Open-Source-Projekte gefördert worden, die durch ihre dezentrale Struktur ohne Versionsverwaltung gar nicht möglich gewesen wären.

Stellen Sie sich vor, zwei Entwickler arbeiten am selben Projekt und innerhalb dieses Projektes zur selben Zeit an den gleichen Dateien. Wenn beide Entwickler ihre Änderungen wieder zusammenführen wollen, stoßen sie dabei auf ein Problem: Wie kriegen wir die Dateien zusammen, an denen beide gleichzeitig gearbeitet haben? Dieses Problem zu beheben, ist eine zentrale Aufgabe einer Versionsverwaltung.

Darüber hinaus erfüllt ein Versionsverwaltungssystem allerdings noch weitere Aufgaben:

  • zentrale Speicherung des Quellcodes mehrerer Entwickler
  • Verwalten von Versionsständen
  • Auflösen von Konflikten bei paralleler Arbeit
  • Erstellen und Zusammenführen von Entwicklungszweigen (Branches)

Time Machine als Versionsverwaltung?

Auf dem Mac ist es naheliegend, über Time Machine als Ersatz für eine Versionsverwaltung nachzudenken. Allerdings ist Time Machine eine Backup-Lösung und als Versionsverwaltung ungefähr so gut geeignet, wie ein Kinderzimmer der ideale Ort für die Aufbewahrung von Meißner Porzellan ist. Auch wenn Sie vielleicht auf die zentrale Speicherung der Daten verzichten können, können Sie mit Time Machine nur sehr schwer bestimmte Versionsstände sichern, da Time Machine mit festen Sicherungszyklen arbeitet.

Außerdem löscht Time Machine alte Backups, was Sie auch nur sehr schlecht beeinflussen können, und Time Machine unterstützt Sie auch nur sehr schlecht bei der Wiederherstellung alter Versionsstände, da Time Machine nur komplette Dateien rekonstruieren kann. Bei einer Versionsverwaltung können Sie hingegen beliebige Versionsstände miteinander vergleichen und komplett oder auch nur teilweise wiederherstellen.

So, wie das Kinderzimmer für kurze Zeit ein geeigneter Aufbewahrungsort für Ihr Porzellan bei der Renovierung des Wohnzimmers sein kann, kann Time Machine eine Notlösung für eine Versionsverwaltung sein. Auf Dauer taugen diese beiden Lösungen jedenfalls nicht.

Da Sie Git auch problemlos für kleinere, lokale Projekte auf Ihrem Rechner und somit ohne Server einsetzen können, beschränken wir uns bei der Beschreibung auf dieses Versionsverwaltungssystem.


Rheinwerk Computing - Zum Seitenanfang

10.6.1Lokale Git-RepositorysZur nächsten ÜberschriftZur vorigen Überschrift

Zentraler Begriff bei der Arbeit mit Git ist das Repository. Unter einem Repository versteht man die Datenhaltung eines Versionsverwaltungssystems, in der sich der gesamte verwaltete Code befindet. Das Repository ist nach außen hin eine Blackbox und sollte, um Inkonsistenzen oder Datenverluste zu vermeiden, immer nur über einen Git-Client angesprochen werden und nie direkt über Dateisystem-Zugriffe.

Im Gegensatz zu CVS und Subversion, das einen zentralen Server vorsieht, ist Git ein dezentrales System. Das bedeutet zum einen, dass es keinen zentralen Git-Server geben muss. Jeder Entwickler hat ein lokales Repository, mit dem er ein oder mehrere Projekte verwaltet. So können Sie sich beim Anlegen eines neuen Projekts in Xcode ein lokales Repository einrichten lassen. Die gesamte Verwaltungsarbeit läuft dann zwischen Xcode und dem Git-Repository auf Ihrem lokalen Rechner ab.

Wenn Xcode beim Erzeugen eines neuen Projekts ein Git-Repository dafür erzeugt, fügt es automatisch alle Projektdateien zu diesem Repository hinzu. Die Arbeit mit Git erfolgt dann über Xcode in lokalen Repository (siehe Abbildung 10.77).

Abbildung

Abbildung 10.77 Ein lokales Git-Repository

Die Arbeit mit einem lokalen Git-Repository verläuft wie bei den meisten Versionsverwaltungssystemen auch: Sie erzeugen, ändern und löschen so lange die Quelltextdateien Ihres Projekts, bis Sie einen Stand haben, den Sie für erhaltenswert erachten. Diesen Stand checken Sie dann durch ein Commit in das Repository ein, das diesen Stand dann dauerhaft speichert. Sie können danach weitere Änderungen an Ihrem Projekt durchführen und wieder commiten, und so füllt sich das Repository mit immer neuen Projektständen an. Um wichtige Projektstände besser wiederfinden zu können, können Sie sie taggen, also mit einem Namen versehen.

Zwischen den einzelnen Commits erlaubt Git Ihnen die Anzeige der geänderten Dateien, und Sie können die Änderungen auch als Diff sehen; das ist ein Textformat zur lesbaren und kompakten Beschreibung der Unterschiede zwischen zwei Textdateien. Natürlich können Sie auch Dateien eines beliebigen Stands aus dem Repository wiederherstellen.

Über den Versionseditor können Sie den aktuellen Stand mit einem beliebigen Versionsstand oder auch zwei beliebige Versionsstände aus dem Repository miteinander vergleichen. Um ihn zu öffnen, klicken Sie entweder auf das Icon in der Werkzeugleiste rechts neben dem Icon für den Assistenzeditor (siehe 1 in Abbildung 10.78) oder wählen den Menüpunkt ViewVersion EditorShow Version Editor; Xcode unterteilt dann den Editorbereich in zwei Teile.

Abbildung

Abbildung 10.78 Verglich von zwei Versionsständen in Xcode

Wenn Sie auf das Uhrensymbol 2 am unteren Rand klicken, öffnet Xcode eine Zeitleiste zwischen den beiden Bereichen, über die Sie die Version für die Anzeige der beiden Bereiche auswählen. Dazu fahren Sie mit der Maus über die Zeitleiste und klicken die gewünschte Version 3 an. Xcode öffnet die angeklickte Version entweder im linken oder rechten Bereich, abhängig von der Seite, auf der Sie auf den Zeitbalken geklickt haben.


Rheinwerk Computing - Zum Seitenanfang

10.6.2Arbeiten mit verteilten Git-RepositorysZur nächsten ÜberschriftZur vorigen Überschrift

Neben der einsamen Arbeit an einem lokalen Repository kann Git auch mit verteilten Repositorys umgehen. Dazu definieren Sie ein Repository als Master, und jeder Entwickler erzeugt für sich einen Klon davon, mit dem er dann arbeitet. Im Gegensatz zu den Klonen muss der Master natürlich auf einem Server liegen, den alle Entwicklerrechner über eine SSH-Verbindung erreichen können. Die Änderungen laufen dann jeweils von den lokalen Klonen wieder zum Master (siehe Abbildung 10.79).

Bei der Arbeit mit verteilten Repositorys arbeitet jeder Entwickler mit seinem Klon wie mit einem lokalen Repository. Er hat allerdings nach dem initialen Klonen zwei zusätzliche Operationen für die Datensynchronisation des Klons mit dem Master zur Verfügung. Über die Pull-Operation kann er sich den aktuellen Stand vom Server in sein lokales Repository ziehen, und er kann dessen Stand auf den Master pushen.

Abbildung

Abbildung 10.79 Verteilte Arbeit mit Git


Rheinwerk Computing - Zum Seitenanfang

10.6.3Git-Integration in XcodeZur nächsten ÜberschriftZur vorigen Überschrift

Durch die gute Integration von Git in Xcode ist die Verwendung von Git sowohl für die Arbeit in Teams als auch für Einzelkämpfer ratsam. Schon das simple Nachvollziehen von Änderungen kann zu einem aussichtslosen Unterfangen werden, wenn man keine Versionsverwaltung verwendet.

Für die Arbeit mit Git besitzt Xcode das Hauptmenü Source Control, das Ihnen den Zugriff auf die wichtigsten Operationen des Repositorys erlaubt. Die wichtigste davon ist sicherlich Commit..., mit der Sie den aktuellen Projektstand einchecken. Wenn Sie diesen Menüpunkt auswählen, zeigt Ihnen Xcode einen Dialog wie in Abbildung 10.80 an. In der linken Spalte können Sie die geänderten Dateien wahlweise in der Projekt- oder Ordnerhierarchie oder als einfache Liste sehen, was Sie über die Icons über der Spalte einstellen. Über die Häkchen neben den Dateien können Sie sie jeweils vom Commit ausschließen.

In das große weiße Feld darunter können Sie eine Nachricht für den Commit eingeben. Beschreiben Sie hier kurz, was dieser Commit an dem Projekt ändert.

Abbildung

Abbildung 10.80 Änderungen in Git einchecken

Für die selektierte Datei sehen Sie rechts neben der Dateiliste eine Ansicht, die die Arbeitsversion mit dem letzten Repository-Stand vergleicht. Über die Buttons in der Mittelleiste können Sie dabei einzelne Änderungen vom Commit ausschließen (Dont Commit) oder (Discard Change) verwerfen (siehe Abbildung 10.81).

Abbildung

Abbildung 10.81 Einzelne Änderungen vom Commit ausschließen

Xcode zeigt bei der Arbeit mit einem Projekt über Markierungen im Navigationsbereich Informationen zur Versionsverwaltung an. Ein » rechts neben dem Dateinamen zeigt beispielsweise an, dass Sie die betreffende Datei modifiziert haben und dass sie somit vom Stand im Repository abweicht (siehe Abbildung 10.82). Ein » zeigt hingegen an, dass Sie die Datei neu angelegt haben.

Über den Menüpunkt Source ControlPull... gleichen Sie den Stand Ihres Klons mit dem des Masters ab. Sie sollten allerdings vorher Ihre lokalen Änderungen in Ihr lokales Repository eingecheckt haben. Xcode lädt dabei alle Änderungen aus dem Master und fügt sie in Ihre lokale Arbeitskopie und Ihr lokales Repository ein, sofern dabei kein Konflikt auftritt. Nach dem Aufruf des Menüpunktes fordert Xcode Sie zunächst auf, den Branch auszuwählen, mit dem Sie Ihre lokale Kopie abgleichen wollen.

Abbildung

Abbildung 10.82 Anzeige der Dateien mit geändertem Git-Status

Abbildung

Abbildung 10.83 Auswahl des Branchs

Branches

Ein Branch stellt eine Verzweigung in der Versionsverwaltung dar. Die Einsatzmöglichkeiten dafür sind vielfältig. Damit ist beispielsweise die parallele Entwicklung verschiedener Programmversionen möglich. Das Git-Repository dieses Buchs enthält zum Beispiel für jede Auflage einen eigenen Branch, wodurch sich die Quelltexte der Apps der ersten Auflage genauso einfach auslesen und überarbeiten lassen wie die der zweiten Auflage. Durch die Verzweigung können wir auch Änderungen an den Texten für die erste Auflage durchführen, ohne die der zweiten Auflage zu ändern.

Branches können auch entstehen, wenn mehrere Entwickler parallel an den gleichen Dateien des Masters arbeiten. Allerdings existiert jeder in jeweils nur einem lokalen Repository eines Entwicklers. Beim Pushen der Commits in den Master müssen die Entwickler diese Zweige dann wieder zusammenführen, so dass im Master nach wie vor nur ein Zweig existiert.

Wenn Sie den Button Pull drücken, zieht Xcode die Änderungen vom Master und versucht, sie in Ihre lokale Kopie einzufügen. [Anm.: Durch das Einchecken vor dem Pull befinden sich die Arbeitskopie und der Klon auf dem gleichen Stand.] Dabei kann nun für jede geänderte Datei aus dem Master einer der folgenden drei Fälle auftreten:

  1. Sie haben die Datei seit dem letzten Pull nicht verändert.
  2. Sie haben zwar die Datei verändert, allerdings an anderen Stellen als die
    Änderungen der Version aus dem Master.
  3. Die Änderungen im Master und in der Kopie überschneiden sich, d. h., es wurden mindestens zwei verschiedene Änderungen an der gleichen Stelle vorgenommen, und es entsteht ein Konflikt.

Während die ersten beiden Fälle in der Regel unproblematisch sind, müssen Sie Konflikte immer manuell auflösen. Xcode kennzeichnet die Dateien mit Konflikten durch ein rotes C neben dem Dateinamen (siehe Abbildung 10.84). Wenn Sie die Datei auswählen, stellt der Dialog die Konflikte durch rote Bereiche dar, wogegen er konfliktfreie Änderungen durch blaue Bereiche hervorhebt.

Abbildung

Abbildung 10.84 Anzeige eines Konflikts

Während Xcode für die Änderungen einen Vorschlag macht, zeigt es bei Konflikten zunächst ein Fragezeichen zwischen den Versionen an. Über die vier Schalter am unteren Rand des Fensters entscheiden Sie, wie Sie den Konflikt auflösen möchten. Dabei zeigt Xcode Ihnen im linken Bereich eine Voransicht des Ergebnisses an.

Die Schalter haben (von links nach rechts) die folgende Bedeutung. Sie übernehmen

  • zuerst den hervorgehobenen Text der linken und dann der rechten Seite,
  • nur den hervorgehobenen Text der linken Seite,
  • nur den hervorgehobenen Text der rechten Seite oder
  • zuerst den rechten und danach den linken hervorgehobenen Text in das Ergebnis.

Falls Ihnen diese Optionen nicht ausreichen sollten, können Sie außerdem den Text auf der linken Seite (die lokale Version) editieren. Auf diese Weise müssen Sie jeden einzelnen Konflikt beheben.

Über den Menüpunkt Source ControlPush... können Sie die Änderungen in Ihrem lokalen Repository in den Master hochladen, wenn Sie alle Änderungen eingecheckt haben. Auch hier fragt Xcode Sie zunächst über einen Dialog (siehe Abbildung 10.85), in welchen Branch Sie die Änderungen einfügen möchten. Wenn Xcode bei dieser Operation allerdings feststellt, dass Ihre Version nicht auf der letzten Version des Branches basiert, dann müssen Sie diesen Stand zunächst vom Server ziehen und gegebenenfalls Konflikte auflösen.

Abbildung

Abbildung 10.85 Lokale Änderungen in einen Branch des Masters pushen

Xcode erlaubt Ihnen auch, Git-Aktionen auf einzelnen Dateien auszuführen, die Sie im Kontextmenü der Datei unter Source Control finden. Um beispielsweise eine einzelne Datei einzuchecken, klicken Sie sie mit der rechten Maustaste an und wählen Commit »<Datei>«... aus (siehe Abbildung 10.86). Falls Sie Ihre Änderungen jedoch lieber verwerfen möchten, wählen Sie stattdessen den Unterpunkt Discard Changes in »<Datei>«... aus.

Abbildung

Abbildung 10.86 Einchecken der Änderungen in einer Datei


Rheinwerk Computing - Zum Seitenanfang

10.6.4Einbindung existierender Git-RepositorysZur nächsten ÜberschriftZur vorigen Überschrift

Über das Menü Source ControlCheck Out... können Sie auch entfernte, d. h. im Netzwerk oder im Internet liegende Repositorys einbinden. Um beispielsweise das Repository mit dem Beispielcode aus dem Buch einzubinden, rufen Sie den entsprechenden Dialog auf, indem Sie auf das Pluszeichen unten links im Fenster klicken und im Pop-up-Menü den Punkt Add Repository... auswählen (siehe Abbildung 10.87).

Abbildung

Abbildung 10.87 Die Repository-Verwaltung im Organizer

Im Dialog geben Sie in das Feld Or enter a repository location die URL des Repositorys ein. Das ist für die Beispielprojekte des Buches git://github.com/Cocoaneheads/iPhone.git. Nach Drücken des Buttons Next fordert Sie Xcode auf, einen Branch auszuwählen (siehe Abbildung 10.88). Danach müssen Sie nur noch einen Ordner auf Ihrer Festplatte auswählen, in dem Xcode die Dateien aus dem Repository ablegen soll.

Abbildung

Abbildung 10.88 Auswahl eines Branches beim Auschecken

Anschließend lädt Xcode die Daten vom Server und legt sie im ausgewählten Verzeichnis ab. Abhängig von der Größe des Repositorys und der Bandbreite Ihrer Internetanbindung kann der Vorgang einige Minuten in Anspruch nehmen. Anschließend haben Sie eine lokale Version, in der Sie nach Belieben arbeiten können. Alle Ihre Änderungen an dem Code landen im lokalen Repository.

Die Stabilität der Git-Integration in Xcode hat sich mit den letzten Versionen zwar zunehmend verbessert, jedoch lassen sich nicht alle Operationen über Xcode durchführen und einige nur mit Einschränkungen. Beispielsweise können Sie nur pushen oder pullen, wenn Sie alle Änderungen eingecheckt haben. Diese Einschränkung existiert bei vielen anderen Git-Clients nicht.


Rheinwerk Computing - Zum Seitenanfang

10.6.5GitXZur nächsten ÜberschriftZur vorigen Überschrift

Das Tool GitX bietet Ihnen einen einfachen und schnellen Zugriff auf Ihre Repositorys. Sie finden eine Version davon auf der beiliegenden DVD. Außerdem ist es Open Source und somit kostenlos. Aktuelle Versionen erhalten Sie über die Webseite des Projekts unter http://gitx.frim.nl. Die Installation erfolgt nach dem Download, indem Sie das App-Icon in den Ordner Programme ziehen.

Nach dem Start geben Sie den Speicherort eines bereits vorhandenen Repositorys an, und GitX stellt Ihnen alle Informationen in einem Fenster zur Verfügung (siehe Abbildung 10.89). Im oberen Teil des Fensters sehen Sie alle Versionen eines Branches des Masters als Punkte auf einer Linie, wobei Sie den Branch des Masters über das Dropdown-Menü Branch in der Titelleiste des Fensters auswählen. Über den Button Create Branch können Sie dann einen neuen Entwicklungszweig erstellen.

Abbildung

Abbildung 10.89 Das GUI von GitX

Die Branches der Entwickler stellt das Tool als abzweigende Linien dar, und Sie sehen auch, wann der Entwickler seinen lokalen Branch wieder in den Branch des Masters integriert hat. In Abbildung 10.89 erkennen Sie beispielsweise, dass Clemens Wagner am Vormittag des 28.8.2011 seine Änderungen mit denen von Klaus Rodewig zusammengeführt hat. Die Darstellung ist allerdings leicht irreführend, da Klaus Rodewig seine Änderungen vor Clemens Wagner auf den Master geschoben hat und somit die späteren Änderungen eigentlich die Verzweigung darstellen.

Im unteren Teil des Fensters sehen Sie Details zu den Versionen wie die betroffenen Dateien und alle Änderungen in diesen Dateien, wofür Sie gegebenenfalls den Dateinamen anklicken müssen.


Rheinwerk Computing - Zum Seitenanfang

10.6.6SourceTreeZur nächsten ÜberschriftZur vorigen Überschrift

Ein weiterer Git-Client ist SourceTree des Herstellers Atlassian. Sie finden es zwar im App Store, die aktuelle Version des Programms erhalten Sie allerdings nur über die Webseite http://www.sourcetreeapp.com. Wie GitX ist auch dieser Client kostenlos, allerdings unterstützt er mit Mercurial [Anm.: http://mercurial.selenic.com] noch ein weiteres Versionsverwaltungssystem, und die Arbeit damit ist im Vergleich zu GitX wesentlich komfortabler. Das beginnt mit einer Lesezeichenverwaltung, in der Sie Ihre Repositorys anlegen und in Gruppen ordnen können (siehe Abbildung 10.90).

Abbildung

Abbildung 10.90 Die Lesezeichenverwaltung in SourceTree

Über das Menü FileNewClone können Sie neue lokale Repositorys anlegen, bestehende Repositorys klonen oder einbinden. Um einen Klon zu erzeugen, geben Sie unter Source PathURL die URL des Projekts ein, und unter Destination Path wählen Sie das Verzeichnis aus, in dem SourceTree die Kopie ablegen soll. Bestehende lokale Repositorys binden Sie hingegen über den Reiter Add Working Copy ein, wobei Sie hierfür nur dessen Verzeichnis und einen Lesezeichennamen eingeben brauchen.

Abbildung

Abbildung 10.91 Klonen eines Projekts über SourceTree

Durch einen Doppelklick auf das Lesezeichen öffnen Sie eine Ansicht, die der von GitX ähnelt. Auch hier sehen Sie den Versionsverlauf, Detailinformationen zu den Dateien und eine Ansicht mit den Änderungen (siehe Abbildung 10.92).

Abbildung

Abbildung 10.92 Das Arbeitsfenster von SourceTree

In der Titelleiste finden Sie Icons für die verschiedenen Operationen. Auch hier zeigt SourceTree Ihnen die Anzahl der Versionen an, um die Klon und Master voneinander abweichen, und zwar sowohl in der linken Seitenleiste neben dem Branch als auch an den Icons für Pull und Push.

Wenn Sie den Button Commit drücken, gelangen Sie zu dem Dialog aus Abbildung 10.93. SourceTree unterscheidet beim Einchecken zwischen staged und unstaged Dateien, wobei es nur die ersteren eincheckt. Sie können diesen Zustand der Dateien durch einfaches Verschieben der Dateien zwischen Files staged in the index und Files in the working tree ändern.

Abbildung

Abbildung 10.93 Der Dialog zum Einchecken

Über das Menü Commit Mode lässt sich dieses Verhalten jedoch auch ändern; wenn Sie hier Selected Files auswählen, können Sie die Dateien über Checkboxen für den Commit auswählen.


Rheinwerk Computing - Zum Seitenanfang

10.6.7Das Kommandozeilenprogramm von GitZur nächsten ÜberschriftZur vorigen Überschrift

Auch wenn die verschiedenen grafischen Git-Clients viele Annehmlichkeiten bieten, kann der Einsatz des Kommandozeilenprogramms in bestimmten Situationen trotzdem notwendig sein. Der Kommandozeilen-Client von Git heißt einfach git, und Sie können es mit den Command Line Tools über den Reiter Downloads in den Einstellungen von Xcode installieren.

Tabelle 10.2 enthält eine Liste der wichtigsten und am häufigsten gebrauchten Befehle für das Kommandozeilenprogramm. Eine detaillierte Beschreibung finden Sie unter http://git-scm.com/documentation.

Tabelle 10.2 Übersicht der wichtigsten Befehle

Befehl Bedeutung

git init

Umwandeln des aktuellen Verzeichnisses inklusive aller Unterverzeichnisse in ein Git-Repository

git add .

Hinzufügen aller Dateien und Verzeichnisse im aktuellen Git-Verzeichnis zum Repository

git add <Datei>

Hinzufügen der Datei <DATEI> zum Repository

git rm <DATEI>

Löschen der Datei <DATEI> aus dem Repository

git mv <DATEI> <DATEI_NEU>

Umbenennen der Datei <DATEI> in <DATEI_NEU>

git commit -m "TEXT"

Erzeugen einer neuen Version mit dem angegebenen Beschreibungstext. Erst durch diesen Befehl fügt Git die Änderungen von add, rm und mv in das Repository ein und speichert sie dauerhaft.

git log

Anzeige aller protokollierten Änderungen im Repository

git checkout <HASH>

Auschecken oder Wiederherstellen eines bestimmten Versionsstandes. Der Hash einer Version ist der aus der Anzeige von git log.

git checkout <DATEI>

Wiederherstellung des Repository-Stands der angegebenen Datei <DATEI>. Mit diesem Befehl machen Sie die lokalen Änderungen an einer Datei rückgängig.

git clone git://github.com/Cocoaneheads/iPhone.git

das Github-Repository zum Buch lokal klonen (oder ein beliebiges anderes entferntes Repository)

git pull

die lokale Kopie (den »Klon«) eines entfernten Repositorys auf den aktuellen Stand bringen

git push

Die lokalen Änderungen in das entfernte Repository schieben. Git berücksichtigt dabei nur die Änderungen im lokalen Repository – also die Änderungen, die Sie dort durch ein commit gesichert haben.

git help <Git-Befehl>

Zeigt eine Hilfe zu dem angegebenen Git-Befehl an; z. B. können Sie sich mit git help help die Hilfe zum Hilfebefehl ansehen.


Rheinwerk Computing - Zum Seitenanfang

10.6.8Der eigene Git-ServerZur vorigen Überschrift

Für die Arbeit mit einem lokalen Git-Repository benötigen Sie nicht mehr als Xcode. Damit können Sie alle Aktionen durchführen, die für die Arbeit mit Git notwendig sind.

Um Code für andere zugänglich zu machen, gibt es zwei verschiedene Möglichkeiten. Die erste ist die Verwendung eines Git-Hosting-Dienstes wie z. B. Github [Anm.: http://www.github.com] . Eine kostenlose Registrierung vorausgesetzt, bietet Github Ihnen die Möglichkeit, ein öffentlich zugängliches Repository anzulegen und dort Ihren Code abzulegen. Dieses Repository ist dann über SSH und einen Git-Client (wie Xcode, GitX, SourceTree oder git) sowie über eine Web-Oberfläche zugänglich.

Wie Sie wissen, liegt ja auch der Beispielcode zu diesem Buch bei Github und ist somit öffentlich zugänglich (https://github.com/cocoaneheads/iPhone). Wie Sie auf dieses Repository über Xcode oder einen anderen Client zugreifen können, haben Sie in diesem Kapitel bereits gelernt. Der Zugriff über die Web-Oberfläche ermöglicht darüber hinaus das gezielte Suchen im Repository, ohne dass Sie dafür erst einen lokalen Klon erzeugen müssen.

Abbildung

Abbildung 10.94 Der Code zum Buch im Browser

Nun ist nicht jedes Projekt quelloffen, und nicht jeder Code muss öffentlich zugänglich sein. Für diesen Anwendungsfall bietet Github die Möglichkeit, private Repositorys anzulegen, die nur für autorisierte Benutzer zur Verfügung stehen. Diese Funktion ist kostenpflichtig, kostet in der kleinsten Version zurzeit 7 USD pro Monat und umfasst die Möglichkeit, bis zu fünf private Repositorys anzulegen.

»Privat« bedeutet in diesem Zusammenhang, dass kein Zugriff durch anonyme Benutzer aus dem Internet erfolgen kann. Der Sourcecode liegt dennoch auf Systemen einer US-amerikanischen Firma. Wie aus Funk und Fernsehen bekannt, herrscht in den USA eine andere Auffassung von Datenschutz als in Deutschland; überdies ist es im Rahmen des Patriot Act wiederholt vorgekommen, dass US-amerikanische Behörden Zugriff auf Verbindungs- und Nutzungsdaten amerikanischer Internetfirmen genommen haben. Der in einem privaten Github-Repository abgelegte Code ist also nicht ganz so privat, wie es die Bezeichnung dieser Art von Repositorys glauben machen möchte.

Für Firmendaten, sensible Anwendungsfälle oder paranoide Zeitgenossen ist daher das Einrichten eines eigenen Git-Servers eine adäquate Lösung. Wenn Sie den Server selbst betreiben, haben Sie vom Datenschutz bis zur Verfügbarkeit alle Parameter im eigenen Einflussbereich. Nutzen Sie hingegen die Hosting-Dienstleistungen eines deutschen Providers, so kommen Sie zumindest noch in den Genuss der deutschen Jurisdiktion in Bezug auf Datenschutz.

Einen Git-Server können Sie prinzipiell auf jedem gängigen Betriebssystem einrichten, für das Sie ein entsprechendes Git-Paket finden oder auf dem Sie den Git-Quellcode übersetzen können. Am einfachsten ist es hingegen auf einer aktuellen Linux-Distribution, da die großen Distributionen bereits fertige Git-Pakete für einen eigenen Server mitbringen. Überdies ist Linux die naheliegende Lösung, da es bei den einschlägigen Hosting-Anbietern günstige virtuelle Linux-Server für wenige Euro im Monat zu mieten gibt. Der eigene, im Internet erreichbare und über eine feste Verbindung angebundene Git-Server ist somit schnell und kostengünstig eingerichtet.

Im Folgenden finden Sie daher eine Anleitung, wie Sie einen eigenen Git-Server auf einem System mit Ubuntu-Linux installieren können. Wir haben die Installation auf virtuellen Servern bei den Hostern 1&1 Internet AG sowie Strato getestet.

Ein Git-Server stellt keine besonderen Anforderungen an die Performance, so dass ein virtueller Server in den allermeisten Fällen ausreichend ist. Da der Server aus dem Internet erreichbar ist, empfiehlt sich natürlich eine ausreichende Server-Härtung, um ungebetene Gäste außen vor zu halten. [Anm.: https://www.galileo-press.de//titel/gp/titelID-2529] Überdies ist ein regelmäßiges Backup angezeigt, denn auch ein Hosting-Anbieter ist vor Datenausfällen nicht gefeit, wie exemplarisch der Ausfall der Amazon-Cloud im Frühjahr 2011 zeigte. [Anm.: http://www.heise.de/newsticker/meldung/Wolkenbruch-bei-Amazon-Datenverlust-in-der-Cloud-1234444.html]

Die Zutaten für einen eigenen Git-Server sind überschaubar. Man nehme

  • einen (virtuellen) Server auf Linux-Basis (im folgenden Beispiel Ubuntu 10.10),
  • einen gut angehangenen Zugang per SSH zum Server,
  • die notwendigen Git-Pakete am Stück sowie
  • gitolite [Anm.: https://github.com/sitaramc/gitolite] , ein Tool zum Verwalten eines Git-Servers.

Prinzipiell funktioniert das Einrichten eines Git-Servers unabhängig von der eingesetzten Linux-Distribution und deren Versionsstand. Für Ubuntu 10.10 sind indes alle notwendigen Pakete bereits vorhanden und können einfach über den Paketmanager installiert werden. Hierbei ist es unerheblich, ob Sie eine grafische Benutzeroberfläche oder die Kommandozeile verwenden.

Da Sie im Verlauf der Einrichtung nicht um die Verwendung der Kommandozeile herumkommen, erfolgt die Installation im folgenden Beispiel auch über die Kommandozeile.

Zunächst installieren Sie die benötigten Pakete über aptitude mit dem folgenden Befehl:

sudo apt-get install git-core gitolite git-daemon-run

Damit ist die Installation auf dem Server abgeschlossen. Auf dem Client, Ihrem Mac, benötigen Sie nun noch einen SSH-Schlüssel, da die Verbindung zum Server über SSH [Anm.: http://www.openssh.org] erfolgt. SSH ist ein verschlüsseltes Übertragungsprotokoll und arbeitet wahlweise über die althergebrachte Authentisierung mit Benutzername und Passwort oder über Public-Key-Kryptografie. Für die Arbeit mit dem Git-Server benötigen Sie die zweite Variante.

Erstellen Sie dafür in dem Programm Terminal auf Ihrem Mac mit dem Befehl ssh-keygen für den Benutzer, mit dem Sie den Git-Server nutzen möchten, einen SSH-Schlüssel – sofern dieser nicht bereits vorhanden ist:

# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/klaus/.ssh/id_rsa): /Users/klaus/.ssh/git_key
Enter passphrase (empty for no passphrase): ********
Enter same passphrase again: ********
Your identification has been saved in /Users/klaus/.ssh/git_key.
Your public key has been saved in /Users/klaus/.ssh/git_key.pub.
The key fingerprint is:
71:d9:6f:bb:85:09:0d:3e:4f:48:b8:7f:cf:d9:40:51 klaus@flachmann
The key's randomart image is:
+--[ RSA 2048]----+
| E|
| + . |
| . + + . |
| o + = . |
| S . = * |
| . B + |
| . B .|
| . *o|
| ..+|
+-----------------+

Abhängig von Ihren Angaben bei der Erzeugung des Schlüssels liegen der öffentliche und der private Schlüssel anschließend im Verzeichnis .ssh/ unterhalb des Benutzerverzeichnisses. Wenn Ihnen kein guter Grund einfällt, der dagegen spricht, belassen Sie den Pfad am besten auf dem Standardwert. Der öffentliche Schlüssel hat den Dateinamen id_rsa.pub, und der Name für den privaten Schlüssel lautet id_rsa. Kopieren Sie den öffentlichen (und nur diesen!) [Anm.: Der andere Schlüssel ist der private, und den sollten Sie niemals weitergeben.] Schlüssel auf den Git-Server. Das geht am sichersten über eine SSH-Verbindung mit dem Befehl scp:

scp ~/.ssh/id_rsa.pub user@:/tmp/gituser.pub

SSH-Zugriff auf dem Server absichern

Wenn Sie den Git-Server zum Abschluss der Konfiguration gegen unbefugten Zugriff absichern möchten, sollten Sie den SSH-Zugriff so konfigurieren, dass die Authentisierung nur noch über den öffentlichen SSH-Schlüssel, nicht jedoch über die Angabe von Benutzername und Passwort möglich ist.

Der öffentliche Schlüssel liegt nun im Verzeichnis für temporäre Dateien des Linux-Servers. Damit er für die Installation des Git-Servers verfügbar ist, ändern Sie die Zugriffsrechte so, dass jeder Benutzer auf den Schlüssel zugreifen kann. Da der öffentliche Schlüssel keine vertraulich zu behandelnde Datei ist, stellt diese Änderung kein Sicherheitsrisiko dar:

# sudo chmod 644 /tmp/gituser.pub

Sie haben jetzt alle Komponenten für einen funktionierenden Git-Server beisammen, die Sie jetzt nur noch zusammenfügen müssen. Der Zugriff auf den Server erfolgt per SSH, und durch die Konfiguration des SSH-Dienstes können Sie die Zugriffsberechtigungen auf den Server selbst steuern. Die Verwaltung der Berechtigungen für die Git-Repositorys auf dem Server erfolgt über gitolite.

gitolite identifiziert die Benutzer anhand ihrer SSH-Schlüssel. Bei der initialen Einrichtung von gitolite übergeben Sie einen SSH-Schlüssel für den Administrator der Git-Repositorys. In dem vorliegenden Beispiel ist das der eben auf den Server kopierte Schlüssel. Die initiale Einrichtung von gitolite erfolgt auf der Kommandozeile mit dem Linux-Benutzer gitolite. Sie müssen sich daher zunächst mit su über das root-Benutzerkonto zum Benutzer gitolite machen:

# su – gitolite

Abschließend rufen Sie den Befehl gl-setup zur Einrichtung von gitolite auf und übergeben als Parameter den Pfad zu dem hochgeladenen SSH-Schlüssel:

gitolite@gitserver:~$ gl-setup /tmp/gituser.pub

Sie haben nun die Berechtigung, das gitolite-admin-Repository zu klonen. Unter Ubuntu können Sie gitolite alternativ auch über den Paketmanager einrichten:

# sudo dpkg-reconfigure gitolite

Die Konfiguration von gitolite erfolgt über ebendieses Repository. Sie erstellen also einen lokalen Klon auf Ihrem Rechner, führen dort die Änderungen an der gitolite-Konfiguration durch und aktivieren die Änderungen durch Pushen des gitolite-admin-Repositorys auf den Git-Server – eine verblüffend passende Methode, um einen Git-Server zu konfigurieren.

Der Linux-Benutzer, mit dem Sie auf den Git-Server zugreifen, ist bei der Standardinstallation unter Ubuntu 10.10 der Benutzer gitolite:

# git clone gitolite@gitserver:gitolite-admin
Cloning into gitolite-admin...
remote: Counting objects: 12, done.
remote: Compressing objects: 100 % (9/9), done.
remote: Total 12 (delta 1), reused 0 (delta 0)
Receiving objects: 100 % (12/12), done.
Resolving deltas: 100 % (1/1), done.

Das Repository enthält zwei Verzeichnisse: conf und keydir. Im Verzeichnis conf finden Sie die Konfigurationsdatei von gitolite: gitolite.conf. In dieser Datei konfigurieren Sie Repositorys und die Zugriffsberechtigungen für diese Repositorys. Standardmäßig enthält die Datei zwei Einträge: einen für das gitolite-admin-Repository und einen für ein Repository mit dem Namen testing:

Repo gitolite-admin
RW+ = kmr
Repo testing
RW+ = @all

Die Syntax der Datei ist selbsterklärend – zumindest für die grundlegenden Einstellungen. Der Parameter repo legt den Namen eines Repositorys fest. Die Zugriffsberechtigungen definieren Sie über die Kürzel R (Lesen), RW (Lesen und Schreiben), RW+ (Lesen, Schreiben, Löschen) und – (Zugriff verboten), gefolgt von dem oder den Benutzern, für die diese Berechtigungen gelten.

In der Konfigurationsdatei oben hat der Benutzer kmr also vollen Zugriff auf das Repository gitolite-admin – er ist der Administrator. Auf das Repository testing können alle Benutzer voll zugreifen – es dient dazu, wie der Name vermuten lässt, den Zugriff auf den Server zu testen.

Ein neues Repository legen Sie analog zu den beiden bestehenden Einträgen an. Um neue Benutzer für den Zugriff auf den Git-Server einzurichten, werfen Sie einen Blick in das Verzeichnis keydir. Dort liegen die öffentlichen SSH-Schlüssel aller Benutzer, die auf die Git-Repositorys auf dem Server zugreifen dürfen. gitolite übernimmt den Dateinamen des öffentlichen Schlüssels als Benutzernamen (exklusive der Dateiendung). Aus dem öffentlichen Schlüssel in der Datei kmr.pub wird also der gitolite-Benutzer kmr.

Kopieren Sie den öffentlichen Schlüssel des hinzuzufügenden Benutzers mit dem gewünschten Dateinamen in das Verzeichnis keydir, fügen Sie ihn zum Repository hinzu, und führen Sie anschließend ein Commit sowie einen Push zum Server durch:

# cp clemens.pub ~/git/gitolite-admin/keydir/
# git add keydir/clemens.pub conf/gitolite.conf
# git commit –m "Clemens hinzugefuegt"
# git push origin

Anschließend können Sie den Benutzer in der Konfigurationsdatei verwenden, um ihm Berechtigungen für den Zugriff auf ein oder mehrere Repositorys zu geben. Ein Repository selbst erzeugen Sie durch das Anlegen in der gitolite.conf und das anschließende Pushen zum Server. gitolite erzeugt dann auf dem Server das neue Repository, das umgehend zum Klonen zur Verfügung steht.

Anmerkung am Rande

Nein, das alles ist nicht kompliziert. Es hört sich nur so an.

Die folgenden Schritte zeigen das Anlegen eines neuen Repositorys UnserProjekt, auf das die Benutzer kmr und clemens Zugriff haben, wobei kmr der Administrator des Repositorys ist.

Schritt 1: Eintrag in der Datei gitolite.conf:

repo UnserProjekt
RW+ = kmr
RW = clemens

Schritt 2: Commit der Änderungen:

# git commit -a -m "Neues Repository UnserProjekt"
[master 07ef7e6] Neues Repository UnserProjekt
1 files changed, 4 insertions(+), 0 deletions(-)

Schritt 3: Push der Änderungen zum Git-Server:

# git push
Counting objects: 7, done.
Delta compression using up to 4 threads.
Compressing objects: 100 % (3/3), done.
Writing objects: 100 % (4/4), 394 bytes, done.
Total 4 (delta 1), reused 0 (delta 0)
remote: Already on 'master'
remote: creating UnserProjekt...
remote: Initialized empty Git repository in /var/lib/gitolite/repositories/UnserProjekt.git/
To gitolite@gitserver:gitolite-admin
5b2c3c8..07ef7e6 master -> master

Schritt 4: Erzeugen eines lokalen Klons:

# git clone gitolite@gitserver:UnserProjekt
Cloning into UnserProjekt...
warning: You appear to have cloned an empty repository.

Voilà! In Schritt 3 hat der Git-Server gemeldet, dass er ein neues Repository mit dem gewünschten Namen angelegt hat. Und in Schritt 4 erfolgt das erfolgreiche Klonen des (noch leeren) Repositorys.

Und nun, viel Spaß bei der Arbeit mit Ihrem eigenen Git-Server!



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.

>> Zum Feedback-Formular
<< zurück




Copyright © Rheinwerk Verlag GmbH, Bonn 2014
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Rheinwerk Computing]

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de


  Zum Katalog
Zum Katalog: Apps programmieren für iPhone und iPad






Apps programmieren für iPhone und iPad
Jetzt bestellen


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Apps programmieren für iPhone und iPad






Apps programmieren für iPhone und iPad


Zum Katalog: Einstieg in Objective-C 2.0 und Cocoa






Einstieg in Objective-C 2.0 und Cocoa


Zum Katalog: Spieleprogrammierung mit Android Studio






Spieleprogrammierung mit Android Studio


Zum Katalog: Android 5






Android 5


Zum Katalog: iPhone und iPad-Apps entwickeln






iPhone und iPad-Apps entwickeln


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo