Git-Repository konfigurieren

Ein Git-Repository mit geeigneter Konfiguration fuer den jeweiligen Projekttyp einrichten.

Wann verwenden

• Versionskontrolle fuer ein neues Projekt initialisieren

• .gitignore

  fuer eine bestimmte Sprache oder ein Framework hinzufuegen
• Branch-Schutz und -Konventionen einrichten
• Commit-Hooks konfigurieren

Eingaben

• Erforderlich: Projektverzeichnis
• Erforderlich: Projekttyp (R-Paket, Node.js, Python, allgemein)
• Optional: URL des Remote-Repositorys
• Optional: Branch-Strategie (Trunk-based, Git Flow)
• Optional: Commit-Message-Konvention

Vorgehensweise

Schritt 1: Repository initialisieren

cd /path/to/project
git init
git branch -M main

Erwartet: Das Verzeichnis

.git/

wurde erstellt. Der Standard-Branch heisst

main

.

Bei Fehler: Wenn

git init

fehlschlaegt, sicherstellen, dass Git installiert ist (

git --version

). Ist bereits ein

.git/

-Verzeichnis vorhanden, ist das Repository bereits initialisiert — diesen Schritt ueberspringen.

Schritt 2: .gitignore erstellen

R-Paket:

# R artifacts
.Rhistory
.RData
.Rproj.user/
*.Rproj

# Environment (sensitive)
.Renviron

# renv library (machine-specific)
renv/library/
renv/staging/
renv/cache/

# Build artifacts
*.tar.gz
src/*.o
src/*.so
src/*.dll

# Documentation build
docs/
inst/doc/

# IDE
.vscode/
.idea/

# OS
.DS_Store
Thumbs.db

Node.js/TypeScript:

node_modules/
dist/
build/
.next/
.env
.env.local
.env.*.local
*.log
npm-debug.log*
.DS_Store
Thumbs.db
.vscode/
.idea/
coverage/

Python:

__pycache__/
*.py[cod]
*.egg-info/
dist/
build/
.eggs/
.venv/
venv/
.env
*.log
.mypy_cache/
.pytest_cache/
htmlcov/
.coverage
.DS_Store
.idea/
.vscode/

Erwartet: Die

.gitignore

-Datei wurde mit projekttyp-geeigneten Eintraegen erstellt. Sensible Dateien (

.Renviron

,

.env

) und generierte Artefakte sind ausgeschlossen.

Bei Fehler: Wenn unklar ist, welche Eintraege aufzunehmen sind,

gitignore.io

oder GitHubs

.gitignore

-Vorlagen als Ausgangspunkt nutzen und fuer das Projekt anpassen.

Schritt 3: Ersten Commit erstellen

git add .gitignore
git add .  # Review what's being added first with git status
git commit -m "Initial project setup"

Erwartet: Der erste Commit wurde erstellt und enthaelt

.gitignore

sowie die initialen Projektdateien.

git log

zeigt einen Commit.

Bei Fehler: Wenn

git commit

mit "nothing to commit" fehlschlaegt, sicherstellen, dass Dateien mit

git add

gestaged wurden. Wenn mit einem Autorenidentitaetsfehler fehlschlaegt,

git config user.name

und

git config user.email

setzen.

Schritt 4: Remote verbinden

# Add remote
git remote add origin git@github.com:username/repo.git

# Push
git push -u origin main

Erwartet: Das Remote

origin

ist konfiguriert.

git remote -v

zeigt Fetch- und Push-URLs. Der initiale Commit wurde zum Remote gepusht.

Bei Fehler: Wenn der Push mit "Permission denied (publickey)" fehlschlaegt, SSH-Schluessel konfigurieren (siehe

setup-wsl-dev-environment

). Wenn das Remote bereits existiert, mit

git remote set-url origin <url>

aktualisieren.

Schritt 5: Branch-Konventionen einrichten

Trunk-based (empfohlen fuer kleine Teams):

• main

  : produktionsreifer Code
• Feature-Branches:

  feature/beschreibung

• Fehlerbehebungen:

  fix/beschreibung

# Create feature branch
git checkout -b feature/add-authentication

# After work is done, merge or create PR
git checkout main
git merge feature/add-authentication

Erwartet: Die Branch-Namenskonvention ist etabliert und dokumentiert. Teammitglieder wissen, welches Praefix fuer welche Art von Arbeit zu verwenden ist.

Bei Fehler: Wenn Branches bereits inkonsistent benannt sind, mit

git branch -m alter-name neuer-name

umbenennen und offene Pull Requests aktualisieren.

Schritt 6: Commit-Konventionen konfigurieren

Format der Conventional Commits:

type(scope): description

feat: add user authentication
fix: correct calculation in weighted_mean
docs: update README installation section
test: add edge case tests for parser
refactor: extract helper function
chore: update dependencies

Erwartet: Die Commit-Message-Konvention ist dokumentiert und vom Team vereinbart. Kuenftige Commits folgen dem Format

type: description

.

Bei Fehler: Wenn Teammitglieder die Konvention nicht einhalten, mit einem commit-msg Hook erzwingen, der das Format validiert (siehe Schritt 7).

Schritt 7: Pre-Commit-Hooks einrichten (Optional)

.githooks/pre-commit

erstellen:

#!/bin/bash
# Run linter before commit

# For R packages
if [ -f "DESCRIPTION" ]; then
  Rscript -e "lintr::lint_package()" || exit 1
fi

# For Node.js
if [ -f "package.json" ]; then
  npm run lint || exit 1
fi

chmod +x .githooks/pre-commit
git config core.hooksPath .githooks

Erwartet: Der Pre-Commit-Hook laeuft automatisch bei jedem

git commit

. Linting-Fehler blockieren den Commit, bis sie behoben sind.

Bei Fehler: Wenn der Hook nicht ausgefuehrt wird, pruefen ob

core.hooksPath

gesetzt ist (

git config core.hooksPath

) und die Hook-Datei ausfuehrbar ist (

chmod +x

).

Schritt 8: README erstellen

# Minimal README
echo "# Project Name" > README.md
echo "" >> README.md
echo "Brief description of the project." >> README.md
git add README.md
git commit -m "Add README"

Erwartet:

README.md

wurde in das Repository eingecheckt. Das Projekt hat eine minimale, aber informative Einstiegsseite auf GitHub.

Bei Fehler: Wenn

README.md

bereits existiert, aktualisieren statt ueberschreiben. In R-Projekten

usethis::use_readme_md()

fuer eine Vorlage mit Badges verwenden.

Validierung

• .gitignore

  schliesst sensible und generierte Dateien aus
• Keine sensiblen Daten (Tokens, Passwoerter) in getrackten Dateien
• Remote-Repository verbunden und erreichbar
• Branch-Namenskonventionen dokumentiert
• Initialer Commit sauber erstellt

Haeufige Stolperfallen

• Commit vor .gitignore: Zuerst

  .gitignore

  hinzufuegen. Bereits getrackte Dateien werden von spaeter hinzugefuegten

  .gitignore

  -Eintraegen nicht beeinflusst.
• Sensible Daten in der Historie: Wenn Geheimnisse eingecheckt wurden, bleiben sie auch nach dem Loeschen in der Historie.

  git filter-repo

  oder BFG zum Bereinigen verwenden.
• Grosse Binaerdateien: Keine grossen Binaerdateien einchecken. Git LFS fuer Dateien > 1 MB verwenden.
• Zeilenenden:

  core.autocrlf=input

  unter Windows/WSL setzen, um CRLF/LF-Probleme zu vermeiden.

Verwandte Skills

• commit-changes

  - Staging- und Commit-Workflow

• manage-git-branches

  - Branch-Erstellung und -Konventionen

• create-r-package

  - Git-Einrichtung als Teil der R-Paketerstellung

• setup-wsl-dev-environment

  - Git-Installation und SSH-Schluessel

• create-github-release

  - Releases aus dem Repository erstellen

• security-audit-codebase

  - Auf eingecheckte Geheimnisse pruefen