OBS/Adminhilfe/Git Fork/Anleitung

Sourcen ziehen
SmartGit installieren
https://www.syntevo.com/smartgit/download/

Name: Nachname, Vorname
Mail: nachname.vorname@obs
View: Log
Repository - Clone:
http://192.168.254.162/root/obs.git
Path: C:\Bergau\OBS\Dev\tempsource

Anmeldedaten:
dev
Siehe Passwortverwaltung!
.git-Ordner und .gitignore-Datei aus C:\Bergau\OBS\Dev\tempsource in den dev-Ordner ziehen und den dev\tempsource-Ordner löschen (Achtung: Sind versteckte Dateien!)
In SmartGit: Wenn Meldung aufploppt: Remove Repository. Sonst Rechtsklick aufs tempsource-Repository - Delete
In SmartGit: Repository - Add or Create... - C:\Bergau\OBS\Dev öffnen
Alle Änderungen im Workingtree discarden (Dabei gehen mögliche Änderungen an Dateien, die vor der Installation von SmartGit gemacht wurden, verloren, also relevante Dateien einmal sichern, um die Änderungen nach dem Discard wieder einzumergen. Für neue Arbeitsplätze ist das egal, da kann ruhig alles discarded werden.)
Bei Workingtree-Warnung in Smartgit: dev\.git\config bearbeiten: 'tempsource' aus dem Workingtree-Eintrag entfernen

Bugfix

In SmartGit: Remote - Add:

http://192.168.254.162/root/bugfix.git  
xBugfix

Modified Shop

Clone:
http://192.168.254.162/root/modified2-obs-shop.git
C:\Bergau\OBS
shop

Anmeldedaten:
Siehe Passwortverwaltung!

App

Clone:
http://192.168.254.162/root/app.git
C:\Bergau\OBS
app

Anmeldedaten:
Siehe Passwortverwaltung!

Einstellungen

Preferences

Commands

Automatically save stash on common commands, if they fail due to local changes (Zusätzlich:'git config rebase.autoStash true' (Siehe Anleitung))

Low-level Properties

Edit - Preferences - Low-level Properties:

tooltip.compactLineLimit : 10 (setzt die Standardgröße von Tooltips, damit mehr angezeigt wird, ohne, dass man F1 drücken muss)
changes.maximumFileSize : 3000000 (damit auch große Dateien wie die OBSDB.sys bearbeitet werden können)
branches.delete.preselectDeleteFromRemote : true (Damit beim Löschen von Remote-branches der Bestätigungshaken vorbelegt ist)

Fenstereinstellungen

Branches-Fenster

Sort Refs by Commit Time: Damit Tags absteigend angezeigt werden.

Git-Shell öffnen

Für weitere Einstellungen.

Arbeitsabläufe

Unstable

Entwickler

Fetch, Unstable-Branch auschecken, 'Pull' zum Versionen ziehen; Wenn gefragt wird, was mit Änderungen passieren soll: 'Stash and Reapply'
Programmieren...
Gab es zwischenzeitlich neue Sourcen sollte zunächst "Save Stash" ausgeführt, Unstable ausgecheckt und anschließend "Apply Stash" ausgeführt werden.
neuen Branch (Rechtsklick - 'add branch') vom Unstable: '<kürzel>-<beschreibung>'; Darauf achten, dass der neue Branch ausgecheckt ist (aktiv, Haken davor)
Für diesen Branch relevante Änderungen commiten (In SmartGit: Working Tree (Changes) - Dateien auswählen - Commit - Bezeichnung eingeben); Branches auf ein Commit begrenzen. Wenn schon eines gemacht wurde: Local - Undo Last Commit
Branch pushen, zurück auf unstable wechseln (checkout), lokalen Branch löschen.
Bei mehreren, unabhängigen Änderungen: zurück zu Schritt 3.

Darauf achten, keine Abhängigkeiten der Commits untereinder zu haben!
Wenn Änderungen länger in Entwicklung sind: Rebase (Änderungsbranch auschecken (Haken davor), dann Rechtsklick auf den unstable-Branch -> Rebase ... to here), um die Änderungen auf den aktuellen Source-Stand zu bringen

Merger

Unstable auswählen
Bei allen grünen Merge-Zweigen von unten nach oben:
1. [Rechtsklick - Cherry-Pick] auf commits mit grünen 'merge'-Branches
2. grünen Branch löschen (auch remote!)
Versions-Tag setzen
Unstable pushen
Version erstellen (Auf Drucklib-Änderungen achten!)

Jörn

Wenn jemand anderes die Unstable gemacht hat: Unstable ziehen: Auschecken, Fetch, Pull.
Normales Programmieren: Mit Haken vor Unstable: Änderungen machen, stagen, committen.
Änderungen von Anderen einmergen:

Eigene Änderungen Stagen und Commiten
In der Commit-Liste: Commits, die mit merge/<name>-<beschreibung> markiert sind, anklicken.
Unten unter Changes die Änderungen einsehen und bewerten
Wenn Änderungen gut: Rechtsklick auf den Commit, der mit merge/<name>-<beschreibung> markiert ist -> Cherry-Pick Commit
Rechtsklick der mit merge/<name>-<beschreibung> markiert ist -> 'merge/<name>-<beschreibung>' -> Delete

Version erstellen: Alle Änderungen stagen und committen, pushen. Wenn die Version Live bei uns aufgespielt wird: Versionstag setzen.

Bugfix/Hotfix

Entwickler

Änderung siehe Unstable zum Mergen geben
Neuen Branch '<kürzel>-<Beschreibung>' von Version erstellen und auschecken
[Rechtsklick - Cherry-Pick] auf den Commit mit der Änderung

Merger

Neuen Branch auf das alte Versionstag erstellen und auschecken
Für alle Änderungen:
1. [Rechtsklick - Cherry-Pick] auf commits mit grünen 'bugfix'-Branches
2. Grüne Bugfix-Branches löschen
neues Versionstag setzen
Version erstellen...
Unstable-Branch auschecken
Bugfix-Branch löschen
Rechtsklick aufs Tag: Push to gitlab

Begriffe

Begriff	Erklärung	Entspricht
Repository	Verzeichnis, das mit git verwaltet wird. Im Verzeichnis liegt ein .git-Ordner, in dem die Änderungen und Einstellungen erfasst werden.
Remote	Server, auf dem ein Repository zentral verwaltet wird. Dieser kann pro Repository eingestellt werden. Es können auch mehrere Remotes für ein Repository eingerichtet werden. Auf dem Remote-Verzeichnis können verschiedene Benutzer mit unterschiedlichen Berechtigungen arbeiten.	PROGRAMM-UPDATE\OBS_SOURCE
Commit	Sourcenstand. Ein Commit besteht aus Informationen über den Autor, das Datum und Abhängigkeiten von anderen Commits. Im Commit werden die Änderungen seit dem letzten Commmit zeilengenau festgehalten.
Branch	Verweis auf ein Commit. Kann mit einem Remote-Branch verknüpft sein und durch Pull auf den Stand des Remote-Branches gebracht werden. Rote Branches sind nur lokal verfügbar, grüne Branches liegen auf dem Remote. Durch Doppelklick (Checkout) kann ein Branch aktiv gemacht werden. Dabei werden alle Dateien im Arbeitsverzeichnis durch den Stand ersetzt, der im Commit festgehalten wurde, auf das der Branch zeigt.
Checkout	Einen Branch oder Commit betreten, ändert die Dateien im Arbeitsverzeichnis auf den Stand des Commits, das ausgecheckt wird.
Tag	Verweis auf ein Commit. Kann ans Remote gepusht werden.	Version in der Updater-Liste
Fetch	Überträgt alle Änderungen vom Remote in das lokale Repository, OHNE das Veränderungen an den lokalen (roten) Branches oder dem Arbeitsverzeichnis durchgeführt werden.
Pull	Zieht die Commits aus dem Remote-Branch (grün) in den ausgecheckten lokalen (roten) Branch. Alle Commits, die übernommen werden, werden mit einem weißen Punkt davor gekennzeichnet. Die Dateien im Arbeitsverzeichnis werden auf den Stand des Commits gebracht, auf den der Remote-Branch zeigt.	Aktuelle Sourcen ziehen
Push	Überträgt den aktuell ausgecheckten Branch an Remote. Erstellt aus einem roten Branch einen grünen Branch, den alle sehen können, nach dem sie gefetcht haben.	Zum Mergen geben
Stage	Bestätigt Änderungen zeilengenau als erwünscht und markiert sie zum Übernehmen beim Committen.
Committen	Speichert alle gestageten Dateien als neuen Sourcestand in den ausgecheckten, lokalen (roten) Branch.
Amend	Macht den letzten Commit rückgängig und zieht alle Änderungen wieder in das Staging. Erlaubt es, einen Commit zu korrigieren oder zusätzliche Änderung vor dem Mergen hinzuzufügen.

Whitelist

Um Dateien zur Whitelist hinzuzufügen, muss die .gitignore-Datei bearbeitet werden, die in \dev liegt.

Mit # können darin Kommentare geschrieben werden werden.

* ist ein Platzhalter für beliebig viele Zeichen.

'obs/*' erlaubt alle Dateien im obs-Ordner.
'obs/*.pas' erlaubt alle .pas-Dateien im obs-Ordner.
'obs/userdb_*.sys' erlaubt alle .sys-Dateien im obs-Ordner, die mit 'userdb_' beginnen.

** ist ein Platzhalter für beliebig viele Unterverzeichnisse ('Rekursiv')

Änderungen sollten sofort nach dem Speichern als Änderugn im Working Tree sichtbar sein. Anschließend können die neuen Dateien und die .gitignore-Änderung comitted und zum Mergen gegeben werden.

Dateien, die einmal hinzugefügt wurden, müssen gelöscht werden, um ignoriert werden zu können.

Gitlab-Server

Wir verwalten unser git mit gitlab, liegt (Stand 12-2019) als Debian-VM auf dem VNode2-Host. Einwahl im RDM, Zugangsdaten sind in der Passwortverwaltung.

Dort ist gitlab-ee per apt installiert.

Zum Updaten:

sudo apt-get update
sudo apt list -a gitlab-ee
sudo apt-get install gitlab-ee=<aktuelle mittelversion>
sudo apt-get install gitalb-ee=<aktuelle major-version>

Danach braucht der Server etwa 10 Minuten, um wieder erreichbar zu sein. Vorher gibt es http-500-Fehler.

Die gitlab-Datenbank ist eine sqlite-Datenbank, da muss also kein Server gepatcht werden.

Die Technik erstellt regelmäßig Backups von den VMs.

OBS/Adminhilfe/Git Fork/Anleitung

Inhaltsverzeichnis

Installation

SmartGit und OBS

Bugfix

Modified Shop

App

Einstellungen

Preferences

Commands

Low-level Properties

Fenstereinstellungen

Branches-Fenster

Git-Shell öffnen

Arbeitsabläufe

Unstable

Entwickler

Merger

Jörn

Bugfix/Hotfix

Entwickler

Merger

Begriffe

Whitelist

Gitlab-Server

Navigationsmenü

OBS/Adminhilfe/Git Fork/Anleitung

Installation

SmartGit und OBS

Bugfix

Modified Shop

App

Einstellungen

Preferences

Commands

Low-level Properties

Fenstereinstellungen

Branches-Fenster

Git-Shell öffnen

Arbeitsabläufe

Unstable

Entwickler

Merger

Jörn

Bugfix/Hotfix

Entwickler

Merger

Begriffe

Whitelist

Gitlab-Server

Navigationsmenü

Suche