Git gud

French

English

French

English

Appearance

Le workflow d’une fonctionnalité : de l’idée au merge ​

C’est le workflow que vous utiliserez 90 % du temps. Le standard pour ajouter une nouvelle capacité au code. Le maîtriser, c’est contribuer efficacement tout en gardant un historique net.

Bugfix, chore ou autre tâche vers main ? C’est exactement la même mécanique. Mémorisez‑la, vous la ferez en boucle.

La règle d’or : MVC (Minimal Viable Change)

Une branche doit contenir le plus petit changement complet, stable et testable. Si une US est trop grosse, découpez.

Branches petites ⇒ reviews rapides ⇒ moins de conflits ⇒ moins de risques.

Les 5 étapes ​

Étape 1 : 🌿 Partir propre ​

Avant d’écrire la moindre ligne, partez de l’état le plus récent de main. C’est votre établi rangé : vous vous évitez des sueurs froides plus tard.

bash
# 1. Basculer sur main
git checkout main

# 2. Récupérer les dernières mises à jour
git pull

Ensuite, créez votre branche de fonctionnalité depuis main.

:::important Convention de nommage : feature/<Ticket-ID>_<courte-description>

  • Préfixe feature/ pour organiser visuellement
  • Ticket obligatoire pour la traçabilité (ex : GG-123)
  • Description courte (2‑3 mots) pour la lisibilité :::

Et pour les correctifs ?

Même processus. Les seules différences :

  • Nom de branche bugfix/<Ticket-ID>_<desc>
  • Message de commit qui commence par fix: (ex : fix(GG-456): corrige le bouton de login)
bash
# Créer et basculer en un coup
git checkout -b feature/GG-123_user-login-form

Vous êtes isolé et prêt à coder.

Étape 2 : 💻 Travailler et commit localement ​

Votre bac à sable. Commitez souvent. Pas besoin d’être « parfait » tout de suite : on nettoiera après.

Pensez « points de sauvegarde ». Ça vous permet d’expérimenter sans peur.

bash
# 1. Indexer
git add .

# 2. Commit (Conventional Commits !)
git commit -m "feat(GG-123): ajoute email et mot de passe"

# Si le fichier était déjà indexé, on peut faire court :
git commit -am "feat(GG-123): ajoute email et mot de passe"

Après votre premier commit, soit vous recommittez, soit vous « amendez » le précédent :

bash
git add .
git commit --amend

Vim

Par défaut, l’éditeur de message est Vim. insert pour écrire, Esc puis :wq pour enregistrer et quitter.

Envie d’un autre éditeur ?

bash
# VS Code
git config --global core.editor "code --wait"

Étape 3 : 🚀 Partager et ouvrir la PR/MR ​

Poussez votre branche pour la rendre visible et ouvrir une PR/MR.

bash
# -u configure l’upstream pour les push suivants
git push -u origin feature/GG-123_user-login-form

Pousser les mises à jour

Ensuite, un simple :

bash
git push

Étape 4 : 🔄 Nettoyer et se remettre à jour ​

main a avancé pendant que vous bossiez. À vous de mettre votre branche à jour et de résoudre les conflits éventuels.

Deux outils : merge (rapide, historique sale) et rebase (un peu plus exigeant, historique net). La version longue est ici : ➡️ Merge vs. Rebase.

Notre recommandation : squash‑then‑rebase. Simple à vivre, propre à lire. Quoi qu’il arrive, votre branche sera écrasée en un seul commit sur main.

Rebase (lent mais propre)

1. Écrasez vos commits ​

bash
git rebase -i HEAD~3

Gardez le premier en pick, passez les suivants en s (squash) ou f (fixup).

2. Rebase sur main ​

bash
git pull --rebase origin main

En cas de réécriture d’historique, poussez en sécurité :

bash
git push --force-with-lease --force-if-includes

(Ou votre alias git pf des règles d’or 😉)

Merge (rapide mais brouillon)
bash
git pull --merge origin main
git push

Étape 5 : ✅ Finaliser et merger ​

Votre fonctionnalité est prête, relue, à jour. On atterrit.

La cuisine interne côté ligne de commande

Normalement gérée par votre forge, mais pour les curieux :

shell
git checkout main
git merge --squash feature/GG-123_user-login-form
git commit -am "feat(GG-123): User login form"

Check‑list avant merge ​

  • [ ] Titre et description au format Conventional Commits
  • [ ] Revue faite, sans ego (on lit Egoless Programming)
  • [ ] Squash activé et suppression de la branche après merge
  • [ ] CI/CD au vert et feedback traité
  • [ ] Tests (unitaires, intégration, E2E, QA…)

Ensuite on merge. Un seul beau commit sur main.

Et la version SemVer ?

GitVersion voit le préfixe feat: et calcule la nouvelle version, par exemple 1.1.0-beta.1.

Bravo, vous avez livré une fonctionnalité !

Pour aller plus loin ​

Fonctionnalités longues, mono‑repo avec couches multiples à synchroniser ? Jetez un œil à Task Branches & Merge Trains.