v0.9.0
This commit is contained in:
parent
101eb53ec9
commit
a3091b204c
GPG Key ID:
4CB9B8D93A96A538
@ -1,9 +1,16 @@
|
|||||||
# Changelog
|
# Changelog
|
||||||
|
|
||||||
|
- **20/07/25** - commit: v0.9.0
|
||||||
|
- **Hinzugefügt:**
|
||||||
|
- [X] Git Workflow
|
||||||
|
- [x] HAVOK Engine
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
- **18/07/25** - commit: v0.8.0
|
- **18/07/25** - commit: v0.8.0
|
||||||
- **Hinzugefügt:**
|
- **Hinzugefügt:**
|
||||||
- [X] Wahrheitstabelle.
|
- [X] Wahrheitstabelle.
|
||||||
-
|
|
||||||
- **17/07/25** - commit: v0.7.0
|
- **17/07/25** - commit: v0.7.0
|
||||||
- **Hinzugefügt:**
|
- **Hinzugefügt:**
|
||||||
- [X] Voltcraft Probe.
|
- [X] Voltcraft Probe.
|
||||||
|
|||||||
10
README.md
10
README.md
@ -18,6 +18,7 @@ Die Artikel sind auch zur Vorbereitung für neue Artikel auf <https://www.ioniva
|
|||||||
- [Editoren/ IDE´s](#editoren-ides)
|
- [Editoren/ IDE´s](#editoren-ides)
|
||||||
- [Helix](#helix)
|
- [Helix](#helix)
|
||||||
- [Gaming](#gaming)
|
- [Gaming](#gaming)
|
||||||
|
- [Engines und Frameworks](#engines-und-frameworks)
|
||||||
- [Git](#git)
|
- [Git](#git)
|
||||||
- [Grundlagen](#grundlagen)
|
- [Grundlagen](#grundlagen)
|
||||||
- [Linux](#linux)
|
- [Linux](#linux)
|
||||||
@ -67,13 +68,20 @@ Unter `./tools/` befinden sich Programme/ Skripte (aktuell in Typescript und Pyt
|
|||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
### Engines und Frameworks
|
||||||
|
|
||||||
|
- [Die Havok-Engine ⚙️](dokus/frameworks/havok-engine.md)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
### Git
|
### Git
|
||||||
|
|
||||||
- [Artikel: git](dokus/git/git.md)
|
- [Artikel: git](dokus/git/git.md)
|
||||||
- [SSH-Zugriff auf Git-Repository in WSL einrichten](dokus/git/git-ssh-remote.md)
|
- [SSH-Zugriff auf Git-Repository in WSL einrichten](dokus/git/git-ssh-remote.md)
|
||||||
- [Git – Remote-Branches: Häufige Aufgaben und Lösungen](dokus/git/git-remote-branch.md)
|
- [Git – Remote-Branches: Häufige Aufgaben und Lösungen](dokus/git/git-remote-branch.md)
|
||||||
- [Git-Submodule: Der umfassende Praxisleitfaden](dokus/git/git-submodule-leitfaden.md)
|
- [Git-Submodule: Der umfassende Praxisleitfaden](dokus/git/git-submodule-leitfaden.md)
|
||||||
- [Git-Cheat Sheet Commit Etscheidungshilfe](dokus/git/commit-etscheidungshilfe.md)
|
- [Git-Cheat Sheet Commit Erscheinungshilfe](dokus/git/commit-etscheidungshilfe.md)
|
||||||
|
- [Git Workflow](dokus/git/git_workflow.md)
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|||||||
108
dokus/frameworks/havok-engine.md
Normal file
108
dokus/frameworks/havok-engine.md
Normal file
@ -0,0 +1,108 @@
|
|||||||
|
# Die Havok-Engine ⚙️
|
||||||
|
|
||||||
|
## Inhalt
|
||||||
|
|
||||||
|
- [Die Havok-Engine ⚙️](#die-havok-engine-️)
|
||||||
|
- [Inhalt](#inhalt)
|
||||||
|
- [Was ist die Havok-Engine?](#was-ist-die-havok-engine)
|
||||||
|
- [Integration in andere Engines](#integration-in-andere-engines)
|
||||||
|
- ["Hello, World!" in der Havok-Engine](#hello-world-in-der-havok-engine)
|
||||||
|
- [Beispielcode](#beispielcode)
|
||||||
|
- [Erläuterung des Codes](#erläuterung-des-codes)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Was ist die Havok-Engine?
|
||||||
|
|
||||||
|
Die **Havok-Engine** ist eine leistungsstarke und weit verbreitete **Physik-Middleware**, die in zahlreichen Videospielen zur Simulation realistischer physikalischer Interaktionen eingesetzt wird.
|
||||||
|
Entwickelt von der irischen Firma Havok, die zu Microsoft gehört, ist sie keine allumfassende Game-Engine wie Unity oder Unreal, sondern spezialisiert sich auf die realistische Darstellung von Physik, Animationen und Kollisionen.
|
||||||
|
|
||||||
|
Im Kern ist Havok eine Sammlung von Software-Werkzeugen (SDK), die Entwickler in ihre eigenen Game-Engines oder Projekte integrieren können.
|
||||||
|
Anstatt eine komplette Entwicklungsumgebung bereitzustellen, konzentriert sich Havok auf die folgenden Kernbereiche:
|
||||||
|
|
||||||
|
- **Havok Physics:** Das bekannteste Produkt. Es ermöglicht die Simulation von Starrkörperdynamik, Kollisionserkennung und -reaktion in Echtzeit.
|
||||||
|
Wenn in einem Spiel Kisten realistisch umfallen, Gebäude einstürzen oder Ragdoll-Effekte bei Charakteren auftreten, steckt oft Havok Physics dahinter.
|
||||||
|
- **Havok Animation Studio:** Ein Werkzeugset für fortschrittliche Charakteranimationen, das flüssige und prozedurale Bewegungen ermöglicht.
|
||||||
|
- **Havok Cloth:** Wird für die realistische Simulation von Stoffen und Kleidung verwendet, wie z.B. wehende Umhänge oder Fahnen im Wind.
|
||||||
|
- **Havok Destruction:** Dieses Modul wird verwendet, um dynamisch zerstörbare Umgebungen zu erstellen.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Integration in andere Engines
|
||||||
|
|
||||||
|
Havok wird von vielen großen Spielestudios lizenziert und in deren eigene Engines integriert.
|
||||||
|
Bekannte Spiele, die Havok nutzen, sind unter anderem *The Elder Scrolls V: Skyrim*, *Halo*, *Dark Souls* und *Assassin's Creed*.
|
||||||
|
|
||||||
|
Es kann als eigenständiges SDK in eine C++-basierte Engine integriert werden.
|
||||||
|
Zudem existiert das **"Havok Physics for Unity"**-Paket, um die Physik-Engine direkt in Unity-Projekten zu nutzen.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## "Hello, World!" in der Havok-Engine
|
||||||
|
|
||||||
|
Ein klassisches "Hello, World!" ist für eine Physik-Engine nicht repräsentativ. Ein passenderes Äquivalent ist die Erstellung einer minimalen physikalischen Simulation: **eine Kiste, die unter dem Einfluss der Schwerkraft auf eine unbewegliche Ebene fällt.**
|
||||||
|
|
||||||
|
Das folgende konzeptionelle Code-Beispiel in C++-ähnlichem Pseudocode verdeutlicht die grundlegenden Schritte.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Beispielcode
|
||||||
|
|
||||||
|
```cpp
|
||||||
|
// 1. Initialisierung der Havok-Engine
|
||||||
|
Havok::initializeMemory();
|
||||||
|
Havok::initializeBaseSystems();
|
||||||
|
|
||||||
|
// 2. Erstellen einer Physik-Welt mit Schwerkraft
|
||||||
|
hkpWorld::Cinfo worldInfo;
|
||||||
|
worldInfo.m_gravity = hkVector4(0.0f, -9.8f, 0.0f);
|
||||||
|
hkpWorld* physicsWorld = new hkpWorld(worldInfo);
|
||||||
|
|
||||||
|
// 3. Erstellen eines statischen Bodens (unbewegliche Ebene)
|
||||||
|
hkpBoxShape* groundShape = new hkpBoxShape(hkVector4(50.0f, 1.0f, 50.0f));
|
||||||
|
hkpRigidBody::Cinfo groundInfo;
|
||||||
|
groundInfo.m_shape = groundShape;
|
||||||
|
groundInfo.m_motionType = hkpMotion::MOTION_FIXED; // Unbeweglich
|
||||||
|
groundInfo.m_position.set(0.0f, 0.0f, 0.0f);
|
||||||
|
hkpRigidBody* ground = new hkpRigidBody(groundInfo);
|
||||||
|
physicsWorld->addEntity(ground);
|
||||||
|
|
||||||
|
// 4. Erstellen einer dynamischen Kiste (bewegliches Objekt)
|
||||||
|
hkpBoxShape* boxShape = new hkpBoxShape(hkVector4(0.5f, 0.5f, 0.5f));
|
||||||
|
hkpRigidBody::Cinfo boxInfo;
|
||||||
|
boxInfo.m_shape = boxShape;
|
||||||
|
boxInfo.m_mass = 10.0f; // Masse von 10 kg
|
||||||
|
boxInfo.m_motionType = hkpMotion::MOTION_DYNAMIC; // Wird von Physik beeinflusst
|
||||||
|
boxInfo.m_position.set(0.0f, 10.0f, 0.0f); // Startposition über dem Boden
|
||||||
|
hkpInertiaTensorComputer::setShapeVolumeMassProperties(boxShape, boxInfo.m_mass, boxInfo);
|
||||||
|
hkpRigidBody* box = new hkpRigidBody(boxInfo);
|
||||||
|
physicsWorld->addEntity(box);
|
||||||
|
|
||||||
|
// 5. Die Simulations-Schleife (in der Praxis pro Frame)
|
||||||
|
for (int i = 0; i < 300; ++i) {
|
||||||
|
// Physik-Welt um einen Zeitschritt (1/60s) fortschreiten lassen
|
||||||
|
physicsWorld->stepDeltaTime(1.0f / 60.0f);
|
||||||
|
|
||||||
|
// Position der Kiste abfragen und ausgeben/darstellen
|
||||||
|
hkVector4 currentPosition = box->getPosition();
|
||||||
|
printf("Position nach Schritt %d: (%.2f, %.2f, %.2f)\n", i, currentPosition(0), currentPosition(1), currentPosition(2));
|
||||||
|
}
|
||||||
|
|
||||||
|
// 6. Aufräumen
|
||||||
|
box->removeReference();
|
||||||
|
ground->removeReference();
|
||||||
|
physicsWorld->removeReference();
|
||||||
|
Havok::quitBaseSystems();
|
||||||
|
Havok::quitMemory();
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Erläuterung des Codes
|
||||||
|
|
||||||
|
1. **Initialisierung:** Starten der internen Speichermanager und Basissysteme von Havok.
|
||||||
|
2. **Physik-Welt:** Das `hkpWorld`-Objekt ist das Herzstück der Simulation. Es verwaltet alle Objekte und wendet Kräfte wie die Schwerkraft an.
|
||||||
|
3. **Statischer Boden:** Ein unbeweglicher Körper (`MOTION_FIXED`), der als Kollisionsobjekt dient, damit die Kiste nicht ins Unendliche fällt.
|
||||||
|
4. **Dynamische Kiste:** Das "Hello, World!"-Objekt. Es hat eine Masse, ist als `MOTION_DYNAMIC` definiert und wird somit von der Schwerkraft beeinflusst und reagiert auf Kollisionen.
|
||||||
|
5. **Simulations-Schleife:** Der Aufruf von `physicsWorld->stepDeltaTime()` lässt die Zeit in der Simulation vergehen und aktualisiert die Positionen der dynamischen Objekte.
|
||||||
|
6. **Aufräumen:** Der belegte Speicher wird nach der Simulation wieder freigegeben.
|
||||||
@ -2,6 +2,7 @@
|
|||||||
|
|
||||||
|
|
||||||
|
|
||||||
- [SSH-Zugriff auf Git-Repository in WSL einrichten](git/git-ssh-remote.md)
|
- [SSH-Zugriff auf Git-Repository in WSL einrichten](git-ssh-remote.md)
|
||||||
- [Git – Remote-Branches: Häufige Aufgaben und Lösungen](git/git-remote-branch.md)
|
- [Git – Remote-Branches: Häufige Aufgaben und Lösungen](git-remote-branch.md)
|
||||||
- [Git-Submodule: Der umfassende Praxisleitfaden](git/git-submodule-leitfaden.md)
|
- [Git – Submodule: Der umfassende Praxisleitfaden](git-submodule-leitfaden.md)
|
||||||
|
- [Git – Workflow](git_workflow.md)
|
||||||
|
|||||||
244
dokus/git/git_workflow.md
Normal file
244
dokus/git/git_workflow.md
Normal file
@ -0,0 +1,244 @@
|
|||||||
|
# Git Workflow
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## 📝 Inhalt
|
||||||
|
|
||||||
|
- [Git Workflow](#git-workflow)
|
||||||
|
- [📝 Inhalt](#-inhalt)
|
||||||
|
- [📦 Workflow](#-workflow)
|
||||||
|
- [✏️ Neues Feature starten](#️-neues-feature-starten)
|
||||||
|
- [💾 Arbeiten und Zwischenspeichern](#-arbeiten-und-zwischenspeichern)
|
||||||
|
- [🔄 Zwischenstand von main holen (wenn andere auch pushen)](#-zwischenstand-von-main-holen-wenn-andere-auch-pushen)
|
||||||
|
- [✅ Feature fertig? Merge in main](#-feature-fertig-merge-in-main)
|
||||||
|
- [❌ Oops! Auf main gearbeitet?](#-oops-auf-main-gearbeitet)
|
||||||
|
- [✅ Git-Regeln für sauberes Arbeiten](#-git-regeln-für-sauberes-arbeiten)
|
||||||
|
- [💡 Git Merksätze](#-git-merksätze)
|
||||||
|
- [ℹ️ Mini-Cheatsheet](#ℹ️-mini-cheatsheet)
|
||||||
|
- [📦 GIT\_BRANCH\_CLEANUP.md](#-git_branch_cleanupmd)
|
||||||
|
- [🧹 Wann lösche ich einen Feature-Branch?](#-wann-lösche-ich-einen-feature-branch)
|
||||||
|
- [✅ Nach dem Merge in `main`](#-nach-dem-merge-in-main)
|
||||||
|
- [❗ Nicht löschen, wenn …](#-nicht-löschen-wenn-)
|
||||||
|
- [🔁 Nachträglich löschen (wenn vergessen)](#-nachträglich-löschen-wenn-vergessen)
|
||||||
|
- [📦 Merksatz](#-merksatz)
|
||||||
|
- [📦 Branch-Namenskonventionen](#-branch-namenskonventionen)
|
||||||
|
- [🔧 Aufbau](#-aufbau)
|
||||||
|
- [📚 Übersicht der Präfixe](#-übersicht-der-präfixe)
|
||||||
|
- [🧼 Empfehlung für Schönheitskorrekturen](#-empfehlung-für-schönheitskorrekturen)
|
||||||
|
- [📝 Hinweis](#-hinweis)
|
||||||
|
|
||||||
|
## 📦 Workflow
|
||||||
|
|
||||||
|
Tägliche Arbeit mit Git
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### ✏️ Neues Feature starten
|
||||||
|
|
||||||
|
```bash
|
||||||
|
git checkout main
|
||||||
|
git pull
|
||||||
|
git checkout -b feature/mein-feature
|
||||||
|
```
|
||||||
|
|
||||||
|
> ➔ Jetzt bist du auf einem neuen Branch. Alles was du änderst, bleibt NUR hier.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 💾 Arbeiten und Zwischenspeichern
|
||||||
|
|
||||||
|
```bash
|
||||||
|
git add .
|
||||||
|
git commit -m "WIP: Kurze Beschreibung meiner Arbeit"
|
||||||
|
```
|
||||||
|
|
||||||
|
- `WIP` = Work in Progress
|
||||||
|
- Lieber öfter kleine Commits als einen Monster-Commit.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 🔄 Zwischenstand von main holen (wenn andere auch pushen)
|
||||||
|
|
||||||
|
```bash
|
||||||
|
git pull origin main
|
||||||
|
```
|
||||||
|
|
||||||
|
- **Wichtig:** Nur im Feature-Branch bleiben!
|
||||||
|
- `git pull` sorgt dafür, dass du aktuellen Code hast.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### ✅ Feature fertig? Merge in main
|
||||||
|
|
||||||
|
```bash
|
||||||
|
git checkout main
|
||||||
|
git pull
|
||||||
|
git merge feature/mein-feature
|
||||||
|
git push
|
||||||
|
```
|
||||||
|
|
||||||
|
- Danach kannst du den Branch löschen:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
git branch -d feature/mein-feature
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### ❌ Oops! Auf main gearbeitet?
|
||||||
|
|
||||||
|
Noch **kein Commit** gemacht?
|
||||||
|
|
||||||
|
```bash
|
||||||
|
git checkout -b feature/schnell-gerettet
|
||||||
|
```
|
||||||
|
|
||||||
|
> ➔ Änderungen wandern automatisch mit. `main` bleibt sauber.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### ✅ Git-Regeln für sauberes Arbeiten
|
||||||
|
|
||||||
|
- Niemals direkt auf `main` coden.
|
||||||
|
- Immer neuen Branch für neue Aufgaben.
|
||||||
|
- Vor dem `git pull` **immer committen** oder **stashen**.
|
||||||
|
- Viele kleine Commits sind besser als ein riesiger.
|
||||||
|
- Beim Merge zuerst `git pull`, dann `merge`.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 💡 Git Merksätze
|
||||||
|
|
||||||
|
| **Situation** | **Lösung** |
|
||||||
|
|:---|:---|
|
||||||
|
| Änderungen da, noch kein Commit | `git checkout -b neuer-branch` |
|
||||||
|
| Änderungen gestaged, aber kein Commit | Geht genauso: `git checkout -b neuer-branch` |
|
||||||
|
| Änderungen gemacht, will aber neuen Stand von origin | Erst `commit` oder `stash`, dann `pull` |
|
||||||
|
| Feature abgeschlossen | `merge` zurück auf `main` |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### ℹ️ Mini-Cheatsheet
|
||||||
|
|
||||||
|
```bash
|
||||||
|
git add . # Alle Änderungen vormerken
|
||||||
|
git commit -m "Commit" # Änderungen sichern
|
||||||
|
git checkout main # Wechsel auf main
|
||||||
|
git pull # main aktualisieren
|
||||||
|
git checkout -b neuer-branch # Neuen Feature-Branch starten
|
||||||
|
```
|
||||||
|
|
||||||
|
[🚀 TOP](#-inhalt)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 📦 GIT_BRANCH_CLEANUP.md
|
||||||
|
|
||||||
|
### 🧹 Wann lösche ich einen Feature-Branch?
|
||||||
|
|
||||||
|
#### ✅ Nach dem Merge in `main`
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Lokal löschen
|
||||||
|
git branch -d feature/xyz
|
||||||
|
|
||||||
|
# Remote löschen
|
||||||
|
git push origin --delete feature/xyz
|
||||||
|
```
|
||||||
|
|
||||||
|
#### ❗ Nicht löschen, wenn …
|
||||||
|
|
||||||
|
- Der Branch wird noch gebraucht (z. B. Review, Bugfix)
|
||||||
|
- Der Merge war nur testweise oder unvollständig
|
||||||
|
- Du arbeitest noch weiter dran
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 🔁 Nachträglich löschen (wenn vergessen)
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Lokalen Branch löschen
|
||||||
|
git branch -d feature/xyz
|
||||||
|
|
||||||
|
# Remote-Branch löschen
|
||||||
|
git push origin --delete feature/xyz
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 📦 Merksatz
|
||||||
|
|
||||||
|
| Feature fertig und gemerged? | Dann: |
|
||||||
|
|:---|:---|
|
||||||
|
| ✅ | `git branch -d` + `git push origin --delete` |
|
||||||
|
| ❌ oder nicht sicher | Branch behalten |
|
||||||
|
|
||||||
|
[🚀 TOP](#-inhalt)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 📦 Branch-Namenskonventionen
|
||||||
|
|
||||||
|
Dieses Dokument beschreibt die standardisierten Branch-Namenskonventionen für unser Projekt. Ziel ist eine klare, nachvollziehbare Struktur für parallele Entwicklungszweige.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 🔧 Aufbau
|
||||||
|
|
||||||
|
Alle Branch-Namen folgen diesem Schema:
|
||||||
|
|
||||||
|
```plaintext
|
||||||
|
<prefix>/<bereich>-<kurze-beschreibung>
|
||||||
|
```
|
||||||
|
|
||||||
|
Beispiel:
|
||||||
|
|
||||||
|
```plaintext
|
||||||
|
feature/user-login
|
||||||
|
refactor/frontend-structure
|
||||||
|
chore/update-readme
|
||||||
|
```
|
||||||
|
|
||||||
|
Optional mit Ticket- oder Issue-ID:
|
||||||
|
|
||||||
|
```plaintext
|
||||||
|
feature/123-user-login
|
||||||
|
bugfix/87-fix-auth-header
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 📚 Übersicht der Präfixe
|
||||||
|
|
||||||
|
| Präfix | Zweck | Beispiel |
|
||||||
|
|--------------|------------------------------------------------------|------------------------------------------|
|
||||||
|
| `feature/` | Neue Funktionen / Erweiterungen | `feature/pdf-export` |
|
||||||
|
| `bugfix/` | Fehlerbehebung (nicht kritisch) | `bugfix/button-hover` |
|
||||||
|
| `hotfix/` | Kritische Fehlerbehebung auf produktivem System | `hotfix/payment-error` |
|
||||||
|
| `refactor/` | Code-Umbau ohne Funktionsänderung | `refactor/state-management` |
|
||||||
|
| `chore/` | Wartung, Infrastruktur, Dokumentation | `chore/clean-docker`, `chore/update-doc` |
|
||||||
|
| `cleanup/` | Entfernen von Altlasten oder veralteten Strukturen | `cleanup/unused-scripts` |
|
||||||
|
| `test/` | Tests und Testinfrastruktur | `test/mock-api` |
|
||||||
|
| `docs/` | Dokumentationsänderungen | `docs/setup-instructions` |
|
||||||
|
| `ci/` | Änderungen an CI/CD oder Build-System | `ci/add-github-actions` |
|
||||||
|
| `wip/` | Work in Progress (noch nicht bereit für Merge) | `wip/experimental-ui` |
|
||||||
|
| `release/` | Vorbereitung und Verwaltung von Releases | `release/v1.2.0` |
|
||||||
|
| `revert/` | Rücknahme von früheren Änderungen | `revert/broken-auth` |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 🧼 Empfehlung für Schönheitskorrekturen
|
||||||
|
|
||||||
|
Für reine Schönheits- und Strukturkorrekturen (keine funktionalen Änderungen):
|
||||||
|
|
||||||
|
- `refactor/ui-cleanup`
|
||||||
|
- `chore/html-beautify`
|
||||||
|
- `cleanup/unused-css`
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 📝 Hinweis
|
||||||
|
|
||||||
|
- Branch-Namen **immer klein schreiben**, mit `-` als Trenner.
|
||||||
|
- Kein Datum, kein Entwicklerkürzel im Namen (außer bei besonderen Teamregeln).
|
||||||
|
- `main` oder `master` ist unser stabiler Produktionszweig.
|
||||||
@ -24,3 +24,5 @@ dokus/git/git-submodule-leitfaden.md
|
|||||||
dokus/git/commit-etscheidungshilfe.md
|
dokus/git/commit-etscheidungshilfe.md
|
||||||
dokus/products/voltcraft625logicprobe/voltcraft625-logic-probe-anleitung.md
|
dokus/products/voltcraft625logicprobe/voltcraft625-logic-probe-anleitung.md
|
||||||
dokus/grundlagen/wahrheitstabelle.md
|
dokus/grundlagen/wahrheitstabelle.md
|
||||||
|
dokus/git/git_workflow.md
|
||||||
|
dokus/frameworks/havok-engine.md
|
||||||
|
|||||||
Loading…
x
Reference in New Issue
Block a user