Was ist GitHub?
GitHub ist eine cloud-basierte Plattform zur Versionierung von Software auf Basis der Git-Versionierung. GitHub-Online-Repositories sind sehr beliebt und deswegen weit verbreitet.
GitHub-Remote-Repositories
Während die Git-Umgebung auf Deinem lokalen Rechner Deine persönliche Entwicklungsumgebung abbildet, ist GitHub eine Plattform für Remote-Repositories. Eine solches Remote-Repository ist ein entferntes Repository auf einem anderen Host, zu dem Du Deine Entwicklungsdateien überträgst.
Auf GitHub.com kannst Du deine Repositories gemeinsam mit anderen Entwicklern nutzen um Deine Software im Team zu entwickeln.
GitHub ist ein Version Control System
GitHub – so auch GitLab und die Ausgangsversion Git – sind sogenannte Versionierungs Control Systeme – engl. Version Control Systems – kurz VCS.
Bereits mit wenigen Versionierungs-Prozessen und ein paar einfachen Befehlen kannst Du bei der Softwareentwicklung große Vorteile durch die Git-basierte Versionierung erzielen.
„Für Dich als Software-Entwickler*in ist es nur ein kleiner Schritt zur Versionierung mit Git, aber für jedes agile Software-Projekt im Team ist die Git-Vesionierung ein großer Schritt – ein Meilenstein!“
Sascha Block – Software Architekt
Warum ist die Versionierung von Software so wichtig?
Die Verwendung eines Git-VCS löst nicht nur viele gängige Probleme beim Schreiben von Code, sondern verbessert den gesamten Softwareentwicklungs-Prozess maßgeblich.
Indem Du Deine Code-Entwicklung mit einem Git verfolgen kannst und Deinen Code online hostest, betreibst Du Softwareentwicklung transparent, reproduzierbar und offen für die Zusammenarbeit in agilen Teams.
Wie funktioniert die Git-Versionierung?
Um Git, GitHub oder GitLab zu verstehen ist der erste Schritt, zu lernen, wie Du Deinen eigenen Source-Code versionieren kannst. Klassischerweise wird Git von der Kommandozeile – wie einer der Unix-Shell – ausgeführt.
Inzwischen stehen für die Ausführung von Git zahlreiche grafische Benutzeroberflächen (GUIs) zur Verfügung.
Git per Shell Command steuern
Für die Durchführung fortgeschrittener Operationen und die Verwendung von Git auf einem entfernten Rechner ist es jedoch notwendig, die Verwendung von Git über die Befehlszeile zu erlernen.
Git installieren
Wenn Du Git gerade erst installiert hast, musst Du als Erstes einige Angaben zu Deiner Person machen, da Git aufzeichnet, wer einzelne Änderungen an einer Datei vornimmt. Natürlich lassen eine Vielzahl von Dateien oder Verzeichnissen auf einen Streich versionieren. In all diesen Änderungsdateien ist dann nicht nur Dein „Identitätsstempel“ vermerkt, sondern auch exakt die von Dir durchgeführten Änderungen. Genau das ist das schließlich Sinn und Ziel jeder Versionierung. Lege also Deinen Namen und Deine E-Mail-Adresse fest, indem Du die folgenden Zeilen ausführst, wobei Du „First Last“ und „user@domain“ durch Deinen vollständigen Namen bzw. Deine E-Mail-Adresse ersetzt
$ git config --global user.name "Vorname Nachname"
$ git config --global user.email "user@domain"
Um mit der Versionierung Deines Codes mit Git zu beginnen, navigierst Du bis zu einem Verzeichnis, dass Du speziell für Git neu neu erstellst. Von diesem lokalen Verzeichnis aus, wirst Du zukünftig Deinen Sourcecode versionieren gleich ob dies in Richtung GitHub, GitLab oder sonstwo geschieht.
git init
Führe den Befehl git init aus, um den aktuellen Ordner als Git-Repository zu initialisieren.
Git-Repository und Repository-Verzeichnisse
Ein Repository oder kurz Repo bezieht sich auf die aktuelle Version der verfolgten Dateien sowie auf alle zuvor gespeicherten Versionen.
Nur Dateien, die sich innerhalb eines Repository-Verzeichnisses befinden, nutzen das Potenzial, versionskontrolliert zu werden, d. h. Git ignoriert alle Dateien außerhalb des initialisierten Verzeichnisses.
Aus diesem Grund werden Projekte unter Versionskontrolle in der Regel in einem einzigen Verzeichnis gespeichert, das mit einem einzigen Git-Repository übereinstimmt.
Zu einem Repository-Verzeichnis zählen natürlich auch die darin eingeschlossenen Unterverzeichnisse.
Darüber hinaus gibt es viele weitere Strategien für die optimale Organisation eigener Software-Projekte und Software-Releases.
Die wichtigsten Git-Befehle – Dein Git-Vokabular
Commit
Der Commit ist eine Momentaufnahme der von Dir an den Stagingdateien vorgenommenen Änderungen. Ein Commit in einem Git ist sozusagen ein Backup deines Speicherstands im Git-Projekt mit all deinen an den Stage-Dateien vorgenommenen Änderungen. Alle Änderungen werden mit dem Commit-Befehlt gespeichert. Der Clou – wie bei einem Backup kannst Du jederzeit zu diesem Stand zurückkehren. Smart, oder?
Stage
Eine Stage – auch als der Staging-Bereich bezeichnet – enthält die Dateien, die in die nächste Git-Übertragung aufgenommen werden sollen. Mit dem Staging definierst Du eine Datei also für die nächste Übertragung in das entferne Remote-Git-Repository.
Track
Wenn Du eine Git-Datei trackst, dann verfolgst Du deren Änderungen und wird über jede solche Änderung informiert. Eine getrackte Datei ist ein Git-Element, das vom Git-Repository als einzelnes Element erkannt wird.
Branch
Ein Branch ist eine parallele Version der Dateien in einem Repository.
Local
Wie schon eingangs erklärt, liegen deine Entwicklungsdateien immer zuerst lokal auf Deiner Maschine in der Version Deines Repositories, ist also auf Deinem persönlichen Computer gespeichert.
Remote
Der Remote ist die Version des Repositories, das auf einem entfernten Host – wie einem Server – gespeichert ist. Dieses Remote-Repo kann auf GitHub oder GitLab oder sonstwo untergebracht sein. Eine URL oder URI adressiert diese Remote-Adresse.
Clone
Ein Clone ist eine lokale Kopie eines entfernten Projektarchivs dass Du von Deinem Rechner erstellt hast.
Fork
Ein Fork (Gabel) ist eine (veränderte) Kopie eines Projektarchivs und kann von Dir oder einem anderen Benutzers erstellt werden. Es ist eine übliche Strategie ein GitHub-Projekt zu forken und sich damit eine 1:1 Kopie dieses Git-Projekts als Archiv zu kopieren. Ebenso kannst Du ein Git-Repo vom GitHub-Konto eines anderen Git-Hub-Benutzers zu Deinem eigenen
überführen oder auch zusammenführen.
Merge
Ein Merge ist eine Versionierungsstrategie um Versionsdateien zusammen zu führen. Mit dem Git-Merge aktualisierst Du ein Git-Projekt, indem Du die in neuen Commits eingeführten Änderungen per Merge einarbeitest.
Pull
Per Pull oder auch mit dem Pull-Request rufst Du veränderte Dateien per Commits aus einem entfernten Repository ab und überführst diese in dein lokales Repository. Die Release-Dateien werden also in der Richtung Deiner Entwicklungsumgebung zusammengeführt.
Push
Per Push oder Push-Request sendest Du per Commit aus Deinem lokalen Repository an ein entferntes Repository.
Pull Request
Der Pull-Request ist eine Anfrage als Nachricht, die von einem anderen GitHub-Benutzer gesendet wird, um die Übertragungen in seinem entfernten Repository in das entfernte Repository eines anderen Benutzers einzubinden. Per Pull-Requests werden also Erlaubnisse zur Einversionierung in ein Remote-Repository erteilt.
Eignet sich die Git-Versionierung nur für Code?
Git ist nicht allein auf Code beschränkt! Es gibt keinen Grund, warum dieser Rahmen nur auf Code beschränkt sein muss; ein VCS eignet sich gut für die Nachverfolgung beliebiger Klartextdateien:
- Manuskripte
- technische Spezifikationen
- Protokolle
Ist die Git-Versionierung immer öffentlich?
Ob eine Git-Versionierung öffentlich einsehbar also public ist oder privat und damit nicht öffentlich einsehbar ist, entscheidet der Besitzer eines Repositories.
Die Berechtigungssteuerung von Repositories ist vielfältig und bietet für jede erdenkliche Anforderung eine Lösung.
Oder um es klipp und klar anders zu formulieren:
Es gibt keinen, nein gar keinen guten Grund Software und Source-Code nicht per Git zu versionieren. Beim Programmieren ist Git unverzichtbar.
In diesem Sinne: Föhliches Git-Versionieren! ;-)
