Bonnes pratiques
Git

Lorsque l’on utilise Git, surtout quand on est débutant, on ne sait pas toujours comment nommer correctement ses branches ou ses messages de commits. Pourtant il est primordial pour s’y retrouver dans un projet, de respecter une convention de nommage.

C'est ce que je vous propose dans cet article. Avez-vous une autre convention de nommage ? Je suis curieux de savoir


Partagé par Axel Shaïta
il y a plus de 3 ans
4

Baptiste Pottier il y a plus de 3 ans
On peut aussi questionner le github flow et s’orienter vers le trunkbaseddevelopment.com.
Corentin Leffy il y a plus de 3 ans
Super article ! Merci ! Je cherchais une source d'inspiration pour générer un CHANGELOG à partir de commits, et celle-ci m'inspire ☺️

En effet, le nommage des branches et des commits (surtout les commits) est très important et trop souvent négligé. Les commits peuvent être d'une aide très précieuse quand on travaille sur un système legacy, puisqu'il va nous permettre de comprendre l'histoire de celui-ci. À ne pas sous-estimer donc !

J'utilise une convention similaire à celle présentée, un peu plus riche et visuelle : gitmoji.carloscuesta.me . L'idée est très proche : on utilise un emoji en Markdown pour le type. Ainsi, la plateforme (GitLab ou Github par exemple) va interpréter le Markdown et afficher l'emoji. C'est plus visuel et on garde cette possibilité de trier les commits par type, vu que l'on utilise du texte pour les typer.

Je commit très régulièrement de manière à être capable de retourner à la précédente version stable de mon application. Cependant, en faisant cela, je ne prends pas le temps de remplir le corps du commit. Je m'arrête très souvent au sujet (qui peut être un peu long par moment). Et vous ? Est-ce que vous utilisez souvent le corps du commit ?
Charly Laurent il y a plus de 3 ans
Pour les commits, je m'inspire de cet article : tbaggery.com/... , en précisant le numéro de ticket dès le début du message.
Pour les branches, je travaille avec cette méthode : nvie.com/... , qui propose des noms de branche comme release-0.1 ou hotfix-0.1.1, mais ne spécifie rien de particulier pour les branches feature.
La ressource proposée est intéressante, car les conventions de nommage sont ultra importantes lorsqu'on travaille en équipe. Je garde ça dans mes favoris :-)
Marc Bouvier il y a plus de 3 ans
Pour les conventions de nommage des commits, ca me semble correspondre à "conventional commit" qui semble être de plus en plus suivi.

www.conventionalcommits.org/...
Benoit GANTAUME il y a plus de 3 ans
@Baptiste Pottier j'avais vu une conf sur le trunk base dev, j'avais trouvé ça assez dingue et puissant.
As-tu une expérience avec ?
Quels sont pour toi les avantages par rapport à un git flow ?
Axel Shaïta il y a plus de 3 ans
@Corentin Leffy J'ai pas mal utilisé cette convention que je trouve, comme tu dis, très visuelle. J'en fais d'ailleurs mention très brièvement dans mon article.

@Marc Bouvier C'est exactement cette convention ! Effectivement elle est de plus en plus suivie car pas mal d'outils se basent sur celle-ci pour automatiser la génération des changelogs ou le versionning (en se basant sur semver.org/lang/fr/)
Baptiste Pottier il y a plus de 3 ans - modifié il y a plus de 3 ans
@benoit Oui, nous l'utilisons depuis une année en mode "souple", c'est à dire que nous gardons une branch develop en plus de la master, là ou certain "extremistes" ne gardent que la master (et franchement on s'interroge à ne pas pousser jusque là tellement c'est pratique).
Les gains sont :
- l'obligation de travailler propre (il faut penser au copain)
- obligation de faire de petit commit
- incitation forte au feature flag
- Jamais de gros diff, jamais de branch qui se meurent ou qui durent des jours et des jours voir plus (sympa à merger ...)

On peut très bien savoir faire cela avec des branches, mais alors elles n'ont plus d’intérêt (si on merge toutes les heures, autant faire dans develop).
A chaque onboarding, le nouvel arrivant est dérangé mais très vite il adore (et on utilise les tags!) c'est queque chose qu'il faut pratiquer pour véritablement en comprendre l'avantage (comme le TDD sur ce point)
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
CTO Craft d'une boite de services avec Aurélien Estoup
Accéder à l'épisode
C'est reparti pour la saison 4
Accéder à l'épisode
Quoi de neuf les devs ? Numéro 26
Afficher la ressource
Quoi de neuf les devs ? Numéro 33
Afficher la ressource
Modéliser une architecture logicielle grâce aux modèle C4 ou C4 model en anglais
Afficher la ressource
Artisan Développeur utilise des cookies afin de t'offrir les meilleurs services. En poursuivant ta navigation, tu acceptes l’utilisation de cookies. En savoir plus