WALUDO Outils
DOCS.01 WALUDO DOCS

Mémo Git

Référence des commandes Git courantes pour la configuration, les branches, les commits, les fusions, l’annulation, les dépôts distants et Conventional Commits, avec des exemples modifiables et copiables.

Commandes courantes

La plupart des commandes ci-dessous viennent de it-tools.tech et sont complétées par des pratiques de développement quotidiennes.

Le texte bleu dans les blocs de code peut être modifié pour changer et copier rapidement les exemples.

Configuration

Définir le nom d’utilisateur et l’adresse e-mail globaux :

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

Démarrer un projet

Initialiser un dépôt Git :

bash 
git init

Cloner un dépôt existant :

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

Commits

Valider toutes les modifications suivies :

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

Valider toutes les modifications :

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

Ajouter les nouvelles modifications au dernier commit :

bash 
git commit --amend --no-edit

Je me suis trompé

Modifier le message du commit le plus récent :

bash 
git commit --amend

Annuler le dernier commit tout en conservant les modifications :

bash 
git reset HEAD~1

Annuler les N derniers commits tout en conservant les modifications :

bash 
git reset HEAD~N

Annuler le dernier commit et supprimer toutes les modifications :

bash 
git reset HEAD~1 --hard

Réinitialiser la branche locale selon l’état distant :

bash 
git fetch origin
bash 
git reset --hard origin/branch-name

Divers

Renommer la branche locale master en main :

bash 
git branch -m master main

Convention des commits

Consultez la spécification Conventional Commits v1.0.0.

Valider votre commit

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

Référence rapide des types

TypeDescription
fixCorrige un bug
featAjoute une fonctionnalité
buildModifie le système de build (dépendances, interfaces externes, version de Node, etc.)
choreModifie des éléments hors logique métier (processus de build, configuration des outils, etc.)
ciModifie la configuration d’intégration continue (CI/CD)
docsModifie la documentation (README, documentation d’API, etc.)
styleModifie le style du code sans changer la logique
refactorRestructure le code sans changer son comportement
perfAméliore les performances
testModifie les cas de test

Scope

Un scope entre parenthèses peut suivre le type pour fournir un contexte supplémentaire :

feat(parser): adds ability to parse arrays

Changements incompatibles

Un point d’exclamation indique un changement incompatible et peut être ajouté à n’importe quel type :

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

Inclure BREAKING CHANGE dans le pied du commit produit le même effet.

Corps et pied sur plusieurs lignes

Exemple d’un commit avec un corps et un pied sur plusieurs lignes :

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

Spécification complète

Les mots-clés MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY et OPTIONAL doivent être interprétés comme l’indique la RFC 2119.

  • Chaque commit MUST commencer par un type, suivi d’un scope OPTIONAL, d’un point d’exclamation OPTIONAL, puis de deux-points et d’une espace REQUIRED
  • Une nouvelle fonctionnalité MUST utiliser le type feat
  • Une correction MUST utiliser le type fix
  • Le scope MAY suivre le type ; il MUST être un nom décrivant une partie du code entre parenthèses, par exemple fix(parser):
  • La description MUST suivre immédiatement les deux-points et l’espace du préfixe de type et de scope
  • Un corps plus long MAY suivre la description courte et MUST commencer après une ligne vide
  • Un ou plusieurs pieds MAY suivre le corps après une ligne vide ; chaque pied MUST contenir un token et un séparateur
  • Le token d’un pied MUST remplacer les espaces par des tirets, par exemple Acked-by ; l’exception est BREAKING CHANGE
  • Un changement incompatible MUST être signalé par ! dans le préfixe ou par le pied BREAKING CHANGE: description
  • Si ! est utilisé, BREAKING CHANGE: MAY être omis du pied et la description SHOULD expliquer le changement
  • Des types autres que feat et fix MAY être utilisés, par exemple docs: updated ref docs.
  • Les outils qui implémentent la spécification MUST analyser les unités sans tenir compte de la casse, sauf que BREAKING CHANGE MUST rester en majuscules
  • BREAKING-CHANGE MUST être synonyme de BREAKING CHANGE lorsqu’il est utilisé comme token de pied