Um eine gute Zusammenarbeit zu gewährleisten müssen Änderungen nachvollziehbar sein und alle Beteiligten am aktuellen Stand arbeiten können. Und genau dafür gibt es GIT. Wir setzen GIT ein um mit Hochschulen gemeinsam in unseren Projekten voran zu kommen und die Übersicht zu behalten.
Um an unseren und hochschulinternen Projekten teilzunehmen muss man sich lediglich in unserem GIT registrieren.
Dazu sind folgende Schritte notwendig:
Danach ist man sofort angemeldet.
Bitte teilen Sie uns nach der Registrierung Ihre Kennung mit und wir richten für Sie dann die Organisation und das Repository ein.
Das Repository kann man im Browser, lokal auf dem PC oder auch direkt auf dem Server verwenden.
Um Daten zu bearbeiten oder erst mal einen bestimmten Stand in das Git zu bekommen kann der Browser oder auch Eclipse oder ähnliches verwendet werden. Die Ordnerstruktur sollte der auf dem Server ähneln, um später diese auch direkt auf dem Server Synchronisieren zu können.
Um die Daten im Browser zu bearbeiten, geht man zunächst in das gewünschte Repository. Dazu klickt man in der Übersicht unter Repositories auf das gewünschte. Hier im Beispiel steht nur eins zur Verfügung.
Man landet im root Verzeichnis des Repositories. Mit Klick auf eine Datei kann diese nun bearbeitet werden oder mit klick auf einen Ordner, gelangt man in diesen. Wenn es mehrere Unterordner gibt und dazwischen keine weiteren Verzweigungen oder Dateien, werden diese gebündelt dargestellt. D.h. bei klick auf diesen Link gelangt man direkt zu dem Punkt an dem es Dateien oder weitere Verzweigungen gibt.
Möchte man eine neue Datei irgendwo dazwischen anlegen klickt man zuerst auf den gebündelten Ordner und dann oben drüber in der Pfadangabe auf den Ordner wo man hin möchte.
Um eine Datei nun zu bearbeiten geht man in den entsprechenden Ordner und klickt diese an. Dadurch kann man diese erst mal betrachten.
Wenn man nun auf den Stift klickt, kann man diese auch bearbeiten.
Wenn die Arbeiten abgeschlossen sind, scrollt man nach unten. Dort gibt es 2 Textfelder unterhalb von "Anderungen committen". In dem ersten gibt man eine kurze Beschreibung ein, was geändert wurde und in dem unteren Textfeld eine lange Beschreibung.
Die kurze Beschreibung erscheint immer direkt neben den Dateien in der Übersicht. Hier am besten nur ganz wenige Stichworte verwenden.
Die lange Beschreibung kann man sich mit klick auf die Kurzbeschreibung anzeigen lassen und dazu auch direkt die Änderungen. Somit sieht man die Änderungen und hat auch direkt die lange Erklärung dazu.
Wenn Sie das Repository per Kommandozeile klonen, müssen Sie das Repository mit https://... klonen
git clone https://<@superx-rocks.de/git/< /< >.git
z.B.
git clone https://schmidt@superx-rocks.de/git/Koeln_Uni/Koeln__Uni_SuperX-Konfiguration.git
Nun müssen Sie bei jedem Push/Pull Ihren Benutzernamen und das Passwort eingeben. Um die Passworteingabe auszuschalten müssen Sie ein API-Token erzeugen. Dazu gehen Sie in der Weboberfläche nach Login über Ihr Personen-Icon rechts oben nach Einstellungen -> Anwendungen -> Neuen Token erzeugen. Sie geben den Token einen sprechenden Namen, und kreuzen an ob Sie beim Repository entweder nur lesen oder lesen und schreiben wollen:
Wenn Sie dann das Token generieren wird im Browser einmalig ein Hash angezeigt, diesen müssen sie direkt rauskopieren und in die URL des Repo kopieren. Wenn z.B. "75c95694c285077e557c2f72e594050576c51c96" angezeigt wird, und Ihre Kennung "schmidt" lautet, dann wäre die Klon-URL:
https://schmidt:75c95694c285077e557c2f72e594050576c51c96@superx-rocks.de/git/Koeln_Uni/Koeln__Uni_SuperX-Konfiguration.git
Wenn Sie geklont haben wird die URL in die Datei
.git/config geschrieben. Damit keine anderen User die Datei lesen können sollten Sie eingeben:
chmod og-rw .git/config
Damit hat nur die Eigentümer_in Lese- und Schreibzugriff.
Wir befinden uns in unserem Schaubild
in dem rot umrandeten Bereich, d.h. wir haben das Repository lokal geklont, und synchronisieren dies nun mit der Installation, d.h. dem Ziel-Tomcat-Server. Dazu liefern wir ein Script aus:
rsync_to_superx.x
rsync_to_h1.x
Die Scripte nutzen die folgenden Umgebungsvariablen:
LOCAL_DIR -> Quellverzeichnis REMOTE_HOST ->Ziel-Hostname REMOTE_USER ->Ziel-Benutzerkennung REMOTE_DIR -> Zielpfad
Die ersten beiden REMOTE-Variablen werden nur benötigt, wenn die Installation auf einem anderen physischen Rechner liegt. Der Zielpfad ist das Verzeichnis, bei SuperX Installationen /home/superx, bei HISinOne-BI .../webapps/superx
Manche Repositories liefern auch ANT-Scripte mit aus, mit denen SuperX-Module aus dem Quellcode erstellt werden können. Wenn dies der Fall ist, liegt im Wurzelverzeichnis eine Datei "build.xml".
Zunächst installieren Sie das BuildTool ANT. Wir empfehlen die Versionen 1.10 oder höher. Hier die Schritte für die Shell am Beispiel der Version 1.10.12:
wget https://dlcdn.apache.org//ant/binaries/apache-ant-1.10.12-bin.tar.gz tar -xzvf apache-ant-1.10.12-bin.tar.gz ANT_HOME=./apache-ant-1.10.12 export ANT_HOME PATH=$PATH:$ANT_HOME/bin export PATH
Danach können Sie die Build-Befehle auflisten mit
ant -p
Linus Torvalds, der "Vater" von Linux, nutzte anfangs eine kommerzielle Versionierungsssoftware. Als die Lizenz restriktiver wurde, suchte er nach Alternativen. Die damaligen "Platzhirsche" CVS und SVN gefielen ihm nicht, u.a. weil sie (zum Committen) eine permanente Verbindung zum Server voraussetzte. Daher entwickelte er kurzerhand eine neue Software, die alle Features bot, die er brauchte. Da er wegen "Linux" im Ruf stand, seine Softwareprodukte mit seinem eigenen Namen zu verbinden, taufte er seit Software "git" (zu deutsch "Trottel") - ein ironischer Seitenhieb.
Wir haben oben beschrieben wie Sie mit git im Browser arbeiten können. Es gibt aber mit der Kommandozeile noch wesentlich mächtigere Werkzeuge.
Vorsicht: Sie sollten das tool nur in der englischen Lokalisierung nutzen, bei der deutschen stiften Sie nur Verwirrung. Auch bei Konflikten arbeitet es nicht sehr gut.
Auch das Tool "gitk" wirkt zwar auf den ersten Blick recht "altbacken", aber es eignet sich sehr gut zum Durchsuchen einer Commit Historie bzw. zum Prüfen von Änderungen.
Sie finden die git-bezogenen Menüs mit der rechten Maustaste unter "Team".
Die Kommandozeile funktioniert, wenn man sich in einem Verzeichnis befindet, unterhalb dessen das Repository "geklont" wurde. Mit
git status
zeigt man den aktuellen Status an.
Das lokale Verzeichnis ist ein Klon des Remote Repository. Mit
git pull
bekommen Sie immer den aktuellen Stand. Dies sollten Sie regelmäßig machen, damit Ihre lokale Installation nicht zu sehr divergiert.
Bei git entwickelt man typischerweise in sog. "Branches", d.h. man zweigt vom ausgelieferten Code (der "Hauptbranch", früher hieß der "master", neuerdings nennt man es "Default-Branch") ab, entwickelt dort in Ruhe, und wenn alles funktioniert "merged" man seinen Branch in den Hauptbranch.
In welchem Branch man sich befindet, zeigt folgendes Kommando an:
git branch
Ergebnis z.B.:
* master
Dabei wird der Branch, in dem man sich befindet mit einem "*" gekennzeichnet. Einen neuen lokalen Branch erstellt man einfach mit
git checkout -b meine_coole_entwicklung git branch master * meine_coole_entwicklung
Wenn ein erstellter lokaler Branch nicht mehr benötigt wird, kann dieser mit
git branch -D meine_coole_entwicklung
gelöscht werden.
Der neue Branch ist zunächst nur lokal verfügbar. Dies kann man so beibehalten, falls man nur alleine in diesem arbeitet. Er lässt sich jedoch auch mit
git push --set-upstream origin meine_coole_entwicklung
auf ein entferntes Repository veröffentlichen um mit anderen zusammen zu arbeiten.
Wenn man fertig ist und einen stabilen Stand hat, kann man diesen in den "master" mergen:
git checkout master git pull git merge meine_coole_entwicklung git push
Alle verfügbaren romote-Branches kann man sich anzeigen mit
git branch -r
die entfernten Branches anzeigen lassen (-a würde lokale und entfernte anzeigen) und den entsprechenden Branch mit
git checkout -b jemandes_coole_entwicklung origin/jemandes_coole_entwicklung
lokal verfügbar machen.
Auch den Remote Branch können Sie löschen mit
git push origin :meine_coole_entwicklung
Manchmal will man in der Commit Historie zu einem speziellen Commit zurückkehren (z.B. um zu prüfen ob damals noch alles funktionierte). Dafür sind Branches nicht geeignet, weil man die im Nachhinein nicht anlegen kann. Sie können über die Commit Historie den Hash ausfindig machen und so ganz leicht zum damaligen Stand zurückkehren, z.B.:
git checkout 4735d97b8f44e6d809783019f6ce0fe515d621c2
Hier sollten Sie nicht committen oder branchen, es dient nur der Diagnose.
Bei git committen Sie in zwei (oder drei) Schritten:
1. Sie ändern den Code, und fügen dann die Änderung mit
git add Dateipfad
auf eine Art "Bühne", also Dateien, die für einen Commit vorgemerkt sind. Dies wiederholen Sie für beliebig viele Dateien, die Sie in einem Commit bündeln wollen, oder Sie geben direkt ein
git add -A -v
Damit werden alle geänderten Dateien auf die Bühne geschoben.
2. Sie committen mit einer sprechenden Nachricht:
git commit -m "Bugfix meiner coolen Entwicklung #Ticketnr"
3. Wenn Sie mit remote branches arbeiten publizieren Sie die Änderung mit
git push
Git speichert jeden einzelnen Commit mit einem sog. "Hash"-Wert, also einer SHA-1-Zufalls-Zeichenkette, die eindeutig ist und im Sinne einer digitalen Signatur auch nicht änderbar ist.
Die Hashes können Sie z.B. nutzen, um Zustände einer Datei
Eine Konvention bei git ist es, dass man die Hashes abkürzen kann, also statt des gesamten Hashes z.B.
4735d97b8f44e6d809783019f6ce0fe515d621c2
kann man auch nur die ersten 8 Stellen nehmen:
4735d97b
Mit dem Kommando
git log --pretty=format:"%h - %an, %ar : %s" Dateipfad
kann man sich die Historie von Dateien ansehen. Noch komfortabler geht das mit gitk
Den Hash kann man sich im Feld "SHA1-ID" mit STRG-C rauskopieren.
Wenn man z.B. einen Patch erstellen will, kann man die Dateien erstmal auflisten:
git log --name-only Dateipfad
Diese Dateiliste kann man in eine Textdatei kopieren, und mit folgenden Kommando sortieren und alle Duplikate entfernen, z.B. die Datei files.txt:
cat files.txt | sort -u >files_sorted.txt
Daraus kann man dann eine zip-Datei erzeugen, mit allen Dateien in files_sorted.txt:
zip mein_patch.zip -@ < files_sorted.txt
Wenn Sie in der Shell Differenzen einer Datei zwischen zwei Commits einsehen wollen, können Sie die SHA-Ids aus obigem git log Kommando direkt vergleichen, mit
git diff <also z.B.
git diff 3e9919e7c 231b35927 -- superx/WEB-INF/conf/edustore/db/module/sos/hilfstabellen/sos_stg_aggr_fuellen.sqlWenn Sie einen Commit nach dem Hash z.B. 3e9919e7c suchen, schreiben Sie
git show 3e9919e7cKonflikte
Wenn es Konflikte gibt, z.B. weil die gleiche Datei von verschiedenen Parteien geändert und "gepushed" wurde, können Sie ein sog. "mergetool" nutzen, um die Änderungen einzeln zu prüfen:
git mergetool --tool=meldResetten
Falls Sie Ihre Änderungen verwerfen möchten, können Sie wie folgt vorgehen:
Wenn einzelne Dateien/Verzeichnisse zurückgesetzt werden sollen, und noch nicht geadded/commited wurde:
git checkout -- DateipfadBei Angabe eines Verzeichnisses werden rekursiv alle Dateien in allen Unterverzeichnissen zurückgesetzt.
Wenn man z. B. alle Änderungen im aktuellen Verzeichnis und dessen Unterverzeichnissen verwerfen will, gibt man ein:
git checkout -- .(wichtig ist der Punkt am Ende)
Wenn Dateien schon committed wurden, kann man die remote-Datei erzwingen mit
git checkout --theirs -- DateipfadWenn Commits schon gepusht wurden, holt man sich aus der Commit Historie den Hash des Commits, um dann z.B. den Commit rückgängig zu machen:
git revert 4735d97b8f44e6d809783019f6ce0fe515d621c2 git pushGroße Binärdateien
Bei großen Binärdateien ist es nicht sinnvoll, die "normalen" git Befehle zu nutzen. Bei jeder Dateiänderung kann git nicht die Unterschiede finden, d.h. es gibt immer einen Mergekonflikt.
Um das zu umgehen kann man auch nur die Metadaten im git versionieren, die Dateien selbst werden gesondert gespeichert. Dazu muss man das Paket lfs (Large File Storage) installieren, z.B. unter Ubuntu:
apt-get install git-lfsDanach kann man in jedem git Repo die Funktion aktivieren (am Beispiel binäre Postgres-Dumps mit der Endung ".backup")::
git lfs install git lfs track "*.backup" git add .gitattributesDanach kann man ganz normal Dateien hinzufügen/committen.
Pakete erzeugen und installieren
Wenn das genutzte Repository ein "Modul-Repository" ist, können sie aus den Quellen einen Build erzeugen, und daraus entweder eine Distribution erzeugen (zip-Datei), oder direkt in einem Ziel-SuperX installieren. Zuncäst benötigen Sie dazu das Make-Tool Apache Ant:
Beispiel:
https://dlcdn.apache.org//ant/binaries/apache-ant-1.10.12-bin.tar.gz
Nach dem Entpacken setzen Sie ANT_HOME, sowie übernehmen die Binary von ANT in den PATH:
ANT_HOME=/home/superx/tools/apache-ant-1.10.12 export ANT_HOME PATH=$PATH:$ANT_HOME/bin export PATHDanach können Sie die Modulscripte generieren mit (Beispiel COStage):
. SQL_ENV cd git/COSTAGE/ ant -DMODULE_PATH=$COSTAGE_PFAD -DBASE_DIR=. -DWEBAPP=$WEBAPP -DMODULE=costage allSo erzeugen Sie dann ein SuperX-Paket (Beispiel COStage):
ant -DMODULE_PATH=$COSTAGE_PFAD -DWEBAPP_DIR=$WEBAPP -DMODULE=costage distDokumentation
Zur Dokumentation können Sie das interne Wiki und Ticket-System nutzen.
Ticket System
Tickets anlegen und bearbeiten
Im Ticket System können Sie ein Ticket anlegen, im Menü "Issue":
Hier können Sie ein Thema, eine Beschreibung, und Ziel-Meilensteine bzw. Fälligkeiten definieren. In der rechten Seitenleiste können Sie auch steuern, ob Sie bei Änderungen Emails "abonnieren" oder "abbestellen" wollen.
Es gibt in der Bearbeitung ein paar Unterschiede zu HISZILLA:
- Ticket Kommentare lassen sich bearbeiten / löschen
- Sie können nur bestimmte Dateitypen anhängen (Text). Binärdateien oder große Dateien bitte über git selbst hochladen.
- Zur Fomatierung wird Markdown genutzt
- Man kann in seinem Profil einen Avatar wählen oder anlegen
Kombination mit Commits
Jedes Ticket bekommt eine fortlaufende Nummer (hier im Beispiel die #1), auf die Sie in Commits referenzieren können. Wenn Sie z.B. einen Commit mit der Message
git commit -m "Mapping teaching units correction #1"anlegen, wird dieser später in der Browser Oberfläche automatisch mit den Ticket verlinkt:
Sie können auch auf Issues in andere Repositories verlinken, nach dem Schema
owner/repository#1234
