Ou peut-être qu'une fois qu'on a publié sur une branche de feature/prototype/... partagée il est compliqué de réécrire l'historique et le repusher sans péter la conf de autres.
Avec un peu d'organisation, cela peut être fait. Au moins juste avant de merger...
Cela a t'il réellement un intérêt de suivre l'historique au niveau du patchset lorsque le gestionnaire de ticket fait correctement son boulot au niveau du ticket et reférence les commits asssociés.
Je pense légèrement différemment...
Pour moi, ton gestionnaire de code source doit presque (et le plus possible) se suffire à lui même.
Déjà, git est un DVCS. Donc comment tu fais pour consulter ton gestionnaire de ticket si t'es pas forcement connecté?
En plus, cela peut rendre fortement dépendant d'un gestionnaire de ticket si t'as pas bien prévu ton truc (il faut pouvoir exporter les données, le réimporter avec les même identifiants,...). Rien que si tu as fait un projet sur github, c'est pas évident.
Alors que si tu fais des beaux messages de commits (avec potentiellement des bouts de texte pris du gestionnaire de ticket), déjà tu risques de gagner du temps en évitant d'avoir à ouvrir un autre outils dans la majorité des cas, en plus tu es un peu plus indépendant (l'indispensable est dans le contrôleur de code source),...
Là où je bosse, on utilise quasiment jamais le gestionnaire de ticket lors de la recherche d'un bug dans l'historique. Si le message de commit est pas assez clair, soit on lit le code source. Si on va dans le gestionnaire de ticket, c'est qu'on a merdé notre historique.
[^] # Re: Pourquoi ?
Posté par cosmocat . En réponse au journal Git workflow, rebase, conflits et rôle d'intégrateur. Évalué à 4.
Avec un peu d'organisation, cela peut être fait. Au moins juste avant de merger...
Je pense légèrement différemment...
Pour moi, ton gestionnaire de code source doit presque (et le plus possible) se suffire à lui même.
Déjà, git est un DVCS. Donc comment tu fais pour consulter ton gestionnaire de ticket si t'es pas forcement connecté?
En plus, cela peut rendre fortement dépendant d'un gestionnaire de ticket si t'as pas bien prévu ton truc (il faut pouvoir exporter les données, le réimporter avec les même identifiants,...). Rien que si tu as fait un projet sur github, c'est pas évident.
Alors que si tu fais des beaux messages de commits (avec potentiellement des bouts de texte pris du gestionnaire de ticket), déjà tu risques de gagner du temps en évitant d'avoir à ouvrir un autre outils dans la majorité des cas, en plus tu es un peu plus indépendant (l'indispensable est dans le contrôleur de code source),...
Là où je bosse, on utilise quasiment jamais le gestionnaire de ticket lors de la recherche d'un bug dans l'historique. Si le message de commit est pas assez clair, soit on lit le code source. Si on va dans le gestionnaire de ticket, c'est qu'on a merdé notre historique.