Convention dans les messages de commits

GerardPaligot commented 10 years ago

Actuellement, les messages des commits des contributeurs ne sont pas très explicites sur les changements apportés. J'aimerais discuter sur une convention à appliquer pour ce projet. Personnellement, je suis participant de la convention initiée par AngularJS et maintenant utilisée par beaucoup de projets.

Qu'en pensez-vous ?

SpaceFox commented 10 years ago

Je suis d'accord pour dire que ce point pourrait être amélioré.

Cependant je propose une autre convention : "on s'efforce de rendre le truc clair, et KISS".

Sérieusement, le document Git Commit Message Conventions fait six pages.

C'est peut-être indispensable pour d'énormes projets, mais je ne pense vraiment pas que ce soit adapté à notre structure. Je veux dire, si j'arrive sur un projet développé par une équipe de même pas 10 personnes et que je dois me taper 6 pages de lecture juste pour pouvoir commiter le moindre fichier, je vais fuir. Sérieusement : la norme proposé utilise des footers. C'est peut-être une erreur, mais un bon quart de mes commits doivent être plus courts que le format proposé.

Alex-D commented 10 years ago

On peut pas se limiter aux guidelines ? Cf ce bloc : https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#-git-commit-guidelines sans partir dans les méandres de conventions complexes ?

Déjà si on faisait le truc genre

**fix** : Tutorial import #1256565

avec éventuellement du détail dans le body.

GerardPaligot commented 10 years ago

On est pas obligé de suivre la convention d'AngularJS, ni de la suivre à la lettre. Par contre, faudrait définir notre propre convention (dérivant d'une autre ou pas).

Comme le mentionne Alex, il existe une version simplifiée qui ne tient pas sur 6 pages mais peut aisément tenir sur une seule. C'est ce qu'on utilise au taff et je dois dire qu'on obtient un historique vraiment claire. On est en train de travailler pour générer un changelog automatiquement à partir de notre historique Git.

Sans aller jusque là pour ZdS, ça ne sera que bénéfique au projet.

SpaceFox commented 10 years ago

En fait j'aime bien celle que tu as appliqué toi-même dans ce projet : #id_ticket description + éventuellement un complément sur la ligne en-dessus si besoin.

J'y vois deux énormes avantages :

Si j'ai bien compris le fonctionnement de Github, ça va créer des liens automatiques entre les messages de commits et les tickets Github
La convention tient en une seule ligne, ce qui nous garantit qu'elle sera comprise par tous et devrait être appliquée. Et du coup, si quelqu'un ne la suit pas, on pourra l'engueuler en disant "tu n'as pas lu la ligne de convention de message de commits".

Alex-D commented 10 years ago

fix : #<id_ticket> <description>
refato : (#<id_ticket>) <description>

Serait une solution viable et à mi chemin entre les deux propositions :)

GerardPaligot commented 10 years ago

Si j'ai bien compris le fonctionnement de Github, ça va créer des liens automatiques entre les messages de commits et les tickets Github

Oui et c'est vraiment génial. On peut donc enrichir les tickets et avoir un historique convenable sur la plateforme GitHub. Si la convention que j'avais appliqué convient à tout le monde, je ne suis pas contre.

La convention tient en une seule ligne, ce qui nous garantit qu'elle sera comprise par tous et devrait être appliquée. Et du coup, si quelqu'un ne la suit pas, on pourra l'engueuler en disant "tu n'as pas lu la ligne de convention de message de commits".

C'est présenté bizarrement mais l'idée est là. :)

@Alex-D: Je sais par expérience que c'est difficile d'indiquer convenablement le type d'un commit. Selon les contributeurs, certains commits toutes les 3 lignes et d'autres après 40 modifications dans 40 fichiers différents. Il faut donc éduquer les contributeurs pour trouver le juste milieu et c'est pas gagné. :)

firm1 commented 10 years ago

Les conventions c'est bien, mais pour un projet pareil vu les contributeurs actuel, je pense que la documentation de la convention ne devrait pas aller au delà de 5 liste a puces et devrait énoncer tous les cas possibles a rencontrer.

Parce que bon, je me vois mal refuser une PR parce que le mec a pas respecter une obscure convention de commit. Le 19 mai 2014 22:46, "Gerard" notifications@github.com a écrit :

Si j'ai bien compris le fonctionnement de Github, ça va créer des liens automatiques entre les messages de commits et les tickets Github

Oui et c'est vraiment génial. On peut donc enrichir les tickets et avoir un historique convenable sur la plateforme GitHub. Si la convention que j'avais appliqué convient à tout le monde, je ne suis pas contre.

La convention tient en une seule ligne, ce qui nous garantit qu'elle sera comprise par tous et devrait être appliquée. Et du coup, si quelqu'un ne la suit pas, on pourra l'engueuler en disant "tu n'as pas lu la ligne de convention de message de commits".

C'est présenté bizarrement mais l'idée est là. :)

@Alex-D https://github.com/Alex-D: Je sais par expérience que c'est difficile d'indiquer convenablement le type d'un commit. Selon les contributeurs, certains commits toutes les 3 lignes et d'autres après 40 modifications dans 40 fichiers différents. Il faut donc éduquer les contributeurs pour trouver le juste milieu et c'est pas gagné. :)

— Reply to this email directly or view it on GitHubhttps://github.com/Taluu/ZesteDeSavoir/issues/568#issuecomment-43555799 .

GerardPaligot commented 10 years ago

J'ai ouvert cette discussion pour en définir une simple justement. :)

cgabard commented 10 years ago

Bref, quelqu'un de motivé pour bosser sur une proposition qui tient en 5 lignes ?

Je précise que git recomande que le message du commit soit architecturé ainsi :

Une premiere ligne de de moins de 50 caractère qui résume le but du commit
une ligne blanche
le reste du message "wrappé" à 72 caractères

Ce serait bien qu'on respecte ça car beaucoup d'outils utilisent cette référence pour l'affichage.

Pour le reste, il nous faut quelques détails sur comment doit être rédigé le reste du contenu.

Alex-D commented 10 years ago

Personnellement, j'aime bien les préfixes. Du coup je propose :

Chaque commit doit indiquer en préfixe sa nature (fix, feat, refacto, style, ... pareil que AngularJS)
Un commit ne doit répondre volontairement qu'à une issue à la fois et la référencer avec #numeroissue juste après le préfixe
La description doit être claire et concise, la première ligne devant faire moins de 50 caractères
Après une ligne vide, vous pouvez apporter plus de précision au commit si nécessaire (72 chars max)

Viens ensuite la question de l'anglais / français. Est-ce utile de causer anglais alors que nous sommes tous francophones, tout en sachant que le projet est quand même open source ?

Exemples : fix #435 : RSS URLs in generated feeds feat #675 : Add box to choose font-size & family perf : Remove some useless requests in forum

Perso, ça me semble pas trop mal.

SpaceFox commented 10 years ago

Moi j'aime pas les préfixes. Tu ne sais jamais ce qu'il faut mettre, personne ne va prendre la peine de lire la liste, on va avoir des fautes de frappe, des incohérences, etc. Si le message de commit est clair, l'information est en doublon. Au final, ça peut être pratique si tu génères ton changelog automatiquement, mais ce n'est pas le cas.

Donc je propose :

Le message de commit est de la forme #id_ticket description + description si nécessaire)
Le message respecte la convention Git (1ère ligne de 50 caractères max, description après une ligne blanche, wrappée à 72 caractères)
Un seul ticket par commit

Le 20 mai 2014 09:49, DEMODE Alexandre notifications@github.com a écrit :

Personnellement, j'aime bien les préfixes. Du coup je propose :

Chaque commit doit indiquer en préfixe sa nature (fix, feat, refacto, style, ... pareil que AngularJS)

Un commit ne doit répondre volontairement qu'à une issue à la fois et la référencer avec #numeroissue juste après le préfixe

La description doit être claire et concise, la première ligne devant faire moins de 50 caractères

Après une ligne vide, vous pouvez apporter plus de précision au commit si nécessaire (72 chars max)

Viens ensuite la question de l'anglais / français. Est-ce utile de causer anglais alors que nous sommes tous francophones, tout en sachant que le projet est quand même open source ?

Exemples : fix #435 : RSS URLs in generated feeds feat #675 : Add box to choose font-size & family perf : Remove some useless requests in forum

Perso, ça me semble pas trop mal.

— Reply to this email directly or view it on GitHubhttps://github.com/Taluu/ZesteDeSavoir/issues/568#issuecomment-43595731 .

Alex-D commented 10 years ago

Je ne pige pas le description + description si nécessaire pour moi la description est obligatoire donc il n'y a pas de "si nécessaire", une faute de frappe peut-être ?

Retirons donc les préfixes, j'aimais bien, peut-être parce que je suis un robot :D

SpaceFox commented 10 years ago

Ha oui pardon, il faut lire :

Le message de commit est de la forme #id_ticket description + commentaires si nécessaire)

Le 20 mai 2014 10:02, DEMODE Alexandre notifications@github.com a écrit :

Je ne pige pas le description + description si nécessaire pour moi la description est obligatoire donc il n'y a pas de "si nécessaire", une faute de frappe peut-être ?

Retirons donc les préfixes, j'aimais bien, peut-être parce que je suis un robot :D

— Reply to this email directly or view it on GitHubhttps://github.com/Taluu/ZesteDeSavoir/issues/568#issuecomment-43596795 .

Eskimon commented 10 years ago

Pour le reste, il nous faut quelques détails sur comment doit être rédigé le reste du contenu.

Le probleme depend aussi de comment les gens bossent (ca a ete dit autre part mais je ne retrouve plus...). Entre les gens qui font des commit super atomic et les autres qui modifie 3 fichiers et 2 fonctions avant de faire un commit c'est delicat...

Perso je suis partisan de la solution d'alex:

fix : #

En tout cas c'est ce que je m'efforce d'appliquer pour linker les choses joliment avec le GH

Apres plusieurs questions:

Est-ce que tout les commits doivent être lie a un ticket (bug/evolution) ?
Anglais ou Francais ou les deux ?

Alex-D commented 10 years ago

HS : C'est étrange, mais Github n'a pas l'air de parser le MD envoyé depuis les courriels...

En somme.

Un seul ticket par commit
Format du commit respectant la norme suivante

(#id_ticket) message, la ligne faisant 50 caractères maximum
<ligne vide>
(description longue si nécessaire, wrappée à 72 caractères)

Alex-D commented 10 years ago

Mon point de vue est

linké à une issue, s'il y répond (c'est pour ça que c'est entre parenthèses dans mon message ci-dessus) ;
anglais only, ça me semble bien, mais faut être prêt à voir passer des carnages.

Le préfixe, finalement peu importe que ce soit fix : #truc message ou Fix de l'issue #machin ça link quand même.

SpaceFox commented 10 years ago

Est-ce que tout les commits doivent être lie a un ticket (bug/evolution) ?

Pour moi oui : si tu as besoin de corriger un truc qui n'est pas dans un ticket c'est que tu dois créer le ticket d'abord. C'est d'ailleurs ce qui permet de garder des messages de commit simples : si tu veux vraiment des détails, ils sont dans le ticket.

Une exception : pour les trucs vraiment complètement évidents (genre, correction d'une faute de frappe dans un texte).

Le 20 mai 2014 10:13, DEMODE Alexandre notifications@github.com a écrit :

Mon point de vue est

linké à une issue, s'il y répond (c'est pour ça que c'est entre parenthèses dans mon message ci-dessus) ;

anglais only, ça me semble bien, mais faut être prêt à voir passer des carnages.

Le préfixe, finalement peu importe que ce soit fix : #truc message ou Fix de l'issue #machin ça link quand même.

— Reply to this email directly or view it on GitHubhttps://github.com/Taluu/ZesteDeSavoir/issues/568#issuecomment-43597668 .

cgabard commented 10 years ago

Une exception : pour les trucs vraiment complètement évidents (genre, correction d'une faute de frappe dans un texte).

Et encore, suffit de faire un ticket générique "correction des erreurs dans le texte" et tous les commits liés peuvent le référencer, sans le fermer

GerardPaligot commented 10 years ago

Si nous récapitulons :

La convention serait :

#<id> <message> # 50 caractères maximum
<BLANK LINE>
<description> # 72 caractères maximum

La liaison a un ticket par l'identifiant est obligatoire. Si le ticket n'existe pas, il faut le créer.
Un commit ne peut concerner qu'un seul ticket.
Au minimum, le contributeur doit respecter la première ligne de la convention.
Les commits doivent être écrit en anglais.

Tout le monde ok ?

Alex-D commented 10 years ago

Va pour ça.

Eskimon commented 10 years ago

J'aurais aime émettre une réserve sur l'anglais, mais je suppose qu'on peut considérer que les gens capable de faire des commits / PR sont un minimum technique / qualifie et donc parle anglais...

Alex-D commented 10 years ago

Ca devrait pas être trop ouf de dire "#truc Fix encoding" ou "Fix requests on forum topic"

Ce que j'ai écris là est peut-être même faux, mais compréhensible, du coup on s'en fou.

geoffreyc commented 10 years ago

Je suis le premier a être partisan de l'anglais, mais en l’occurrence la, pour un projet francais qui a aucune vocation a être internationalisé, je vois pas l’intérêt. On va juste ce retrouver avec des commits pas tres compréhensible, tout le monde ne parlant pas anglais au meme niveau.

2014-05-20 9:46 GMT+01:00 Eskimon notifications@github.com:

J'aurais aime émettre une réserve sur l'anglais, mais je suppose qu'on peut considérer que les gens capable de faire des commits / PR sont un minimum technique / qualifie et donc parle anglais...

— Reply to this email directly or view it on GitHubhttps://github.com/Taluu/ZesteDeSavoir/issues/568#issuecomment-43600543 .

GerardPaligot commented 10 years ago

Tout le code du projet étant déjà en anglais, je ne vois pas le problème.

Alex-D commented 10 years ago

Donc on part sur du franglish en somme ?

Car "#truc Correction des requêtes sur les sujets du forum" VS "#truc Fix requests on forum topic" y a pas photo...

Eskimon commented 10 years ago

Perso l'anglais me gene pas un, mais je trouve juste bien bizarre d'avoir des commits en anglais et des discussions lies a ces deniers en francais...

SpaceFox commented 10 years ago

Les messages de commits je m'en fous, mais pitié pas les discussions en anglais. Déjà qu'en français on a du mal à se comprendre...

Le 20 mai 2014 10:54, Eskimon notifications@github.com a écrit :

Perso l'anglais me gene pas un, mais je trouve juste bien bizarre d'avoir des commits en anglais et des discussions lies a ces deniers en francais...

— Reply to this email directly or view it on GitHubhttps://github.com/Taluu/ZesteDeSavoir/issues/568#issuecomment-43601213 .

Alex-D commented 10 years ago

On n'écrit pas "un" mais "hein" (à bien prononcer d'ailleurs). Merci <3

Perso je trouve que les discussions liées ne sont pas == au dépôt git. Du coup ça ne me dérange pas. Il y a d'un côté le développement et de l'autre le meta-développement. Et pour moi, si d'un côté on préférera avoir tout en anglais pour une histoire d’uniformisation, de l'autre on préférera parler français car ce sera un canal de communication rapide et plus compréhensible par nous, francophones.

Eskimon commented 10 years ago

On n'écrit pas "un" mais "hein" (à bien prononcer d'ailleurs). Merci <3

Tain' le café qui fait pas effet quoi ! (Et tant qu'on parle d'orthographe, désolé pour tout les accents massacres, j'essaie de faire gaffe mais le clavier qwerty c'est pas terrible pour ça...)

Par contre du coup avec ton argumentaire comme ça je suis tout a fait d'accord :)

GerardPaligot commented 10 years ago

On n'écrit pas "discutions" mais "discussions" (à bien prononcer d'ailleurs). Merci <3

+1 Alex. Puis, quand je commit, je référence souvent du code (class, méthodes, attributs, etc). Si on commit en français, j'aurais un mélange d'anglais et de français. Ca ne va juste pas. Donc les discussions en français, le reste en anglais (ça serait bien de switcher la documentation en anglais d'ailleurs).

SpaceFox commented 10 years ago

ça serait bien de switcher la documentation en anglais d'ailleurs

Honnêtement, je n'en vois pas l'intérêt. Peut-être si un jour on veut accueillir des gens non-francophones, mais d'ici là...

Le 20 mai 2014 10:58, Gerard notifications@github.com a écrit :

On n'écrit pas "discutions" mais "discussions" (à bien prononcer d'ailleurs). Merci <3

+1 Alex. Puis, quand je commit, je référence souvent du code (class, méthodes, attributs, etc). Si on commit en français, j'aurais un mélange d'anglais et de français. Ca ne va juste pas. Donc les discussions en français, le reste en anglais (ça serait bien de switcher la documentation en anglais d'ailleurs).

— Reply to this email directly or view it on GitHubhttps://github.com/Taluu/ZesteDeSavoir/issues/568#issuecomment-43601621 .

cgabard commented 10 years ago

Au passage, pour la limite de 72 caractère de git, c'etait pour le "wrapping" (je ne connais pas le mot français) : tu peux faire autant de lignes que tu veux mais chaque ligne physique ne doit pas faire plus de 72 caractères de long. Un peu comme la limie de 80 caractères pour le code. Rien n'empeche de faire 10 lignes de 72 caractères.

cgabard commented 10 years ago

La doc en anglais, sincèrement, tant qu'on a encore des chaines en français en dur dans le code, ça ne sert pas à grand chose... Le projet n'est pour le moment clairement pas destiné a etre utilisé par des anglophones.

GerardPaligot commented 10 years ago

@SpaceFox: Quand on ouvre le code, on ne permet pas à des contributeurs non-francophones de contribuer ?

geoffreyc commented 10 years ago

Tant que les messages de commits de se transforme pas en anglais de primaire, apres moi ca me va.

On Tue, May 20, 2014 at 10:07 AM, Gerard notifications@github.com wrote:

@SpaceFox https://github.com/SpaceFox: Quand on ouvre le code, on ne permet pas à des contributeurs non-francophones de contribuer ?

— Reply to this email directly or view it on GitHubhttps://github.com/Taluu/ZesteDeSavoir/issues/568#issuecomment-43602376 .

Eskimon commented 10 years ago

@SpaceFox: Quand on ouvre le code, on ne permet pas à des contributeurs non-francophones de contribuer ?

Sur le principe oui mais dans les faits ? Tu penses vraiment qu'un anglophone va venir contribuer a un projet dont il ne peut comprendre les discussions ? D'ailleurs a ce sujet, si les commits sont en anglais dans quel lange sont les tickets ? Il y avait une conclusion la dessus ?

cgabard commented 10 years ago

Le fait est qu'actuellement, un non-francophone, a supposer qu'il prenne connaissant du projet, ne pourrat pas suivre grand chose :

Il y a des chaines en français en dur dans le code
La doc est en français
Les tickets sont en français
L'utilisation principale du projet est un site en français
La pré-prod pour les tests est un site en français.

Je n'ai rien contre ouvrir aux non-francophone mais force est de constater que l'on a rien de prévu pour

GerardPaligot commented 10 years ago

On va dire que c'est pré-maturé de retravailler la documentation pour la rédiger en anglais.

SpaceFox commented 10 years ago

@SpaceFox https://github.com/SpaceFox: Quand on ouvre le code, on ne permet pas à des contributeurs non-francophones de contribuer ?

En théorie, si. Mais le pragmatisme me fait dire qu'on se posera la question quand le cas se présentera. Aujourd'hui on a un code francophone pour un site francophone, même pas ouvert au public, avec du français dans tous les coins. D'autant plus que pour l'instant, on a beaucoup d'autres trucs à faire avant de traduire notre doc.

2014-05-20 11:19 GMT+02:00 Gerard notifications@github.com:

On va dire que c'est pré-maturé de retravailler la documentation pour la rédiger en anglais.

— Reply to this email directly or view it on GitHubhttps://github.com/Taluu/ZesteDeSavoir/issues/568#issuecomment-43603461 .

firm1 commented 10 years ago

S'il faut faire des conventions, je pense qu'il n'y a même pas matière à discuter sur le cas de la langue des commits. Tout es en français, point barre. On avisera le jour ou on internationalisera le code, et quelque chose même dis que ce sera pas avant quelques années.

Le code est en anglais c'est le principal, pour les commits, je n'arrive même pas à imaginer quelqu'un parcourir un historique d'environ 1000 commits à part pour se dire : "wow, il sont beau mes commits".

Taluu commented 10 years ago

Autant je suis pour les commits en anglais, et le wrapping (première ligne à 50 caractères, qui résume le bordel, puis plus de détails si on veut), mais forcément indiquer un ticket, ça non. Tout comme l'histoire des préfixes en fait.

Imaginons, on développe une nouvelle feature, dans une PR... On va pas se faire chier à créer un ticket ou le référencer à chaque fois. L'historique de git nous dira "tiens ca fait parti de cette branche, associé à cette PR ; cette PR fait référence à ce ticket" (et encore, c'est pour les nazis qui veulent regarder l'historique git...)

Alex-D commented 10 years ago

Point Godwin Merci @Taluu

L'issue obligatoire si elle existe dirons-nous :)

GerardPaligot commented 10 years ago

S'il faut faire des conventions, je pense qu'il n'y a même pas matière à discuter sur le cas de la langue des commits. Tout es en français, point barre.

Cette issue est là pour en discuter, pas pour imposer les choses. :)

Sinon, je ne comprends pas bien votre point de vue. Le code source du projet est en anglais, vous ne référencez jamais du code dans vos messages de commits ? Pour moi, si le code est en anglais, les commits doivent l'être aussi.

@Taluu: Les préfixes ne sont pas retenus dans la convention pour le moment. Par contre, une issue associée à un commit, ça me semble vraiment utile. Je ne comprends pas trop ton avis sur ce point.

Taluu commented 10 years ago

Parce que puisqu'on va fonctionner avec des PR, le titre des PR est suffisant pour indiquer à l'issue (si elle existe) qu'on est en train de la traiter / qu'il y a un avancement dessus. Je pense qu'il est plus judicieux d'avoir un point d'entrée plutôt que N > 1.

Et lors du merge de la PR, on aura une référence comme quoi elle est fixée. Pour les nouvelles features par exemple, je doute qu'on fera systématiquement un ticket pour en discuter (la PR servira de lieu de discussion dans ce cas, au final), d'où la possible absence de n° de ticket dans les commits.

Ce que je dis donc, c'est de ne pas obliger à référencer systématiquement un n° de ticket... Mais par contre obliger à référencer le n° de ticket (s'il y en a un) dans la PR.

cgabard commented 10 years ago

Je suis assez d'accord. Si ce que tu as a faire (fix ou feature) est gros, je vois mal l'interet de référencer le ticket a chaque fois.

Par ex @GerardPaligot , pour ta branche API, tous les tickets que tu fais ont ou auront le numéro du ticket dans le titre du commit ?

N'est ce pas suffisant que la PR, et donc le commit de merge de branche, le contienne ?

GerardPaligot commented 10 years ago

Oui, pour ma branche API je référence à chaque fois l'issue #471 (et ce depuis quasiment le début de mes contributions pour le projet). Du coup, dans le temps et entre les messages éventuellement postés dans l'issue, on peut y voir mes commits et y accéder directement. C'est un mécanisme automatique dans GitHub qui nécessite, comme seul effort lors de la rédaction du commit, simplement référencer l'identifier de l'issue. Tout le reste se fait automatiquement. Chose qu'il n'est pas possible de faire (à ma connaissance) avec l'identifiant dans le nom du PR.

Alex-D commented 10 years ago

Sur Github, tu peux créer une PR et elle aura un id aussi. Et aura le même comportement qu'une issue.

firm1 commented 10 years ago

Chose qu'il n'est pas possible de faire (à ma connaissance) avec l'identifiant dans le nom du PR.

@Taluu vient de le dire, c'est possible de le faire dans la description de la PR. un peu comme ici

SpaceFox commented 10 years ago

Le code source du projet est en anglais, vous ne référencez jamais du code dans vos messages de commits ?

Absolument jamais. En fait c'est pire que ça : je ne vois pas pourquoi j'en viendrais à mettre du code dans mon message de commit.

Sinon, j'avais oublié les implications du fonctionnement en PR (je reste un noob en Git) et du coup, je suis plutôt d'accord avec Baptiste et Christophe : si on peut mettre la référence à l'issue dans la PR (ça marche au moins dans le commentaire de la PR), pas besoin de se faire chier à le remettre dans chaque commit.

Le 20 mai 2014 13:35, Gerard notifications@github.com a écrit :

Oui, pour ma branche API je référence à chaque fois l'issue #471https://github.com/Taluu/ZesteDeSavoir/issues/471(et ce depuis quasiment le début de mes contributions pour le projet). Du coup, dans le temps et entre les messages éventuellement postés dans l'issue, on peut y voir mes commits et y accéder directement. C'est un mécanisme automatique dans GitHub qui nécessite, comme seul effort lors de la rédaction du commit, simplement référencer l'identifier de l'issue. Tout le reste se fait automatiquement. Chose qu'il n'est pas possible de faire (à ma connaissance) avec l'identifiant dans le nom du PR.

— Reply to this email directly or view it on GitHubhttps://github.com/Taluu/ZesteDeSavoir/issues/568#issuecomment-43614440 .

Eskimon commented 10 years ago

Pourtant ça fait joli et organisé de voir les commits dans une discussion (comme on peut le voir sur l'exemple très juste de @GerardPaligot et l'API)

zestedesavoir / zds-site

Convention dans les messages de commits #568