Ich möchte hier eine Schnell-Anleitung (eventuell mit Fortsetzung) zur Nutzung von Git (und GitHub) allein mit Windows-Tools aufzeigen, wobei bewusst auf Linux-Mitteln wie z.B. die Konsole, wo möglich und zweckdienlich, verzichtet wird.

Die Software

Wir benötigen: Sourcetree

Sourcetree ist ein Git-Client, der eine grafische Benutzeroberfläche bereitstellt. Mit Sourcetree können Benutzer Repositories erstellen, klonen, committen und pushen sowie alle Änderungen protokollieren und vergleichen. (Git-)Repositories sind Speicherorte, in denen Git-Projekte verwaltet werden, einschließlich aller Dateiversionen und des Projektverlaufs.

Die Installation gestaltet sich einfach. Einen Bitbucket-Account benötigen wir nicht, daher drücken wir „Skip“.

Im nächsten Schritt deaktivieren wir „Mercurial“, das ebenfalls nicht benötigt wird. Aber ich würde empfehlen, den Haken bei „Configure automatic line handling …“ zu setzen. Das ist praktischer, falls wir irgendwann einmal zwischen dem Windows- und Linux-Universum Dateien austauschen möchten. Ansonsten würden sich bei jedem Auschecken von Code die Zeilenumbrüche verdoppeln, das liegt an der Art und Weise, wie Windows Zeilenumbrüche speichert und würde jetzt en détail zu weit führen.

In den Preferences geben Sie zum Schluss noch ihre Daten ein.

Die Startseite der Software sollte sich uns folgendermaßen präsentieren:

Um nun weiterzukommen, müssen wir unbedingt verstehen, was es mit SSH-Schlüsseln auf sich hat, daher an dieser Stelle ein kleiner Exkurs über das Thema. Kenner können darüber hinweglesen.

Exkurs: SSH und SSH-Schlüsselpaare

SSH steht für „Secure Shell“ und ist ein Verschlüsselungsprotokoll, das für die Kommunikation zwischen zwei Computern verwendet wird.

Zur Anwendung kommen dabei SSH-Schlüsselpaare, die jeder Nutzer zunächst individuell erzeugen muss. Dieses Schlüsselpaar ist weltweit einzigartig. Ein Schlüsselpaar besteht immer aus einem privaten und einem öffentlichen Schlüssel. Nur der öffentliche und der private Schlüssel desselben Schlüsselpaares passen zusammen. Besitzt man nur einen von beiden Schlüssel, kann man nichts damit anfangen, man benötigt immer beide.

Der öffentliche SSH-Schlüssel ist für alle zugänglich (so verrät es ja der Name) und sollte allen Parteien, mit denen man kommunizieren möchte, zur Verfügung gestellt werden, indem man ihn zum Beispiel auf der eigenen Website veröffentlicht.

Der private Schlüssel hingegen – auch das verrät schon der Name – darf unter keinen Umständen in fremde Hände geraten, denn sonst wäre das gesamte Schlüsselpaar kompromittiert.

Möchte man also mit einem Server kommunizieren, muss man dafür sorgen, dass der Server den öffentlichen Schlüssel erhält (wie das funktioniert, erkläre ich gleich). Man selbst identifiziert sich dann mit dem auf dem eigenen Rechner verbliebenen privaten Schlüssel. Wenn man alles richtig eingestellt hat, erfolgt die weitere Arbeit bzw. Kommunikation von da an reibungslos und automatisch.

Wir erzeugen ein Schlüsselpaar

Ich empfehle, auch wenn man dafür mit der Kommandozeile arbeiten muss, das Schlüsselpaar mit Windows-Bordmitteln zu erzeugen, da es mit Sourcetree meinem Erachten nach zu kompliziert ist.

Wir öffnen die Kommandozeile auf Windows und geben folgende Befehle ein:

cd %USERPROFILE%
mkdir .ssh
cd .ssh
ssh-keygen

Kurze Erklärung: Wir legen in unserem Benutzer-Verzeichnis den Ordner „.ssh“ an. Bitte den Punkt nicht vergessen! Wir wechseln in das Verzeichnis und legen ein Schlüsselpaar an.

Als Ergebnis erhalten wir zwei Dateien:

• id_rsa – das ist der private Schlüssel
• id_rsa.pub – das ist der öffentliche Schlüssel

Wer möchte, kann den privaten Schlüssel mit einem Passwort absichern (siehe roter Pfeil). Dies verschafft zusätzliche Sicherheit, falls der private Schlüssel doch einmal in die falschen Hände geraten sollte. Allerdings hat das auch den Nachteil, dass fortan bei jeder verschlüsselten Kommunikation nach dem Passwort gefragt wird, was den Arbeitsfluss unterbrechen kann. Das zusätzliche Passwort ist keine Pflicht, jeder muss für sich selbst darüber entscheiden.

Der öffentliche Schlüssel erhält die Endung „.pub“, der private gar keine.

WICHTIG: Denken Sie daran, für beide Schlüssel Backups anzulegen. Denn sollten Sie einen von beiden verlieren, müssen Sie wieder ein neues Paar anlegen.

Was ist denn jetzt GitHub und was haben wir damit zu tun?

GitHub ist eine Webplattform, die auf das Git-basierte Versionskontrollsystem spezialisiert ist. Mit GitHub können Entwickler, Teams und Organisationen ihre Softwareprojekte hosten, verwalten und mit anderen teilen. Die Funktionen von GitHub erleichtern die Zusammenarbeit zwischen Entwicklern und die Fehlerbehebung und Verbesserung von Softwareprojekten. GitHub bietet Entwicklern und Teams eine Plattform zur Verwaltung von Code, zur Zusammenarbeit und zur Integration in Workflow-Tools.

Damit wir jetzt mit GitHub kommunizieren können, müssen wir dort unseren öffentlichen Schlüssel hinterlassen. Dazu können Sie entweder selbst ein Konto bei GitHub anlegen oder Sie nutzen ein bereits bestehendes Konto, z.B. ein Konto ihres Unternehmens. Im letzten Fall müssen Sie ihren öffentlichen Schlüssel an den Administrator des Kontos schicken, damit dieser die folgenden Schritte erledigt.

GitHub bekommt unseren öffentlichen Schlüssel

Um einen öffentlichen SSH-Schlüssel Ihrem GitHub-Konto hinzuzufügen, können Sie die folgenden Schritte ausführen:

Kopieren Sie den Inhalt der öffentlichen Schlüsseldatei (hier: .ssh/id_rsa.pub) komplett in die Zwischenablage. Das können Sie wie gewohnt mit der Maus erledigen: Markieren und mit STRG+C kopieren.

type id_rsa.pub

Gehen Sie zu Ihrem GitHub-Konto und klicken Sie auf das Dropdown-Menü in der oberen rechten Ecke. Wählen Sie „Settings“ aus.

Klicken Sie im linken Menü auf „SSH and GPG Keys“.

Klicken Sie dann auf „new SSH key“

Geben Sie einen Titel für den Schlüssel ein (z.B. „RSA Schüssel von Martin Mustermann für Maschine 1“). Behalten Sie die Auswahl „Authentication key“ bei. Fügen Sie den Inhalt des öffentlichen Schlüssels in das Feld „Key“ ein. Klicken Sie auf „Add SSH key“.

Danach sollten Sie folgenden Bildschirm erhalten:

Mehr Informationen zum Thema SSH und GitHub

Der private Schlüssel für Sourcetree

Damit nun die verschlüsselte Kommunikation mit GitHub und Sourcetree erfolgen kann, müssen Sie in Sourcetree ihren privaten Schlüssel hinterlegen.

In Tools->Options->General nehmen Sie unter „SSH Client Configuration“ folgende Anpassungen vor:

Und natürlich geben Sie in „SSH Key“ ihren privaten Schüssel an, nicht den öffentlichen.

Das sollte es dann schon gewesen sein.

GitHub – der erste Kontakt

Wenn wir jetzt zum ersten Mal mit GitHub arbeiten möchten, gibt es zwei initiale Möglichkeiten, die den allergrößten Teil der Varianten abdecken. a) Entweder es existiert schon ein Repository auf GitHub, weil z.B. schon andere Kollegen damit arbeiten oder b) Sie legen selbst ein Repository dafür an, weil Sie selbst der Verantwortliche sind.

a) Das Repository existiert bereits.

Sollten Sie neu zu einem Projekt dazustoßen, so müssen Sie zunächst dafür sorgen, dass sie das entfernte Repository von GitHub (man sagt auch „remote Repository“) auf ihren lokalen Rechner kopieren. (Kleine Anmerkung: Sie können das auch auf mehrere ihrer Entwicklungs- und/oder Testrechner parallel machen, Git und GitHub koordinieren das automatisch.)

In der Sprache von Git heißt dieses Kopieren „Klonen“.

Der Verantwortliche für das Repository sollte Ihnen eine spezielle URL mitteilen, die in unserem Falle folgendermaßen aussieht:

git@github.com:martin-mustermann-firmenname/sourcetree-tutorial.git

Wenn Sie die URL nun in das Feld für „Source Path/URL“ eintragen, sollte Sourcetree keine Beanstandungen melden. Das lokale Verzeichnis auf ihrem Rechner wird automatisch vorgeschlagen, Sie können hier auch ein anderes wählen. (In diesem Beispiele sieht die URL etwas anders auf. Aber grundsätzlich ist der Aufbau identisch.)

Nach dem Klonen sollte ihr Bildschirm noch recht „jungfräulich“ aussehen.

Wie wir die ersten Dateien lokal verändern und zu GitHub hochladen, werden wir im nächsten Artikel besprechen. Kommen wir nun zu dem Fall, dass Sie das lokale Repository selbst anlegen.

b) Wir legen das Repository selbst an

Dazu wechseln wir zur Website von GitHub und wählen uns dort mit unseren Konto-Daten ein. In dem Menü rechts oben legen wir mit „New repository“ ein neues remote Repository an.

Den Namen des Projekts dürfen Sie frei wählen, sofern nicht schon ein gleichnamiges in ihrem Konto existiert.

Ich würde bei Projekten in Unternehmen auf jeden Fall die Option „Private“ aktivieren, weil sonst der Code jedem Nutzer weltweit zum Download bereitgestellt wird. Dieser Umstand rührt daher, dass GitHub ursprünglich eine Website zum gemeinschaftlichen Erstellen von Software-Projekten im Open-Source-Bereich war.

Damit wir wenigstens schon eine Datei im Repository haben, lassen wir die Datei „README.md“ automatisch anlegen. Diese können wir dann nachträglich noch anpassen.

Die README.md Datei ist eine zentrale Komponente eines jeden GitHub Repositories. Sie ist ein Markdown-Dokument, das im Hauptverzeichnis platziert wird, und dient dazu, eine Beschreibung des Projekts zu geben. Ferner kann sie als Einstiegspunkt in das Projekt dienen, indem sie den Benutzern Informationen zum Einrichten, Ausführen und Testen des Codes gibt. Die README.md Datei kann auch genutzt werden, um Links zu wichtigen Ressourcen wie Dokumentation, Demo-Videos, Support-Websites und anderen Projekt-Tools bereitzustellen.

Auf der Startseite des Projekts wird dann automatisch der Inhalt der README.md-Dateien angezeigt.

Unter dem grün hinterlegten Knopf „Code“ können wir jetzt die URL aufrufen, wie wir sie aus dem Kapitel „c) Das Repository existiert bereits“ schon kennen. Bitte verfahren Sie damit analog, um das neue Repository auf ihren lokalen Rechner zu klonen.

Zusammenfassung: Wir haben jetzt gelernt, wie wir für Git und GitHub eine einfache Software (Sourcetree) installieren, die zur verschlüsselten Kommunikation wichtigen SSH-Schlüssel nutzten und wie wir ein erstes Repository anlegen und mit GitHub verknüpfen.

Vorschau: In den nächsten Beiträgen wird es darum gehen, Dateien im Repository zu ändern, sie in der History mit Kommentaren abzulegen und für unsere Kollegen auf GitHub zur Verfügung zu stellen, und das möglichst konfliktfrei und automatisch.