Git-basierte kollaborative Entwicklung von Webanwendungen (GitHub/GitLab)

Aus THM-Wiki
Wechseln zu: Navigation, Suche
Software
Name Git
Hersteller Junio C. Hamano, Shawn O. Pearce, Linus Torvalds und viele andere
Version 2.4.5 (25. Juni 2015)
Betriebssystem Linux und andere unixoide Systeme, Windows, OS X



Git (engl. Blödmann) ist ein verteiltes Versionsverwaltungssystem mit dem Schwerpunkt auf Geschwindigkeit, Datenintegrität und Unterstützung von verteilten, nicht-linearen Workflows. Linus Torvalds hat die Software 2005 ursprünglich für die Entwicklung des Linux Kernels konzipiert und implementiert. Inzwischen ist Git zum meist verwendeten verteilten Versionsverwaltungssystem der Softwareentwicklung geworden und eignet sich besonders gut zur kollaborativen Entwicklung von Anwendungen.

Ähnlich wie bei den meisten anderen Versionsverwaltungssystemen, und im Gegensatz zu den meisten Client-Server-Systemen, ist jedes Git-Arbeitsverzeichnis ein vollwertiges Repository. Somit besitzt jedes Arbeitsverzeichnis die gesamte Historie, freien Netzwerkzugriff oder einen zentralen Server.

Git ist Freeware und mit der GNU General Public License Version 2 lizenziert.

GitHub und GitLab sind webbasierte Hosting-Services für Git Repositories. Sie bieten alle Funktionalitäten von Git an, beispielsweise die Versionsverwaltung. Zusätzlich werden weitere, selbst entwickelte Features zur Verfügung gestellt: Diese machen den großen Unterschied zu Git selbst aus. Während Git ein reines Kommandozeilen-Tool ist, stellen GitHub und GitLab webbasierte, grafische Oberflächen zur Verfügung. Weitere, nennenswerte Features sind die Integrationslösungen für Desktop- und Mobilgeräte, Zugriffskontrollen, Wikis, Aufgabenverwaltungen, Fehlerverfolgungen und Feature-Anfragen. Dadurch lassen sich kollaborative Entwicklungen noch einfacher verwalten.

Historie

In der Entwicklungszeit des Linux Kernels (ein Open Source Software Projekt) von 1991 bis 2002 wurden die Änderungen in Form von Patches am bestehendem Code herumgereicht. 2002 wurde dann das Source-Control-Management (SCM) System namens BitKeeper eingeführt, welches ein Werkzeug zur Versionsverwaltung von Software-Quelltext ist. Durch eine Lizenzänderung des BitKeeper-Systems im Jahr 2005 war die Nutzung nicht mehr kostenlos und die zuvor ausgesprochene Erlaubnis, BitKeeper kostenlos zu verwenden, wurde widerrufen. Deswegen haben viele Linux-Kernel Entwickler dieses System gemieden.

Um das Linux-Kernel Projekt zu erhalten, begann Linus Torvalds am 3. April 2005 ein eigenes Tool namens Git zu entwickeln, welches dem BitKeeper-System angelehnt war. Das neue System sollte folgende Anforderungen erfüllen:

  • Geschwindigkeit
  • Einfaches Design
  • Gute Unterstützung von nicht-linearer Entwicklung (tausende paralleler Branches, d.h. verschiedener Verzweigungen der Versionen)
  • Unterstützung verteilter, BitKeeper-ähnlicher Arbeitsabläufe
  • Fähigkeit, große Projekte wie den Linux-Kernel effektiv zu verwalten (Geschwindigkeit und Datenumfang)
  • Sehr hohe Sicherheit gegen sowohl unbeabsichtigte als auch böswillige Verfälschung

Ein Projekt namens Monotone entsprach weitgehend den erforderten Kriterien, Torvalds entschied sich aber dagegen, Monotone an seine Anforderungen anzupassen und begann stattdessen ein eigenes System zu entwickeln. Einer der Hauptgründe für diese Entscheidung war die Arbeitsweise von Monotone, welche einzelne Revisionen von einem anderen Entwickler in den eigenen Entwicklungszweig importieren, was zu „unordentlichen“ Repositories führen würde. Die Entwickler wären gezwungen aufzuräumen, wenn ganze Zweige importiert werden würden. Dafür wären „Wegwerf-Zweige“ geeignet.

Git besteht aus einigen Ideen/Konzepten von Monotone und BitKeeper, wobei kein Quellcode davon verwendet wurde. Es wurde ein selbstprogrammiertes Versionsverwaltungssystem entwickelt.

Momentan betreut die Entwicklung von Git Junio Hamano.

Git Versionsverlauf
Version Veröffentlichung
1.0 Dezember 2005
1.5.0 Februar 2007
1.7.0 Februar 2010
1.8.0 Oktober 2012
2.0 März 2014
2.5.0 Juli 2015

Grundlagen

Git wurde durch die beiden Versionskontrollsysteme BitKeeper und Monotone inspiriert. Ursprünglich war die Software als ein Low-Level-Versionskontrollsystem konzipiert, für welches andere Entwickler Front-Ends entwickeln können. Beispielhafte Umsetzungen sind Cogito oder StGIT. Seitdem hat sich der Kern des Git Projektes zu einem kompletten Versionskontrollsystem entwickelt, welches ohne zusätzliche Software direkt verwendet werden kann.

Eigenschaften

Der Entwurf von Git wurde durch Torvalds' Erfahrungen mit Linux geprägt: Der Aufrechterhaltung eines großflächig verteilten Softwareprojektes. Zusammen mit seinen Kenntnissen über Dateisysteme, ebenfalls resultierend aus der Arbeit mit Linux sowie der dringenden Anforderung, in kürzester Zeit ein funktionierendes System zu entwickeln, ergaben sich folgende Implementierungsentscheidungen:

Unterstützung von nicht-linearer Entwicklung
Git ermöglicht schnelles Branchen (Verzweigen) und Mergen (Zusammenführen). Daher werden Tools zum Visualisieren und Navigieren von nicht-linearen Entwicklungshistorien bereitgestellt. Branches sind sehr leichtgewichtig, da sie lediglich auf einen (den vorherigen) Commit verweisen. Mit Hilfe von diesem kann die vollständige Branch-Struktur wiederhergestellt werden.
Verteilte Entwicklung
Genau wie bei anderen Versionsverwaltungssystemen erhält jeder Entwickler von Git eine lokale Kopie der gesamten Entwicklungshistorie. Änderungen werden von solch einem Repository in ein anderes kopiert. Diese Änderungen werden dann als zusätzliche Entwicklungs-Branches importiert und können auf die gleiche Art und Weise wie ein lokaler Entwicklungs-Branch zusammengefügt werden.
Kompatibilität zu existierenden Systemen und Protokollen
Repositories können über HTTP, FTP, rsync, ssh oder ein Git-Protokoll veröffentlicht werden. Auch bietet Git die Möglichkeit, Concurrent Versions System-Clients (SVN-Clients) und Plugins von Entwicklungsumgebungen (wie Eclipse) mit Hilfe einer CVS-Server-Emulation zu verwenden. Subversion- und SVK-Repositories werden durch git-svn unterstützt.
Effizientes Arbeiten in großen Projekten
Torvalds beschreibt Git als "sehr schnell und skalierbar"[1] - dies hat sich durch Performance-Tests von Mozilla im Vergleich mit anderen Versionsverwaltungssystemen bestätigt [2]. Verantwortlich dafür sind dafür die lokal gelegenen Repositories - sich von diesen Dateien zu holen ist deutlich schneller als von einem Server.
Austauschbare Merge-Strategien
Durch die Komponentenarchitektur von Git besitzt die Software mehrere, gute Algorithmen für die Zusammenführung von Code. Sollte das Zusammenführen (Mergen) nicht automatisiert übernommen werden können, werden die Stellen gekennzeichnet, an denen der Benutzer-Eingriff gefordert wird. Folgende Merge-Strategien stellt Git zur Verfügung:
  • resolve: Der traditionelle Drei-Wege Merge Algorithmus
  • recursive: Die Standard-Variante beim Pullen/Mergen eines Branches und eine Abwandlung des Drei-Wege Merges
  • octupus: Die Standard-Variante beim Mergen von mehr als zwei "Heads"

Kollaborative Workflows

Git Workflow - Aufbau und Befehle
Gitflow Workflow für kollaborative Entwicklung mithilfe von Git

Bei der kollaborativen Entwicklung von Software-Projekten mithilfe von Git haben sich eine Vielzahl möglicher Workflows entwickelt. Zusätzlich zum Git Workflow haben sie einige davon, wie beispielsweise der zentralisierte Workflow[3], der Branching Workflow[4], der Forking Workflow[5] oder der Gitflow Workflow[6] als übliche Workflows unter den Entwicklern verbreitet. Ein Überblick der grundlegenden Techniken aller Workflows soll die Auswahl des richtigen Workflows für das entsprechende Projekt vereinfachen:

Entferntes Repository anlegen
Git als verteiltes Versionsverwaltungssystem stellt ein Projekt an einer zentralen Quelle auf einem Server mittels einer Software wie GitLab oder GitHub zur Verfügung. Dort kann ein entsprechendes Projekt angelegt oder ein lokales, bereits bestehendes Projekt für die kollaborative Zusammenarbeit bereitgestellt werden.[7] Das Projekt auf dem Server wird Remote-Repository genannt. Dieses ist durch eine URL unter dem entsprechenden Protokoll erreichbar.

Hat ein Benutzer die entsprechenden Rechte oder ist das Projekt frei verfügbar, hat er die Wahl ein Projekt zu clonen oder das Repository zu forken.

Clonen
Beim Clonen[8] spiegelt ein Client das gesamte Repositoy inklusive der gesamten Historie lokal auf die Festplatte. Jeder Klon kann dabei als gesamtes Backup des Repositories betrachtet werden. Ein Client kann so lokal das Projekt weiterentwickeln, indem er neue Features oder Verbesserungen implementiert. Wenn die lokalen Änderungen getestet sind, können diese für die Produktion freigegeben werden.
Forken
Ein Grundprinzip der kollaborativen Versionskontrolle ist das Forken[9], das so viel wie Abspaltung bedeutet. Bei einem Fork wird zu einem bestimmten Zeitpunk eine Gabelung eines bestehenden Projektes erzeugt, welches dann parallel zum Original-Projekt weiterentwickelt wird. Anstatt nur ein remote-repository anzubieten, kann beispielsweise jeder Entwickler oder jedes Team ein weiteres remote-repository besitzen. Neue Features und Änderungen lassen sich zwischen dem Original-Projekt und dem Fork weiterhin austauschen. Dafür werden sogenannte Pull-Requests[10] zwischen den entsprechenden remote-repositories gestellt.
Branching
Mittels Branches[11] lassen sich Abzweigungen von der Hauptlinie der Entwicklung erstellen. Die Abzweigungen dienen als Zwischenstufen für die Produktionspipeline. So gibt es in einer stabilen Entwicklungsumgebung zu der Master-Branch noch eine Develop-Branch und für jedes neue Feature eine Topic-Branch. Ist ein neues Feature angedacht, wird dieses in der Topic-Branch entwickelt. Lokale Branches beim Client haben meist ein Pendant auf dem Server, mit denen sie in einer direkten Beziehung stehen, die sogenannte Remote-Branch.
Dateien lokal der Versionskontrolle hinzufügen
Um neu erstelle Dateien oder Änderungen an bestehenden Dateien lokal zu versionieren, muss man diese, gemäß dem Git Workflow, zuerst der Versionskontrolle von Git per $git add hinzufügen. Sind mehrere Dateien betroffen, kann man diese manuell oder alle Dateien automatisch auf einmal hinzufügen. Sind alle Änderungen an den Dateien erfolgreich durchgeführt, müssen diese per $git commit -m "nachricht"' zusammen mit einer Nachricht für die Historie bestätigt werden. Bestätigte Änderungen können auch wieder per $git rm entfernt werden.
Mehrere commits zusammenfassen
Innerhalb einer Topic- oder HotFix-Branch werden von einem oder mehreren Entwicklern möglichst viele Commits erzeugt. Diese sind jedoch für die Historie der Developer- oder Master-Branches in der Produktion zu kleingranular oder nicht interessant. So lassen sich mehrere commits mit einer gemeinsamen Nachricht mittels $git rebase zusammenfassen [12]. So sollte ein erstelltes Feature in der entsprechenden Topic-Branch am Ende vor dem Mergen zusammgenfasst werden.
Änderungen veröffentlichen oder lokal erhalten
Regelmäßig und vor jedem Hochladen sollten die Änderungen von anderen Entwicklern zuerst mittels $git pull vom Remote-Repository auf das lokale Repository übertragen werden. So können Konflikte vermieden oder vorab bereinigt werden. Um lokale Änderungen für andere in einem Remote-Repository bereitzustellen, müssen diese nach erfolgreichem commit mittels $git push auf den Server hochgeladen werden.
Branches zusammenführen
Ist das neue Feature lauffähig entwickelt und getestet, wird der entsprechende Topic-Branch mit dem Developer-Branch zusammengeführt (gemergt). Läuft auch dieser stabil und hat alle weiteren Tests bestanden, findet eine Zusammenführung in der Produktion mit dem Master-Branch statt. Beim Zusammenführen von Branches kann es zu Konflikten kommen. Der häufigste Grund hierfür ist, dass mehrere Entwickler an derselben Datei gearbeitet haben. Die entsprechenden Dateien werden von Git markiert und müssen manuell bereinigt und nochmals zur Versionskontrolle hinzufügt werden.

Git-Client Implementierungen

Git wurde ursprünglich für Linux entwickelt, wobei es mittlerweile die gängingsten Betriebssysteme wie Microsoft Windows, OS X , BSD und Solaris unterstützt.[13]. Der Git-Client kann über die Kommandozeile oder verschiedene Anwendungen mit einer grafischen Benutzeroberfläche benutzt werden.

Verschiedene Umsetzungen des Git-Clients sind:

  • JGit - Umsetzung Git ist eine reine Java Software-Bibliothek. Entworfen, um in jeder Java-Anwendung eingebettet werden zu können. JGit in der Gerrit Code-Review-Tool und in EGit, einem Git-Client für die Eclipse-IDE verwendet.
  • Gitlet - JavaScript-Umsetzung von Git.[14]
  • Dulwich - Python-Implementierung der Git-Dateiformate und Protokolle [15]
  • libgit2 - reine C-Implementierung der Git Kernmethoden zu einer Bibliothek mit einer soliden API, die es ermöglicht individuelle Git-Anwendungen in jeder Sprache mit C-Bindungen in nativer Geschwindigkeit zu schreiben
  • GitHub für Mac - GitHub Client mit voller Funktionalität des Git-Clients und zusätzlichen GitHub Features für Mac OSX
  • GitHub für Windows - GitHub Client mit voller Funktionalität des Git-Clients und zusätzlichen GitHub Features für Windows
  • Gitbox - Git-Client mit grafischer Benutzeroberfläche für Mac OSX
  • Sourcetree - Git- und Mercurial-Client für Windows und Mac OSX
  • SmartGit Git-Client mit Unterstützung für GitHub, SVN und Mercurial für Mac OS X, Windows und Linux

Git Server

Der mit Git verwaltete Quellcode befindet sich standardmäßig in einem lokalen Repository. Voraussetzung für ein zentrales und zuverlässig erreichbares Repository ist der so genannte Git Server, der Daten mit mehreren Entwicklern austauscht. Beispielhafte Webplattformen dieser Server sind github.com oder gitlab.com. Ein Git Server bietet zusätzlich zum Repository-Hosting und einer grafischen Oberfläche zur Verwaltung der Repositories noch weitere Features an. Beispielsweise ein Wiki, eine Zugriffskontrolle oder eine Integrationslösung für Desktop- und Mobilgeräte.

GitHub

GitHub ist ein webbasierter Hosting-Dienst für Software-Entwicklungsprojekte. Der Dienst ist im Februar 2008 gestartet. Die Versionsverwaltungssoftware präsentiert sich als eine webbasierte, grafische Schnittstelle, die einen einfachen Zugriff auf alle wichtigen Funktionen der Plattform erlauben soll. Neben der Versionsverwaltung und dem Repository-Hosting bietet der Dienst alle grundlegenden Techniken zur kollaborativen Entwicklung sowohl kostenlos, wie auch kostenpflichtig an. Mit kostenfreien Accounts können in GitHub öffentliche Repositories erstellt werden, die von jedermann eingesehen, geklont oder geforkt werden können. Mit einem kostenpflichtige Account können private Repositories für proprietäre Software erstellt werden. Mit GitHub Enterprise bietet GitHub größeren Unternehmen die Möglichkeit, eine eigene Installation des Host-Dienstes für die unternehmensinternen Softwareentwicklung innerhalb der eigenen Infrastruktur bereitzustellen.

Auf GitHub stellen auch bekannte Technologieunternehmen wie Google, Facebook, Twitter oder Apple ihre Open-Source-Projekte bereit.

GitLab

GitLab ist ein webbasierter Hosting-Dienst für Projekte der Softwareentwicklung. Es wurde von dem Ukrainer Dmitri Saparoschez mithilfe von Ruby on Rails entwickelt und verfügt über eine solide Benutzer- und Rechteverwaltung. So können Benutzer unter anderem auch mit einem bestehenden Lightweight Directory Access Protocol (LDAP) synchronisiert werden.

Der Quellcode von GitLab ist im Gegensatz zu GitHub Open Source. GitLab bietet ähnliche Angebot wie GitHub an. Zusätzlich wird die GitLab Community Edition als eine kostenlose Installation des Dienstes für die unternehmensinternen Softwareentwicklung angeboten.

Funktionalitäten wie ein Issue-Tracking-System, ein Wiki und Code-Review-Möglichkeiten sind neben dem Source Source Code Management integriert.

Vergleich zwischen GitHub und GitLab

Features GitHub GitLab
Code Review Ja Ja
Bug Tracking Ja Ja
Wiki Ja Ja
Translation system Nein Nein
Shell server Nein Nein
Mailingliste Nein Nein
Persönlich Branch Ja Ja
Privat Branch Ja Ja
LDAP Benutzerauthentifizierung Nein Ja
geschütztes Branchen (nur Masters können Push durchführen) Ja Ja
Build system 3rd-party (e.g. Travis CI and Appveyor) Ja
Release Binaries Ja Nein
Self-hosting Ja Ja (Commercially GitHub Enterprise)

Verwendung

Die Eclipse Foundation berichtet in ihrer jährlichen Community-Umfrage, dass ab Mai 2014 Git das am weitesten verbreitete Quellcode-Management-Tool ist. 42,9 % der professionellen Software-Entwickler berichten, dass sie Git oder GitHub als ihr primäres Quellcode-Verwaltungssystem verwenden[16] - gegenüber 36,3 % im Jahr 2013 und 32 % im Jahr 2012. Das Open-Source-Verzeichnis Black Duck Open Hub zeigt auf, dass 38 % Git verwenden.[17]

Auch auf Google Trends wird Git (Mai 2015) im Vergleich zu SVN und CVS 90 mal mehr aufgerufen[18]

Git-Google-Trends.png

Eine Auflistung von Open-Source-Projekten, die Git für die Quellcodeverwaltung verwenden.[19]

Literatur

  • Scott Chacon, Ben Straub: Pro Git – Everything you need to know about Git. APress, Second Edition, November 2014, ISBN 978-1-484200-77-3.
  • Valentin Haenel, Julius Plenz: Git – Verteilte Versionsverwaltung für Code und Dokumente. Open Source Press, München 2011, ISBN 3-941841-42-4

Einzelnachweise

Weblinks

  • Git Homepage – Offizielle Webpräsenz von Git.
  • Git - Wikipedia Artikel über Git (engl.)
  • GitHub - Wikipedia Artikel über GitHub (engl.)
  • GitLab - Wikipedia Artikel über GitLab (engl.)