OBS/Adminhilfe/Git Fork/Anleitung

Aus OBS Wiki
Zur Navigation springen Zur Suche springen
Für diese Seite wurde eine Zugriffsbeschränkung eingerichtet. Falls du diese Nachricht siehst, bist du nicht berechtigt, diese Seite einzusehen.

Dies ist eine zugriffsgeschützte Seite.


Admin-Hilfe

FAQ
FIBU
Häufige Fehler FAQs
Allgemeines
Tools
Widgets
Wiki Hilfe
Syntax
Wiki-Gruppen Benutzerlisten
MySQL
MySQL Installation
Programmierung und Mergen
Delphi
Einrichtung
MMX
Git/SmartGit
Programm Update
Schaltflächen
F10: Weitere Funktionen
PAX
Nützliche Funktionen
SteVe
OBS-Administration / Installation
Einrichtung
MySQL
OBS
Dienste
Kasse/Notfallkasse
Replikation
Zentrale
Fleet-Management einrichten
VirtualUI
OBS Umzug
Admin Funktionen
Service Firmen
F10
O Support
D Programmierer-Tools
V Crypt Autologin Edit
J Update Marko Lib/Pmode/Script Lib
kundenspezifische Anpassungen
OBS Protokolle
OBS DEMO
Shop-Administration
modified eCommerce
modified eCommerce 2.x
modified eCommerce 1.06
Amazon
VShop 4.0
Kundeninformationen
OfficeStar
MDS

Installation

SmartGit und OBS

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

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

    Anmeldedaten:
    dev
    Siehe Passwortverwaltung!
  4. .git-Ordner und .gitignore-Datei aus C:\Bergau\OBS\Dev\tempsource in den dev-Ordner ziehen und den dev\tempsource-Ordner löschen
  5. In SmartGit: File - Open Repository - \dev öffnen

Bugfix

In SmartGit: Remote - Add: 

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

Modified Shop

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

    Anmeldedaten:
    Siehe Passwortverwaltung!

App

  1. 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

Git-open-shell.jpg

Für weitere Einstellungen.

Arbeitsabläufe

Unstable

Entwickler

  1. Fetch, Unstable-Branch auschecken, 'Pull' zum Versionen ziehen; Wenn gefragt wird, was mit Änderungen passieren soll: 'Stash and Reapply'
  2. Programmieren...
  3. Gab es zwischenzeitlich neue Sourcen sollte zunächst "Save Stash" ausgeführt, Unstable ausgecheckt und anschließend "Apply Stash" ausgeführt werden.
  4. neuen Branch (Rechtsklick - 'add branch') vom Unstable: '<kürzel>-<beschreibung>'; Darauf achten, dass der neue Branch ausgecheckt ist (aktiv, Haken davor)
  5. 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
  6. Branch pushen, zurück auf unstable wechseln (checkout), lokalen Branch löschen.
  7. 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

  1. Unstable auswählen
  2. 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!)
  3. Versions-Tag setzen
  4. Unstable pushen
  5. 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:
  1. Eigene Änderungen Stagen und Commiten
  2. In der Commit-Liste: Commits, die mit merge/<name>-<beschreibung> markiert sind, anklicken.
  3. Unten unter Changes die Änderungen einsehen und bewerten
  4. Wenn Änderungen gut: Rechtsklick auf den Commit, der mit merge/<name>-<beschreibung> markiert ist -> Cherry-Pick Commit
  5. 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

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

Merger

  1. Neuen Branch auf das alte Versionstag erstellen und auschecken
  2. Für alle Änderungen:
    1. [Rechtsklick - Cherry-Pick] auf commits mit grünen 'bugfix'-Branches
    2. Grüne Bugfix-Branches löschen
  3. neues Versionstag setzen
  4. Version erstellen...
  5. Unstable-Branch auschecken
  6. Bugfix-Branch löschen
  7. 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.

Abgerufen von „http:///index.php?title=OBS/Adminhilfe/Git_Fork/Anleitung&oldid=58174“