claude-projects/ai-control/.claude/skills/git-commit/SKILL.md

name, description

name	description
git-commit	Commit + Push des ai-control-App-Repos auf lintus (origin, volle Dev-Historie). Optional, nur auf ausdrückliche Ansage: kuratierter Squash-Publish + Tag auf github und GitHub-Release mit Linux-Binaries. Gedacht für die Linux-Box.

git-commit — ai-control veröffentlichen

Zwei Ebenen, strikt getrennt:

1. Immer: Commit + Push auf lintus (origin) — die volle Dev-Historie.
2. Optional, nur wenn ausdrücklich verlangt: Publish auf github (Squash-Mirror) und ein GitHub-Release mit Linux-Binaries.

Nie ohne Ansage die github-Ebene mitlaufen lassen. Commit-Messages ohne jeden Claude-Hinweis (kein Co-Authored-By, kein „Generated with").

Repo & Remotes

• App-Repo: ~/projects/ai-control
• origin → ssh://git@git.lintus.art:2222/marcus.hinz/ai-control.git — volle Historie, hierher geht jeder Commit.
• github → https://github.com/mHinz-hub/ai-control.git — kuratierter Squash-Mirror: pro Release genau ein Commit ai-control X.Y.Z, dessen Tree dem Dev-Tree entspricht. Die volle Dev-Historie gehört nicht dorthin.

~/claude-projects/ai-control (Control-Repo) ist ein anderes Repo (nur lintus) — nicht gemeint.

1. Normaler Commit + Push (immer)

cd ~/projects/ai-control
git add -A
git status -s                 # prüfen, was reingeht
git commit -m "<sachliche Nachricht>"
git push origin main

2. github-Publish (optional)

Voraussetzung: der Release-Commit liegt auf lokalem main und ist auf lintus gepusht; bei einem Versionssprung ist die Version in allen vier Dateien gehoben (siehe Abschnitt 4).

git push github main ist verboten (divergiert gegen den Squash-Mirror → Reject). Stattdessen einen einzelnen Squash-Commit mit dem aktuellen Tree auf github/main setzen:

cd ~/projects/ai-control
git fetch github
tree=$(git rev-parse HEAD^{tree})
new=$(git commit-tree "$tree" -p github/main -m "ai-control X.Y.Z")
git push github "$new:main"          # Squash-Commit als neues github/main
git tag -f vX.Y.Z "$new"             # Tag auf den Squash-Commit (nicht den Dev-Commit)
git push github -f vX.Y.Z            # bestehenden Tag ggf. ersetzen

Das hält die lokale Dev-Historie unangetastet und reiht sich in ai-control 0.1.0 / 0.1.1 / … ein. Der Tag zeigt bewusst auf den Squash-Commit, nicht auf den Dev-Commit.

3. Release mit Linux-Binaries (optional, auf der Linux-Box)

Baudeps auf der Box: webkit2gtk-4.1, libgtk-3, libayatana-appindicator3, librsvg2, patchelf.

cd ~/projects/ai-control
npm run tauri build
# Artefakte:
#   src-tauri/target/release/bundle/appimage/ai-control_*.AppImage
#   src-tauri/target/release/bundle/deb/ai-control_*.deb

# Release anlegen (falls noch keins zum Tag existiert):
gh release create vX.Y.Z --repo mHinz-hub/ai-control --title "vX.Y.Z" --notes "<Änderungen>"

# Binaries anhängen (jederzeit nachträglich möglich):
gh release upload vX.Y.Z --repo mHinz-hub/ai-control \
  src-tauri/target/release/bundle/appimage/ai-control_*.AppImage \
  src-tauri/target/release/bundle/deb/ai-control_*.deb

Der macOS-Build (./build.sh, DMG) hängt nicht am Linux-Build; macos-private-api u. Ä. sind per cfg aus. Die GNOME-Popup-Extension ist separat, kein Teil des Binaries.

4. Version heben (bei Release)

Vor Abschnitt 2/3 die Version in vier Dateien gleichziehen:

• package.json → "version"
• src-tauri/Cargo.toml → [package] version
• src-tauri/Cargo.lock → Eintrag unter name = "ai-control"
• src-tauri/tauri.conf.json → "version"

Dann normal committen (Abschnitt 1), danach optional 2/3.