In diesem und dem nächsten Artikel sollen alltägliche Aufgaben in Git mithilfe des Programms SourceTree erklärt werden. Im Folgenden widmen wir uns zuerst der Ersteinrichtung und dem Arbeiten im Repository Browser. Im nächsten Teil werden wir auch auf die Nutzung der Projektansicht eingehen.
Ersteinrichtung
Beim ersten Start von SourceTree wird man nach Vorname, Nachname und E-Mail-Adresse gefragt. Diese Informationen werden bei Commits berücksichtigt und sollten daher die Arbeits-Mailadresse wiedergeben und mit vollem Namen versehen werden.
Außerdem ist innerhalb der ersten 30 Tage eine Registrierung bei Atlassian notwendig, die jedoch kostenlos gemacht werden kann. Entsprechende Hinweise zeigt SourceTree automatisch an.
Arbeiten im Repository Browser
Nach jedem Start von SourceTree erwartet einen üblicherweise der Repository Browser. Dieser zeigt eine Übersicht aller Repositories, die man lokal auf dem Rechner mithilfe von SourceTree eingerichtet hat. Erneut öffnen kann man ihn über den Menüpunkt "Fenster" >> "Repository Browser anzeigen". Er besitzt auch eine "Remote"-Ansicht, in der alle
Repositories von Hosted Services aufgelistet sind, auf die man Zugriff hat und in denen man sich über die Repository Browser-Einstellungen (Settings-Icon rechts oben) angemeldet hat. Beim nachfolgend beschriebenen Arbeitsstil braucht man die Remote-Ansicht jedoch nicht, weshalb sie komplett ignoriert werden kann.
Der Repository Browser erlaubt es Repositories beliebig zu gruppieren, ohne dass davon die tatsächlichen Pfade der Projekte geändert werden. Nützlich ist dies etwa, um mehrere Code-Projekte zu einem zusammengehörenden Produkt zusammen zu fassen.
Erstellen eines neuen Repositories
Verzeichnisse, die von Git versioniert werden nennt man Repositories. Möchte man Git in einem neuen Projekt verwenden, so muss man aus dem Projektverzeichnis ein Repository machen. Das übernimmt meist schon die Entwicklungsumgebung (z.B. Xcode oder Android Studio) beim Anlegen eines Projektes. Nachfolgend sei kurz die manuelle Einrichtung durch SourceTree geschildert:
Klicke im Repository Browser auf den Button "+ Neues Repository" und wähle "Lokales Repository erstellen". Trage nun als Zielpfad das Verzeichnis ein, in welchem das Repository angelegt werden soll, vergebe einen Namen und klicke auf "Erstellen". Der Haken ist bei "Erstelle auch ein Remote Repository" standardmäßig nicht gesetzt und der Typ steht standardmäßig auf "Git", was beides so bleiben sollte. Damit ist das neue Repository angelegt.
Im Dialog zum Erstellen eines neuen Repositorys trägt man Zielpfad und Name ein.
Ein bestehendes Repository verwenden
Soll man mit einem bestehenden Repository arbeiten, so erhält man in der Regel eine Einladung für den Zugriff auf das Projekt auf einem Hosted Service (z.B. github.com, gitlab.com). Diese Services bieten zwar die Möglichkeit an, den Code etwa als ZIP-Datei herunter zu laden, jedoch ist das nicht empfehlenswert. Stattdessen sollte man nach dem "SSH" bzw. "HTTPS" Pfad Ausschau halten.
Möglichkeiten ein Repository von einem Hosted Service auszuschecken.
Nun markiert und kopiert man entweder den SSH oder den HTTPS Pfad mittels Cmd+C, öffnet SourceTree, bringt den Repository Browser in den Vordergrund und wählt oben unter "+ Neues Repository" den Eintrag "Von URL klonen".
Im Repository Browser können neue Repositories hinzugefügt werden.
Es erscheint ein Dialog, in dem man den kopierten Pfad mittels Cmd+V einfügt, den Zielpfad auswählt, in den die Projektdateien des Projekts heruntergeladen werden sollen und definiert zusätzlich einen Anzeigenamen innerhalb des Repository Browsers.
Beim Klonen kann der Zielpfad und der Anzeigename im Repository Browser festgelegt werden.
Klickt man nun auf den Button "Klone" beginnt der Prozess, der den aktuellen Stand des Repositories vom Hosted Service herunterlädt kurz das Repository wird ausgecheckt.
SSH oder HTTPS?
Grundsätzlich ist es einfacher per HTTPS auszuchecken, da Open Source Repositories dann gänzlich ohne Einrichtung funktionieren und für private Repositories lediglich die Login-Daten abgefragt werden. Daher sei für den Anfang HTTPS empfohlen.
Langfristig kann es jedoch auch Sinn machen auf SSH umzusteigen, da hier die Authentifizierung über ein Public-Key-Verfahren geschieht. Hierzu muss lokal auf dem Rechner eine Kombination aus Private- und Public-Keys generiert werden (falls nicht schon vorhanden), der Public-Key muss anschließend auf dem Hosted Service eingetragen werden, wodurch der Rechner für alle künftigen Projekte (durch den Private-Key) automatisch authentifiziert ist. Zur Einrichtung gibt es viele Anleitungen, zum Beispiel hier jeweils eine für GitHub und eine für GitLab.
