GITHUB KONVENTIONEN UND STANDARD-DATEIEN
========================================

WAS SIND GITHUB-KONVENTIONEN?
-----------------------------
GitHub erkennt bestimmte Dateinamen automatisch und zeigt
sie prominent an. Diese "Special Files" helfen bei der
Projektorganisation und erleichtern die Zusammenarbeit.

WICHTIGE DATEIEN IM ROOT-VERZEICHNIS
------------------------------------
Diese Dateien gehoeren ins Hauptverzeichnis des Projekts:

  Dateiname          Zweck
  -----------------------------------------------------------------
  README.md          Projektbeschreibung, wird auf der
                     Repository-Startseite angezeigt

  LICENSE            Lizenzinformationen (MIT, GPL, Apache, etc.)
                     GitHub erkennt gaengige Lizenzen automatisch

  CHANGELOG.md       Versionshistorie und Aenderungen

  CONTRIBUTING.md    Anleitung fuer Beitragende
                     Wird bei Pull Requests verlinkt

  CODE_OF_CONDUCT.md Verhaltensregeln fuer die Community

  SECURITY.md        Sicherheitsrichtlinien und wie man
                     Schwachstellen melden kann

  SUPPORT.md         Hinweise wo man Hilfe bekommt

  AUTHORS            Liste der Hauptautoren

  .gitignore         Dateien die Git ignorieren soll

  .env.example       Vorlage fuer Umgebungsvariablen
                     (niemals .env selbst committen!)

  requirements.txt   Python-Abhaengigkeiten
  package.json       Node.js-Abhaengigkeiten
  Cargo.toml         Rust-Abhaengigkeiten
  go.mod             Go-Abhaengigkeiten

DER .GITHUB-ORDNER
------------------
Spezielle GitHub-Konfigurationen gehoeren in .github/:

  .github/
  ├── workflows/           GitHub Actions (CI/CD)
  │   ├── ci.yml          Continuous Integration
  │   ├── release.yml     Automatische Releases
  │   └── test.yml        Test-Automation
  │
  ├── ISSUE_TEMPLATE/      Vorlagen fuer Issues
  │   ├── bug_report.md   Bug-Meldungen
  │   ├── feature_request.md  Feature-Wuensche
  │   └── config.yml      Template-Konfiguration
  │
  ├── PULL_REQUEST_TEMPLATE.md   PR-Vorlage
  │
  ├── CODEOWNERS          Wer ist fuer welchen Code zustaendig?
  │                       Automatische Review-Zuweisung
  │
  ├── FUNDING.yml         Sponsoring-Button konfigurieren
  │
  ├── dependabot.yml      Automatische Dependency-Updates
  │
  └── SECURITY.md         Alternativ zu Root (GitHub bevorzugt)

DATEI-PRIORITAETEN
------------------
Wenn eine Datei an mehreren Orten existiert, gilt:

  1. .github/       (hoechste Prioritaet)
  2. Root /         (Standard)
  3. docs/          (niedrigste Prioritaet)

Beispiel: Existieren sowohl /CONTRIBUTING.md als auch
.github/CONTRIBUTING.md, wird die .github-Version angezeigt.

README-VARIANTEN
----------------
GitHub unterstuetzt verschiedene README-Formate:

  README.md          Markdown (empfohlen)
  README.rst         reStructuredText (Python-Projekte)
  README.txt         Plain Text
  README.adoc        AsciiDoc
  README             Ohne Extension (weniger empfohlen)

LICENSE-TYPEN
-------------
Gaengige Open-Source-Lizenzen:

  Lizenz             Beschreibung
  -----------------------------------------------------------------
  MIT                Sehr permissiv, kaum Einschraenkungen
  Apache-2.0         Permissiv mit Patent-Schutz
  GPL-3.0            Copyleft, Ableitungen muessen GPL sein
  BSD-3-Clause       Aehnlich MIT, mit Namensklausel
  LGPL-3.0           GPL fuer Bibliotheken (weniger restriktiv)
  AGPL-3.0           GPL + Netzwerk-Klausel (SaaS)
  Unlicense          Public Domain
  CC0-1.0            Creative Commons Zero

GitHub erkennt diese automatisch wenn die LICENSE-Datei
im Root liegt und zeigt ein Badge an.

.GITIGNORE BEST PRACTICES
-------------------------
Typische Eintraege fuer verschiedene Projekttypen:

  Python:            __pycache__/, *.pyc, .env, venv/
  Node.js:           node_modules/, .env, dist/
  Java:              *.class, target/, *.jar
  Allgemein:         .DS_Store, Thumbs.db, *.log, .idea/

Tipp: gitignore.io generiert .gitignore fuer beliebige
Technologie-Kombinationen.

COMMIT-MESSAGE-KONVENTIONEN
---------------------------
Conventional Commits Format:

  <type>(<scope>): <description>

  Typen:
    feat:     Neues Feature
    fix:      Bugfix
    docs:     Dokumentation
    style:    Formatierung (kein Code-Aenderung)
    refactor: Code-Umbau ohne Funktionsaenderung
    test:     Tests hinzufuegen/aendern
    chore:    Build, Dependencies, etc.

  Beispiele:
    feat(auth): add OAuth2 support
    fix(api): handle null response correctly
    docs: update installation instructions

BRANCH-NAMENSKONVENTIONEN
-------------------------
Gaengige Muster:

  main / master      Haupt-Branch (stabil)
  develop            Entwicklungs-Branch
  feature/<name>     Neue Features
  bugfix/<name>      Bugfixes
  hotfix/<name>      Dringende Fixes fuer Production
  release/<version>  Release-Vorbereitung

SEMANTIC VERSIONING
-------------------
Format: MAJOR.MINOR.PATCH (z.B. 2.1.3)

  MAJOR    Inkompatible API-Aenderungen
  MINOR    Neue Features (abwaertskompatibel)
  PATCH    Bugfixes (abwaertskompatibel)

Pre-Release: 1.0.0-alpha, 1.0.0-beta.1, 1.0.0-rc.1

GITHUB ACTIONS BASICS
---------------------
Workflow-Datei in .github/workflows/:

  name: CI
  on: [push, pull_request]
  jobs:
    test:
      runs-on: ubuntu-latest
      steps:
        - uses: actions/checkout@v4
        - name: Run tests
          run: npm test

DEPENDABOT KONFIGURATION
------------------------
In .github/dependabot.yml:

  version: 2
  updates:
    - package-ecosystem: "pip"
      directory: "/"
      schedule:
        interval: "weekly"

CODEOWNERS SYNTAX
-----------------
In .github/CODEOWNERS:

  # Globale Owner
  *                    @username

  # Verzeichnis-Owner
  /docs/               @docs-team
  /src/api/            @backend-team

  # Datei-Owner
  *.js                 @frontend-team

SIEHE AUCH
----------
wiki/github_einfuehrung.txt   Git und GitHub Grundlagen
