Git-Merkblatt

Schnellnavigation

Häufige Befehle
Commit-Konvention

Häufige Befehle

Die meisten folgenden Befehle stammen von it-tools.tech und wurden um praktische Erfahrungen aus der Entwicklung ergänzt.

Blauer Text in den Codeblöcken kann bearbeitet und anschließend schnell kopiert werden.

Konfiguration

Globalen Benutzernamen und E-Mail-Adresse festlegen:

bash

git config --global user.name "WaLudo"
git config --global user.email "waludo@gmail.com"

Neues Projekt beginnen

Ein neues Git-Repository initialisieren:

bash

git init

Ein vorhandenes Git-Repository klonen:

bash

git clone https://github.com/WaLudo/waludo-tools.git

Commits

Alle verfolgten Änderungen committen:

bash

git commit -am "feat: add two cups of coffee"

Alle Änderungen committen:

bash

git add .
git commit -m "feat: add five cups of coffee"

Neue Änderungen an den letzten Commit anhängen:

bash

git commit --amend --no-edit

Etwas ist schiefgelaufen

Die Nachricht des letzten Commits bearbeiten:

bash

git commit --amend

Den letzten Commit rückgängig machen, Änderungen aber behalten:

bash

git reset HEAD~1

Die letzten N Commits rückgängig machen, Änderungen aber behalten:

bash

git reset HEAD~N

Den letzten Commit rückgängig machen und alle Änderungen verwerfen:

bash

git reset HEAD~1 --hard

Den lokalen Branch auf den Zustand des Remotes zurücksetzen:

bash

git fetch origin

bash

git reset --hard origin/branch-name

Verschiedenes

Den lokalen Branch master in main umbenennen:

bash

git branch -m master main

Commit-Konvention

Siehe die Spezifikation Conventional Commits v1.0.0.

Commit prüfen

git commit -m "feat(scope): description"

Kurzübersicht der Typen

Typ	Beschreibung
fix	Behebt einen Fehler
feat	Führt eine neue Funktion ein
build	Ändert das Build-System (Abhängigkeiten, externe Schnittstellen, Node-Version usw.)
chore	Ändert nicht fachliche Bereiche (Build-Prozess, Werkzeugkonfiguration usw.)
ci	Ändert die Konfiguration der kontinuierlichen Integration (CI/CD)
docs	Ändert Dokumentation (README, API-Dokumentation usw.)
style	Ändert den Code-Stil, ohne die Logik zu verändern
refactor	Strukturiert den Code um, ohne sein Verhalten zu ändern
perf	Verbessert die Leistung
test	Ändert Testfälle

Scope

Nach dem Typ kann ein Scope in Klammern zusätzlichen Kontext liefern:

feat(parser): adds ability to parse arrays

Breaking Changes

Ein Ausrufezeichen kennzeichnet eine inkompatible Änderung und kann an jeden Typ angehängt werden:

feat(api)!: send an email to the customer when a product is shipped

Dasselbe lässt sich mit BREAKING CHANGE im Footer ausdrücken.

Mehrzeiliger Body und Footer

Beispiel für einen Commit mit mehrzeiligem Body und Footer:

fix: prevent racing of requests

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Remove timeouts which were used to mitigate the racing issue but are
obsolete now.

Reviewed-by: Z
Refs: #123

Vollständige Spezifikation

Die Schlüsselwörter MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY und OPTIONAL sind gemäß RFC 2119 auszulegen.

Jeder Commit MUST mit einem Typ beginnen, gefolgt von einem OPTIONAL Scope, einem OPTIONAL Ausrufezeichen und einem REQUIRED abschließenden Doppelpunkt mit Leerzeichen
Eine neue Funktion MUST den Typ feat verwenden
Eine Fehlerbehebung MUST den Typ fix verwenden
Ein Scope MAY nach dem Typ stehen; er MUST ein Substantiv für einen Codebereich in Klammern sein, zum Beispiel fix(parser):
Die Beschreibung MUST unmittelbar auf Doppelpunkt und Leerzeichen des Typ-Scope-Präfixes folgen
Nach der kurzen Beschreibung MAY ein längerer Body stehen, der nach einer Leerzeile MUST beginnen
Nach einer weiteren Leerzeile MAY ein oder mehrere Footer folgen; jeder Footer MUST ein Token und einen Trenner enthalten
Das Token eines Footers MUST Leerzeichen durch Bindestriche ersetzen, zum Beispiel Acked-by; BREAKING CHANGE ist die Ausnahme
Eine inkompatible Änderung MUST mit ! im Präfix oder mit dem Footer BREAKING CHANGE: Beschreibung markiert werden
Wenn ! verwendet wird, MAY BREAKING CHANGE: im Footer entfallen; die Beschreibung SHOULD die Änderung erläutern
Andere Typen als feat und fix MAY verwendet werden, etwa docs: updated ref docs.
Implementierungen der Spezifikation MUST die Informationseinheiten ohne Beachtung der Groß-/Kleinschreibung verarbeiten; BREAKING CHANGE MUST großgeschrieben bleiben
BREAKING-CHANGE MUST als Footer-Token synonym zu BREAKING CHANGE behandelt werden