L’utilisation de git ne se résume pas à un schéma de branches fixes que tout le monde utilise.
Chaque projet a ses propres besoins et en fonction de la taille de l’équipe, si il y a une équipe de QA ou pas, des façons de faire peuvent s’appliquer plus ou moins facilement.
Je vais vous présenter ici un workflow qui est inspiré de git flow.
Git flow est un bon outil, mais à mon sens il ne prévoit pas que le code soit revu et mergé via un outil comme GitLab ou Github.
master
depuis develop
ou hotfix-foo
doit être automatiquement taggé et livré en productiondevelop
depuis master
, aucun développement directement sur developfeature-foo
depuis develop
: on ne code pas directement sur feature-foo
code-foo
depuis feature-foo
pour coder l’intégralité d’un ticketcode-foo
est mergée sur feature-foo
feature-foo
sur un serveur pour être validé par la QA (tests fonctionnels) et le PO (toutes les demandes ont bien été traitées)code-foo
pour effectuer les correctionsdevelop
develop
doit être mergé au plus vite sur master
, pour ne pas avoir plusieurs features mergées sur develop
mais pas sur master
hotfix-foo
depuis master
master
, il faut rebase (et pas merge) develop
de master
pour récupérer le commit de hotfix sans changer son identifiantLes branches master
, develop
et feature-foo
doivent être protégées :
on doit passer par une merge request pour ajouter du code sur ces branches.
master
doit impérativement bloquer toute tentative de git push --force
,
ce qui recréerait une partie des commits et potentiellement changerait des identifiants de commit.
develop
doit bloquer les git push --force
sauf dans le cas d’un hotfix (étape 12) quand on rebase develop
de master
.
feature-foo
devrait bloquer les git push --force
pour éviter toute erreur manuelle, mais dans l’idée,
on peut en faire si on en a besoin.
Tant que cette branche n’est pas mergée sur develop
on peut faire ce que l’on veut dessus.
Vu qu’elles seront mergées et supprimées, ces branches n’ont pas de restrictions,
on peut faire ce que l’on veut dessus : git push --force
, git commit --amend
etc.
develop
Les branches master
et develop
sont les deux seules branches qui vont rester en vie durant tout votre projet.
master
et sur develop
doivent être les mêmes pour certifier qu’on a bien les mêmes commitsmaster
develop
doit être mergée sur master
et partir en production aussi vite que possibledevelop
mais pas sur master
develop
?Cette branche existe uniquement pour qu’un hotfix puisse être fait depuis la version en production
(donc la branche master
) tout en conservant son identifiant de commit entre master
et develop
.
Sans cette branche develop, si on doit faire un hotfix et que du code est déjà mergé sur master, alors la prochaine livraison contiendra notre hotfix + du code d’une feature qu’on ne veut sûrement pas livrer en même temps qu’un hotfix.
Si vous mettez un /
dans le nom d’une branche, pour git, c’est un répertoire qui sera créé dans .git/branches
.
Exemples :
feature-foo
, git va créer le fichier .git/branches/feature-foo
feature/foo
, git va créer le fichier .git/branches/feature/foo
Ca peut être bloquant si vous créez une branche feature/foo
, vous ne pourrez ensuite plus créer de branche feature
parce qu’il sera impossible de créer un fichier qui a le même nom que le répertoire précédement créé.
Pour éviter d’avoir ce genre de problèmes et de devoir supprimer manuellement des répertoires dans le répertoire .git
,
évitez de mettre des /
dans le nom des branches.