OBS/Adminhilfe/Git Fork/Anleitung: Unterschied zwischen den Versionen

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.
Keine Bearbeitungszusammenfassung
K (Encoding Einstellungen)
 
(27 dazwischenliegende Versionen von 6 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
{{ZugriffOBS}}
{{ZugriffOBS}}
==Installation==
==Installation==
===Fork und OBS===
===SmartGit und OBS===
# Sourcen ziehen
# Sourcen ziehen
# git installieren (Standardeinstellungen)<br>https://git-scm.com/downloads
# SmartGit installieren<br>https://www.syntevo.com/smartgit/download/<br><br>Name: Nachname, Vorname<br>Mail: nachname.vorname@obs<br>View: Log
# Fork installieren<br>https://fork.dev/windows<br><br>Name: Nachname, Vorname<br>Mail: nachname.vorname@obs<br>File - Preferences: Show commits: Topologically
# Repository - Clone:<br>http://192.168.254.162/root/obs.git<br>Path: C:\Bergau\OBS\Dev\tempsource<br><br>Anmeldedaten:<br>dev<br>Siehe Passwortverwaltung!
# Clone:<br>http://192.168.254.162/root/obs.git<br>C:\Bergau\OBS\Dev\<br>tempsource<br><br>Anmeldedaten:<br>root<br>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!)
# .git-Ordner aus C:\Bergau\OBS\Dev\tempsource in den dev-Ordner ziehen und den dev\tempsource-Ordner löschen
# In SmartGit: Wenn Meldung aufploppt: Remove Repository. Sonst Rechtsklick aufs tempsource-Repository - Delete
# In Fork: File - Open Repository - \dev öffnen
# 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
 
===Remote Halde===
In SmartGit: Remote - Add:
http://192.168.254.162/root/obs2.git 
Remote_Halde


===Modified Shop===
===Modified Shop===
# Clone:<br>http://192.168.254.162/root/modified2-obs-shop.git<br>C:\Bergau\OBS\Dev<br>shop<br><br>Anmeldedaten:<br>root<br>PW: Siehe Passwortverwaltung!
# Clone:<br>http://192.168.254.162/root/modified2-obs-shop.git<br>C:\Bergau\OBS<br>shop<br><br>Anmeldedaten:<br>Siehe Passwortverwaltung!
 
===App===
# Clone:<br>http://192.168.254.162/root/app.git<br>C:\Bergau\OBS<br>app<br><br>Anmeldedaten:<br>Siehe Passwortverwaltung!
 
==Einstellungen==
 
=== Repository → Settings ===
 
==== Encoding ====
Beim Encoding sollte ''windows-1252'' ausgewählt werden.
 
[[Datei:Git Settings Encoding.png]]
 
===Edit → Preferences===
====Commands====
Automatically save stash on common commands, if they fail due to local changes (Zusätzlich:'git config rebase.autoStash true' [[OBS/Adminhilfe/Git_Fork/Anleitung#Git-Shell_.C3.B6ffnen|(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)<br>
changes.maximumFileSize : 3000000 (damit auch große Dateien wie die OBSDB.sys bearbeitet werden können)<br>
branches.delete.preselectDeleteFromRemote : true (Damit beim Löschen von Remote-branches der Bestätigungshaken vorbelegt ist)<br>
 
===Fenstereinstellungen===
====Branches-Fenster====
Sort Refs by Commit Time: Damit Tags absteigend angezeigt werden.
 
==Git-Shell öffnen==
[[Datei:Git-open-shell.jpg]]
 
Für weitere Einstellungen.


==Arbeitsabläufe==
==Arbeitsabläufe==
Zeile 17: Zeile 61:
# Fetch, Unstable-Branch auschecken, 'Pull' zum Versionen ziehen; Wenn gefragt wird, was mit Änderungen passieren soll: 'Stash and Reapply'<br>
# Fetch, Unstable-Branch auschecken, 'Pull' zum Versionen ziehen; Wenn gefragt wird, was mit Änderungen passieren soll: 'Stash and Reapply'<br>
# Programmieren...<br>
# Programmieren...<br>
# neuen Branch (Rechtsklick - create new Branch) vom Unstable: '<kürzel>-<beschreibung>'; Darauf achten, dass der neue Branch ausgecheckt ist (aktiv, Haken davor); Wenn gefragt wird, was mit lokalen Änderungen passieren soll: 'Don't Change'<br>
# Gab es zwischenzeitlich neue Sourcen sollte zunächst "Save Stash" ausgeführt, Unstable ausgecheckt und anschließend "Apply Stash" ausgeführt werden.
# Für diesen Branch relevante Änderungen stagen und commiten (In Fork: Changes - Dateien durchgehen - Beschreibung eingeben - Commit); Branches auf ein Commit begrenzen, wenn schon eines gemacht wurde: amend-Haken setzen<br>
# neuen Branch (Rechtsklick - 'add branch') vom Unstable: '<kürzel>-<beschreibung>'; Darauf achten, dass der neue Branch ausgecheckt ist (aktiv, Haken davor)
# Branch pushen (grüner Branch entsteht), zurück auf unstable wechseln (checkout), lokalen (roten) Branch löschen.<br>
# 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<br>
# Branch pushen, zurück auf unstable wechseln (checkout), lokalen Branch löschen.<br>
# Bei mehreren, unabhängigen Änderungen: zurück zu Schritt 3.<br>
# Bei mehreren, unabhängigen Änderungen: zurück zu Schritt 3.<br>
* Darauf achten, keine Abhängigkeiten der Commits untereinder zu haben!<br>
* Darauf achten, keine Abhängigkeiten der Commits untereinder zu haben!<br>
Zeile 47: Zeile 92:
====Entwickler====
====Entwickler====
# Änderung siehe Unstable zum Mergen geben<br>
# Änderung siehe Unstable zum Mergen geben<br>
# Neuen Branch 'bugfix-<kürzel>-<Beschreibung>' von Version erstellen und auschecken<br>
# Neuen Branch '<kürzel>-<Beschreibung>' von Version erstellen und auschecken<br>
# [Rechtsklick - Cherry-Pick] auf den Commit mit der Änderung <br>
# [Rechtsklick - Cherry-Pick] auf den Commit mit der Änderung <br>
====Merger====
====Merger====
# Neuen Branch auf das alte Versionstag erstellen und auschecken<br>
# Neuen Branch auf das alte Versionstag erstellen und auschecken<br>
Zeile 120: Zeile 166:
Mit # können darin Kommentare geschrieben werden werden.
Mit # können darin Kommentare geschrieben werden werden.


'*' ist ein Platzhalter für beliebig viele Zeichen.  
<nowiki>*</nowiki> ist ein Platzhalter für beliebig viele Zeichen.  
* 'obs/*' erlaubt alle Dateien im obs-Ordner.  
* 'obs/*' erlaubt alle Dateien im obs-Ordner.  
* 'obs/*.pas' erlaubt alle .pas-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.
* 'obs/userdb_*.sys' erlaubt alle .sys-Dateien im obs-Ordner, die mit 'userdb_' beginnen.


'**' ist ein Platzhalter für beliebig viele Unterverzeichnisse ('Rekursiv')
<nowiki>**</nowiki> ist ein Platzhalter für beliebig viele Unterverzeichnisse ('Rekursiv')


Änderungen sollten sofort nach dem Speichern in Fork in den Changes sichtbar sein. Anschließend können die neuen Dateien und die .gitignore-Änderung comitted und zum Mergen gegeben werden.
Ä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.
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.

Aktuelle Version vom 29. Januar 2025, 08:09 Uhr

Dies ist eine zugriffsgeschützte Seite.


Admin-Hilfe

OBS-Administration / Installation
kundenspezifische Anpassungen
OBS Protokolle
Shop-Administration

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. Repository - Clone:
    http://192.168.254.162/root/obs.git
    Path: 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 (Achtung: Sind versteckte Dateien!)
  5. In SmartGit: Wenn Meldung aufploppt: Remove Repository. Sonst Rechtsklick aufs tempsource-Repository - Delete
  6. In SmartGit: Repository - Add or Create... - C:\Bergau\OBS\Dev öffnen
  7. 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.)
  8. 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

Remote Halde

In SmartGit: Remote - Add:

http://192.168.254.162/root/obs2.git  
Remote_Halde

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

Repository → Settings

Encoding

Beim Encoding sollte windows-1252 ausgewählt werden.

Git Settings Encoding.png

Edit → 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.