GitHub - Eine Einführung

Page 1

Roland Grela Benjamin Awad

GitHub Eine Einf端hrung

Dieses Werk steht unter der Creative Commons CC BY-NC-SA 3.0-Lizenz


Die Dokumentation beschreibt die Verwendung der Versionsverwaltungs-Sofware Git und die Webseite GitHub.com GitHub ist eine Webseite auf der Sofware Projekte in Teamarbeit verwaltet werden können. Die Einleitung bringt dem Leser Begriffe der Versionsverwaltung bei und macht mit den Funktionen von Git vertraut. Diese Dokumentation entstand unter der Leitung von Michael Zirlewagen im Rahmen der Vorlesung "Webprogrammierung" WS 2011/2012 der Fachhochschule Düsseldorf.

Inhaltsverzeichnis Über Version Control............................................................................................................................3 Warum Version Control?..................................................................................................................3 Arten der Versionsverwaltung..........................................................................................................3 Warum Git?...........................................................................................................................................5 GitHub.................................................................................................................................................. 6 Wer nutzt GitHub?...........................................................................................................................6 GitHub Preise...................................................................................................................................7 GitHub Features...............................................................................................................................7 Installation............................................................................................................................................ 8 Installation unter Linux:...................................................................................................................8 Installation unter Mac OS................................................................................................................8 Installation unter Windows.............................................................................................................. 8 Git und GitHub Einrichtung................................................................................................................. 9 SSH Schlüssel erzeugen.................................................................................................................10 Git einrichten...................................................................................................................................... 11 Erste Konfiguration in Git: Wer bin ich?....................................................................................... 11 Die erste Repository........................................................................................................................... 13 Verbindung mit GitHub...................................................................................................................... 17 Branching und Merging......................................................................................................................19 Git Tools............................................................................................................................................. 21 GitHub API.........................................................................................................................................22


Über Version Control Warum Version Control? Mit zunehmender Größe eines Software-Projekts wächst der Aufwand den man zur Verwaltung des Quelltextes aufbringen muss. Änderungen müssen protokolliert werden um beispielsweise im Falle eines Software-Fehlers zu einer früheren Phase des Projekts zurück zu kommen. Eine häufig genutzte Möglichkeit ist es eine Kopie des Projektes anzulegen, für den Fall dass man zu dieser Version zurückkehren möchte. Das hat allerdings einen entscheidenden Nachteil: Besonders bei größeren Software-Projekten werden viele Dateien redundant gespeichert. Auch muss der gesamte Status des Projekts protokolliert werden. Mit der Zentralisierung des Projekts wächst auch die Empfindlichkeit des Projekts, da alle Dateien auf einer Festplatte gespeichert werden. Aus diesem Grund werden Version Control Systems (Versionsverwaltungssysteme) entwickelt. Bei VCS handelt es sich um Software, welche die Pflege der Quelltexte eines Software-Projektes erleichtern soll. Ein Versionsverwaltungssystem bietet einem mehrere Möglichkeiten zur Protokollierung, Wiederherstellung, Archivierung und Koordination eines Software-Projekts.

Arten der Versionsverwaltung Je nachdem, wie das „Working Dictionary“ (Die Dateien zur Protokollierung der Änderungen) abgespeichert wird, unterscheidet man grundsätzlich zwischen 3 Arten der Versionsverwaltung: – – –

Lokale Versionsverwaltung Zentrale Versionsverwaltung Verteilte Versionsverwaltung

Bei der lokalen Versionsverwaltung wird die komplette Versionsgeschichte in einer einzigen Datei gespeichert. Die Versionsinformationen werden dabei in Form von Zeitstempeln in das zu versionierende Dokument geschrieben. Bei der zentralen Versionsverwaltung erfolgt die Versionierung in einem zentralen Projektarchiv, der Repository. Beispiele für diese Art von VCS sind Apache Subversion (SVN) und das mittlerweile eingestellte Concurrent Version System (CVS). Die dritte Gruppe von VCS-Systemen ist die verteilte Versionsverwaltung (auch: Distributed Version Control Systems). Bei dieser Art der Versionsverwaltung erthält jeder Entwickler eines Software-Projekts eine Kopie sowohl von den Daten, als auch eine Kopie des Working Dictionary. Der Unterschied zwischen der zentralen Versionsverwaltung liegt darin, dass jede Änderung eines Entwicklers ein neuer Zweig (Branch) innerhalb der Versionsgeschichte repräsentiert. Diese Abzweigungen können schließlich durch einen „Merge“ wieder mit dem „Master“-Branch (also die Hauptentwicklung) verschmolzen werden. Beispiele für diese Art von Programmen sind Bazaar, GNU Arch, Monotone, Mercurial, Darcs und Git.


Git – Entwicklungsgeschichte Nachdem der Linux-Kernel mehr als zehn Jahre ohne Versionsverwaltung entwickelt wurde und der Aufwand die Änderungen an den Quelltexten zu protokollieren immer immenser wurde, entschied man sich 2002 dazu von nun an auf ein Versionsverwaltungssystem zur Pflege und Protokollierung des Quellcodes zu setzen. Die Wahl fiel auf das proprietäre Programm BitKeeper der amerikanischen Firma BitMover, da BitKeeper das einzige VCS war, mit dem man automatisiert eine Umstellung der Quelltexte des Linux-Quellcodes vornehmen konnte. Obwohl BitMover zugunsten der Open Source Development Labs (ODSL - Eine None-ProfitOrganisation, die für die Entwicklung des Linux-Kernels verantwortlich ist) handelte und eine freie Lizenz veröffentlichte, hatten dennoch viele Entwickler und Verfechter freier Software Bedenken an dem Einsatz unfreier Software in Open Source Projekten. Es sollte sich zeigen, dass die Bedenken der Linux-Entwickler nicht grundlos waren, denn im April 2005 zog BitMover überraschend die freie Lizenz zurück. Grund hierfür war die Entwicklung von OSDL-Mitglied Andrew Tridgell an einem BitKeeper-kompitablen und freien VCS namens SourcePuller, welches bei den Entwicklern für Unmut sorgte. Larry McVoy, Chef von BitMoover sprach von Reverse Engineering und einem „unmoralischen Akt“. Als Folge sollte BitMover keine freien Lizenzen mehr an Angestellte von OSDL vergeben. Da eine kommerzielle Lizenz für die Linux-Entwicklung keine Alternative darstellte, begann ein Team unter der Leitung von Linux-Erfinder Linus Torvalds noch im selben Monat die Arbeit an einer eigenen, freien Software zur Versionsverwaltung. Nachdem das Projekt am 6. April angekündigt wurde erschien bereits am nächstem Tag die erste Version von „Git“.


Warum Git? –

Sichere Datenübertragung per SSH Die Daten werden sicher und verschlüsselt zwischen der lokalen und der Remote-Repository versendet.

Verteilte Versionsverwaltung Jeder Entwickler eines Software-Projekts erhält eine lokale Kopie des gesamten Projekts bzw. der Repository.

Ideal für große Projekte Git wurde ursprünglich zur Verwaltung des Linux-Quellcodes entwickelt, mit dem Ziel ein schnelles und skalierendes Versionsverwaltungssystem zur Verwaltung sehr langer CommitHistories, zu erschaffen.

Nicht lineare Entwicklung durch Branching und Merging Innerhalb der Entwicklung können verschiedene Entwicklungszweige erstellt („Branching“) und miteinander verschmolzen („Merging“) werden. Dieses Feature ist integraler Bestandteil von Git.

Erweiterbarkeit durch Tools Es gibt viele Tools für Git. So ist es zum Beispiel möglich eine grafische Benutzeroberfläche für das Kommandozeilen-Programm zu installieren.

Freie Software Git ist unter der GPL-Lizenz lizenziert und somit freie Software (Open Source).

Aktive Community Viele große und bekannte Open-Source-Projekte nutzen für die Verwaltung ihres Quelltexts Git, unter anderem: –

Linux

Ruby

Ruby on Rails

PHP

Perl

Jquery

Erlang


GitHub Mit über 1.000.000 öffentlichen Repositories ist GitHub mit Abstand der größte und meistgenutzte Webhoster für Git-Repositories. Der Dienst wurde im August 2005 von der gleichnamigen Trägerfirma mit Sitz in San Francisco gegründet. Durch die Möglichkeit beliebig viele öffentliche Repositories zu erstellen, ist GitHub besonders unter Open-Source-Entwicklern beliebt. Im Gegensatz zu anderen Hostern von Git-Repositories wird bei GitHub das „Forken“, das Erstellen von Abspaltungen, besonders propagiert. GitHub versteht sich nicht nur als Hoster von Repositories, sondern auch als soziales Netzwerk für Entwickler, was sich auch in der Möglichkeit einem Projekt zu „folgen“ oder einem Entwickler zu beobachten widerspiegelt. Den Webdienst GitHub erreicht man unter https://github.com/.

Wer nutzt GitHub? Eine unglaubliche Vielzahl von bekannten Open-Source-Projekten setzen beim Hosting ihrer Repositories auf GitHub, unter anderem: –

Ruby

Ruby On Rails

PHP

Perl

JQuery

Erlang

Node.js

sowie das Programm Git selbst.


GitHub Preise Open Source Projekte können auf GitHub kostenlos erstellt werden. Es können dann beliebig viele Personen an dem Quelltext mitarbeiten, der frei zugänglich ist. Für Unternehmen müssen die Projekte aber privat sein, das hat dann seinen Preis. Je nach Anzahl der unterschiedlichen Projekte zahlt man zwischen 25$ und 200$ im Monat.

Öffentliches Projekt (Open Source) Unbegrenzte Repositories

Unbegrenzte Mitarbeiteranzahl kostenlos

Privates Projekt 5 private Repositories

1 Mitarbeiter

7$ (5,37€) / Monat

10 private Repositories

5 Mitarbeiter

12$ (9,21€) / Monat

20 private Repositories

10 Mitarbeiter

22$ (16,89€) / Monat

10 private Repositories

Unbegrenzte Teams

25$ (19,19€) / Monat

20 private Repositories

Unbegrenzte Teams

50$ (38,38€) / Monat

50 private Repositories

Unbegrenzte Teams

100$ (76,77€) / Monat

125 private Repositories

Unbegrenzte Teams

200$ (153,55€) / Monat

Business Projekt

GitHub Features •

Teamverwaltung Es können unterschiedliche Rechte für verschiedene Arbeitsgruppen verteilt werden

Fehleranalyse Fehlerhafter Code kann in GitHub von den Mitarbeitern markiert und kommentiert werden.

Fehlerbehebung Änderungen können in GitHub analysiert werden und verschiedene Versionen können miteinander verglichen werden.


Installation Die Installation von Git ist in jedem Unix basiertem System (wie Linux, BSD und Mac OS X), aber auch unter Windows mit installiertem CygWin oder msysGit möglich. In diesem Beispiel wird die Installation von Git ohne GUI (engl. „Graphical User Interface“, Grafische Benutzeroberfläche) erläutert. Die Bezugsquellen von GUIs werden in dem Kapitel „Tools“ erläutert. Die Installer für Windows und Mac OS sind jeweils unter http://git-scm.com/download zu finden.

Installation unter Linux: Die einfachste Möglichkeit besteht darin Git mithilfe eines Smart Package Managers zu installieren. In diesem Beispiel wird jeweils einmal der APT (Advanced Package Tool Manager) und der YUM (Yellowdog Updater, Modified) benutzt. apt-get install git-core bzw. yum install git-core Alternativ kann Git ohne Paket-Manager mit dem Linux-Programm „make“ direkt aus den Quelldateien kompiliert und installiert werden. Die Quelldateien findet man als TAR-Archiv unter http://code.google.com/p/git-core/downloads/detail?name=git-1.7.7.5.tar.gz. Nach dem Herunterladen müssen die Dateien zunächst mit tar -zxf git-<versionsnummer>.tar.gz entpackt werden. Danach wechselt man in den entpackten Ordner und führt make aus um Git zu installieren: $ make prefix=/usr all $ sudo make prefix=/usr install

Installation unter Mac OS Um Git unter Mac OS X zu installieren muss lediglich der Installer für Mac OS heruntergeladen und ausgeführt werden. Das Programm ist nach der Installation einsatzbereit.

Installation unter Windows Um Git auf einem Windows-Rechner zu installieren wird eine CygWin oder msysGit-Installation auf dem Zielsystem benötigt um die Kompatibilität mit Git herzustellen. Während der Installation muss die jeweilige Unix-Umgebung (CygWin oder msysGit), sowie der Verzeichnisordner für Git ausgewählt werden.


Git und GitHub Einrichtung Unter https://github.com/signup/free erstellen wir uns jetzt einen kostenlosen Zugang zu GitHub. Daf端r braucht man nur einen Benutzernamen, eine Email-Adresse und ein Passwort einzugeben und schon ist man startbereit.

Nach erfolgreicher Anmeldung landet man auf dieser Startseite.


SSH Schlüssel erzeugen SSH (Secure Shell) ist ein Netzwerkprotokoll mit dessen Hilfe ein sicherer Datenaustausch mit github.com oder einem eigenen Server hergestellt wird. Wir benötigen einen Schlüssel, den wir GitHub mitteilen und dafür stellt die Git Software ein Programm bereit. Mit der Kommandozeile wechseln wir in das Installationsverzeichnis von Git (C:\Programme\Git\bin) oder benutzen alternativ die Git Bash. Bei der Abfrage "Enter file in which to save the key" können wir einfach Enter drücken. Ein Passwort müssen wir aber trotz der Sicherung durch SSH zusätzlich eingeben. ssh-keygen -t rsa -C "email@adresse.de" Generating public/private rsa key pair. Enter file in which to save the key (/c/Users/Benutzer/.ssh/id_rsa): Created directory '/c/Users/Benutzer/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /c/Users/Benutzer/.ssh/id_rsa. Your public key has been saved in /c/Users/Benutzer/.ssh/id_rsa.pub. Die Datei c:/Users/Benutzer/.ssh/id_rsa.pub öffnen wir mit einem Texteditor und kopieren uns den gesamten Text in die Zwischenablage. Diesen Schlüssel geben wir auf github.com unter "Account Settings" bei "SSH Public Keys" an. (https://github.com/account)


Zur Überprüfung ob alles funktioniert hat testen wir mit folgendem Befehl. ssh -T git@github.com The authenticity of host 'github.com (207.97.227.239)' can't be established RSA key fingerprint is 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'github.com,207.97.227.239' (RSA) to the list of hosts. Enter passphrase for key '/c/Users/Benutzer/.ssh/id_rsa': Hi fhd-github-doku! You've successfully authenticated, but GitHub does not provide shell access.

Git einrichten Für jedes Betriebssystem gibt es eigene grafische Benutzeroberflächen um mit Git zu arbeiten. Wir werden hier aber die Kommandozeile benutzen, deren Verwendung auf jedem Betriebssystem gleich abläuft.

Erste Konfiguration in Git: Wer bin ich? Um Git benutzen zu können, müssen wir beim ersten Mal in der Kommandozeile einen Benutzernamen und die Email-Adresse konfigurieren. Diese Informationen identifizieren hinterher bei Änderungen den Verfasser. git config --global user.name "Benutzer" git config --global user.email "email@adresse.de" Der Parameter --global gibt an, dass diese Daten Standard für alle Arbeiten sein sollen. Man kann aber auch für ein bestimmtes Projekt z.B. die Email-Adresse wie folgt ändern: git config projekt.email "email@adresse.de" Damit wir unser Projekt auch auf GitHub hochladen können müssen wir noch unseren GitHub Benutzernamen eingeben und ein API Token, welches wir unter den "Account Settings" bei "Account Admin" auf github.com finden. Das API Token müssen wir, falls wir das Passwort ändern ebenfalls neu angeben.


git config --global github.user GitHub-Benutzername git config --global github.token 1234567.......


Die erste Repository Fangen wir an mit einem Hallo Welt Projekt und erstellen dafür einen neuen Ordner namens "MeinGITRepo". In dieses Verzeichnis wechseln wir dann und initialisieren unser Git Repository1 mit dem Befehl: git init Als Bestätigung bekommen wir die Meldung Initialized empty Git repository in E:/_projekte/MeinGITRepo/.git/ In dem Unterordner .git wurde nun eine Verzeichnisstruktur erstellt, in welcher die Änderungen an dem Projekt festgehalten werden. Der Befehl git status zeigt an, welche Dateien sich in dem Ordner befinden, die noch nicht dem Repository hinzugefügt wurden. Da wir ein leeres Projekt haben, sieht die Ausgabe wie folgt aus: git status # On branch master # Initial commit nothing to commit (create/copy files and use "git add" to track) Nun wollen wir eine erste Datei an die Versionsverwaltung übergeben. Man kann jede beliebige Datei, wie eine Grafik oder einen Quelltext verwenden und in den Arbeitsordner einfügen. Wir beginnen hier mit der Erzeugung einer einfachen Textdatei mit dem Inhalt "Hello World". Diese wird als README.txt gespeichert. Danach geben wir noch einmal "git status" ein: echo "Hello World" > README.txt git status # On branch master # Initial commit # Untracked files: # (use "git add <file>..." to include in what will be committed) # README.txt nothing added to commit but untracked files present (use "git add" to track)

1

Repository (deutsch: Ablage, Depot) Das Repository ist die Sammlung aller eingespielten Dateien. Es bildet praktisch die explizit bestätigten Dateien aus unserem Arbeitsverzeichnis ab.


Die README Datei wird hier unter "Untracked files" aufgelistet. Git registriert jede Änderung im Projekt Ordner und gibt diese im Status aus. Eine neue Datei wird aber nicht automatisch in das Repository eingefügt. Das hat den Vorteil, dass man freier arbeiten kann, weil nicht jede temporär angelegte Datei direkt und für immer in der Versions-Historie hinterlegt ist. Wir wollen aber die README.txt in unser Projekt aufnehmen und dafür benutzen wir den Befehl: git add README.txt # On branch master # Initial commit # Changes to be committed: # (use "git rm --cached <file>..." to unstage) # new file: README.txt Die Datei ist jetzt als staged2 markiert. Damit ist die Datei noch nicht im Projekt verankert, sondern wartet darauf in die neue Version aufgenommen zu werden. Mit "git commit"3 schiebt man die Datei dann in das Projekt. Der Parameter -m erlaubt es einem danach eine Beschreibung der neuen Version anzugeben.

2

Staging Area (deutsch: Bereitstellungsraum, Sammelpunkt) In diesen Bereich werden Abbilder unserer Dateien geschoben, bevor wir sie in das Repository übergeben. Eine Datei, die in diesen Bereich geschoben wurde, befindet sich dann im staged-Status. 3 Commit (deutsch: Übergabe) Dateien in unserem Arbeitsverzeichnis werden erst in das Repository aufgenommen, wenn wir auch mit einem Commit unsere Änderungen bestätigen und einfügen.


git commit -m "README Datei erzeugt" [master (root-commit) 92848b7] README Datei erzeugt 1 files changed, 1 insertions(+), 0 deletions(-) create mode 100644 README.txt git status # On branch master nothing to commit (working directory clean) Der Status zeigt, dass jetzt alle Änderungen übernommen wurden und es keine neuen oder veränderten Dateien gibt. Die Commit-Beschreibung können wir uns mit git log ansehen. git log commit 92848b75e76d9cb062cb2cf941fbdfdb4fa2525c Author: Benutzer <email@adresse.de> Date: Mon Nov 21 15:16:06 2011 +0100 README Datei erzeugt Die Commits werden mit einem SHA-Hash4 identifiziert, hier lautet er 92848b75e... Erstellen wir nun eine HTML-Datei und speichern sie als index.html ab. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <head> <title>Hello World</title> </head> <body> </body> </html> Im Status wird sie wieder als untracked gelistet. Mit der Kurzform "git add ." können wir Git nun mitteilen, dass alle Dateien im aktuellen Verzeichnis hinzugefügt werden sollen. Bevor wir nun aber die Veränderungen speichern, ändern wir noch einmal die index.html und fügen im <body>Teil den Text "<p>Hier entsteht eine Beispielseite.</p>" ein. git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # new file: index.html # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # modified: index.html 4

SHA: Secure Hash Algorithm SHA wird hier zur Überwachung von Änderungen an den Dateien verwendet. Der SHA-Hash wird durch den Inhalt z.B. den HTML Quelltext der index.html errechnet. Dieser Hash besteht aus 40 Zeichen (Buchstaben und Zahlen). Fügt man weiteren Text in die HTML Datei hinzu wird mit Hilfe von SHA erneut der Hash berechnet, der sich daraufhin verändert hat.


Man kann sich die Unterschiede zwischen der Datei im staged-Zustand und nach der Bearbeitung mit dem Befehl "git diff" anzeigen lassen: git diff diff --git a/index.html b/index.html index edd6dd9..c6e4e2a 100644 --- a/index.html +++ b/index.html @@ -5,6 +5,6 @@ <title>Hello World</title> </head> <body> +<p>Hier entsteht eine Beispielseite.</p> </body> </html> \ No newline at end of file Wenn man aber hingegen sehen will, welche Änderungen in den Dateien vorgenommen wurden, die staged sind, fügt man den Parameter "--cached" hinzu. git diff --cached diff --git a/index.html b/index.html new file mode 100644 index 0000000..edd6dd9 --- /dev/null +++ b/index.html @@ -0,0 +1,10 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" + "http://www.w3.org/TR/html4/loose.dtd"> +<html> +<head> +<title>Hello World</title> +</head> +<body> + +</body> +</html> \ No newline at end of file Wir wollen jetzt die HTML-Datei in unser Repository einfügen und dabei die Änderungen, die noch nicht staged sind ebenfalls mit abspeichern. Anstatt erneut den Befehl "git add" zu benutzen, können wir den Paramater -a bei commit verwenden. Das bewirkt, dass alle Modifikationen an Dateien, die wir bereits einmal gestaged haben übernommen werden. git commit -am "HTML Index erzeugt" [master ae01689] HTML Index erzeugt 1 files changed, 10 insertions(+), 0 deletions(-) create mode 100644 index.html Sehen wir uns nun die Funktion zur Wiederherstellung einer älteren Version an. Dazu löschen wir zunächst die README Datei. Gehen wir davon aus dass wir die Datei versehentlich gelöscht


hätten, dann können wir das ganz einfach mit "git checkout -f" rückgängig machen. Es wird dadurch der Zustand des letzten commit hergestellt und die README.txt wird wiederhergestellt. Zu beachten ist dabei, dass die Datei nach dem Löschen im Git Status als "not staged" deklariert wurde. Wenn man also dauerhaft etwas aus unserem Repository entfernen möchte, muss man das Git auch wieder explizit mitteilen, indem man den Befehl "git rm" benutzt. git rm README.txt git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # deleted: README.txt Dieser Befehl löscht die Datei aus dem Verzeichnis und setzt die Änderung in den staged-Status.

Verbindung mit GitHub Bislang haben wir nur offline gearbeitet. Jetzt wollen wir aber unser Projekt auf GitHub hochladen. Zunächst loggen wir uns auf github.com ein und erstellen dort ein Repository mit dem Namen MeinGITRepo.

In der Kommandozeile konfigurieren wir Git mit unserem GitHub Benutzernamen und dem Online Repository. git remote add MeinGITRepo git@github.com:Benutzername/MeinGITRepo.git


Das Projekt laden wir daraufhin auf github.com hoch (pushen). git push -u MeinGITRepo master Enter passphrase for key '/c/Users/vincent/.ssh/id_rsa': Counting objects: 6, done. Delta compression using up to 4 threads. Compressing objects: 100% (4/4), done. Writing objects: 100% (6/6), 663 bytes, done. Total 6 (delta 0), reused 0 (delta 0) To git@github.com:Benutzername/MeinGITRepo.git * [new branch] master -> master Branch master set up to track remote branch master from MeinGITRepo. Mit diesem Befehl speichern wir nun immer unsere offline Ă„nderungen auf dem Server ab.


Branching und Merging Arbeiten wir mit mehreren Personen an einem Projekt, so kann es vorkommen, dass Änderungen an Dateien von anderen vorgenommen wurden und das Pushen zu einer Fehlermeldung führt. Um das zu Verhindern, muss das offline Repository immer auf dem neusten Stand sein. git fetch MeinGITRepo "git fetch" lädt die aktuellste Version des Projekts von GitHub herunter, allerdings ohne dabei unser Projekt direkt zu verändern. Die Unterschiede zwischen den Versionen kann man sich mit "git diff" anzeigen lassen und daraufhin mit dem Befehl "git merge" die Änderungen anwenden. git diff master MeinGITRepo/master git merge MeinGITRepo/master Der Zusatz "master" bezeichnet unseren Haupt-Arbeitszweig (Branch5). Es ist ratsam nicht immer auf diesem Branch zu arbeiten. Will man zum Beispiel etwas ausprobieren oder muss neben der eigentlichen Arbeit schnell einen Fehler an einer anderen Stelle beheben, so erstellt man hierfür einen neuen Zweig mit "git branch". git branch experimental Wir befinden uns danach immer noch im "master" Branch. Der Wechsel in den experimentellen Arbeitszweig erfolgt mit: git checkout experimental Für die beiden Befehle gibt es aber auch eine Kurzform. git checkout -b experimental Das Arbeiten auf diesem neuen Zweig probieren wir aus, indem wir eine neue HTML-Datei "experiment.html" erstellen. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <head> <title>Experiment</title> </head> <body> <p>Hier kann man neue Ideen ausprobieren.</p> </body> </html> 5

Branch (deutsch: Ableger, Abzweigung) Ein Branch ist eine Referenz auf ein Commit. Es wird dazu benutzt Zusatzinformationen über das Commit bereitzustellen, wie einen Namen und historischen Verlauf der Veränderungen. Dabei ist zu beachten, dass ein Branch immer den Namen des letzten Commits erhält.


Die neue Datei fügen wir dann wieder unserem Repository hinzu und laden sie hoch. git add . git commit -am "Experimentelle Seite erzeugt" git push MeinGITRepo experimental Enter passphrase for key '/c/Users/vincent/.ssh/id_rsa': Counting objects: 4, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 471 bytes, done. Total 3 (delta 0), reused 0 (delta 0) To git@github.com:fhd-github-doku/MeinGitRepo.git aa8bf88..2003851 experimental -> experimental Wenn die Arbeiten in diesem Branch erfolgreich verliefen und wir die neue Datei in unseren "master" Branch aufnehmen wollen, wechseln wir zurück auf den Haupt-Zweig und verbinden die beiden miteinander. git checkout master Switched to branch 'master' git merge experimental Updating aa8bf88..2003851 Fast-forward experiment.html | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) create mode 100644 experiment.html Als letztes können wir nun den experimentellen Branch wieder löschen. git branch -d experimental Deleted branch experimental (was 2003851).


Git Tools Für Git existieren eine Vielzahl von Add-Ons und Tools. Der größte Teil dieser Software steht wie das Programm Git unter der GPL-Lizenz und wird von einer aktiven Entwickler-Gemeinde entwickelt. Die Auswahl reicht von Grafischen Benutzeroberflächen bis hin zu Tools, die beispielsweise Git in den Windows-Browser integrieren lassen. Hier sind einige nützliche und bekannte Git Tools aufgelistet: •

Tortoise Git Ein Git-Client für Windows der sich auch in den Windows-Explorer integrieren lässt. http://code.google.com/p/tortoisegit/

Git Extensions ein weiteres Add-On durch das sich Git in den Explorer von Windows integrieren lässt. Darüber hinaus bietet es auch ein Kontextmenü für Dateien an. http://sourceforge.net/projects/gitextensions/

GitHub for Mac Eine Grafische Benutzeroberfläche für Git. Diese GUI wurde speziell für das Hosting bei GitHub optimiert, funktioniert aber auch mit jedem anderen Git-Server. http://mac.github.com/

git-cola Ein elegantes Git-GUI für Windows, Mac OS X und Linux. http://git-cola.github.com/downloads.html

SmartGit Ein in Java geschriebenes, plattformunabhängiges GUI. SmartGit kann zudem als Client für das Versionskontrollsystem SVN genutzt werden. http://www.syntevo.com/smartgit/index.html

Agit Git für Unterwegs. Agit ist ein Git-Client speziell für Android-Smartphones und Tablets. Die App ist kostenpflichtig über den Android-Market erhältlich.


GitHub API Eine API (Application Programming Interface, engl. Programmierschnittstelle) bietet die Möglichkeit Programmteile an ein bestehendes System anbinden zu lassen. Wie viele andere Webdienste und soziale Netzwerke stellt GitHub seinen Benutzern eine umfangreiche API zur Verfügung. Die GitHub-API ermöglicht unter anderem Zugriff auf die Repository, die Profilinformationen und die Aktivitäten. Der Zugriff auf die GitHub API erfolgt über das HTTPS-Protokoll im JSON-Format. Das JSONFormat (JavaScript Object Notation) ist ein Daten-Format in JavaScript zur Strukturierung von Daten in Mensch- und Maschinen-lesbarer Form. JSON wird hauptsächlich zum Austausch von Informationen zwischen Anwendungen verwendet, ähnlich wie XML. Die ausführliche Dokumentation der API findet man unter http://developer.github.com/v3/.