Dans le développement du noyau, le rôle de l'intégrateur (ou mainteneur officiel) est clair : il reçoit les patchs, il les relit, les valide (ou non) et alors seulement ça rentre dans son repo git. C'est lui que git affiche, et si l'intégrateur a bien fait son travail, il montre l'auteur original dans le log du commit.
C'est plutôt logique : le "coupable" en cas de commit foireux est d'abord l'intégrateur qui a accepté le code, qui se retourne ensuite vers l'auteur original si besoin.
Perso, je vois ça comme une limite de la plupart des gestionnaires de configuration, mais ce n'est pas mon sujet du jour.
Maintenant, regardons comment git est (parfois) utilisé dans les grosses entreprises. Vous avez des équipes, chacune travaille sur un projet, composées de plusieurs développeurs, et en général un intégrateur. Les développeurs travaillent sur leur propre branche, et quand ils sont contents, ils envoient le tout à l'intégrateur, qui merge dans la branche principale. En général, c'est moins rigoureux que pour le noyau, et le log du commit fait référence uniquement à la fiche Jira/Bugzilla/... Et vous n'avez que la version finale du code. L'intégrateur est juste là pour faire le taf d'intégration, il ne comprend pas grand chose au code, et par ailleurs il s'en fout.
Avec un peu de malchance, la branche qui avait servi au développement a été supprimée pour gratter de la place (ou était uniquement sur le poste local du développeur, un presta qui a depuis fini sa mission ; le poste a donc été reformaté).
Du coup, vous avez juste :
- le commit qui dit "merge de la fiche XXX-1234 dans le tronc principal"
- votre bug tracker qui indique le nom de la personne assignée au bug, mais sans certitude que ce soit bien elle qui ait produit le code
- perdu le détail des itérations du code
Et là, vous avez un doute. Ce qui semble être un bug à la lecture du code (mal commenté) est peut-être volontaire. Le dev a peut-être été obligé d'écrire ça pour contourner autre chose. Après tout, ce damné soft est un cauchemart, le résultat de plusieurs années de retouches successives que personne ne maîtrise plus depuis bien longtemps.
Bref...
En gros, la question c'est :
- est-il préférable d'avoir tout le détail du code dans un arbre unique, avec tous les micro-commits, mais au moins on garde tout, pour toujours, et on peut tout retrouver
- ou est-il préférable de n'avoir que les commits "finaux", quitte à perdre le ou les auteurs intermédiaires et les versions intermédiaires en cas de stratégie de stockage merdique/très contrainte
- ou avez-vous d'autres approches ?
# Tiens, à propos, comment-vous gérez vos repos, vous ?
Posté par Dring . En réponse au journal Remonter l'historique du noyau avec git depuis le début. Évalué à 5.
Dans le développement du noyau, le rôle de l'intégrateur (ou mainteneur officiel) est clair : il reçoit les patchs, il les relit, les valide (ou non) et alors seulement ça rentre dans son repo git. C'est lui que git affiche, et si l'intégrateur a bien fait son travail, il montre l'auteur original dans le log du commit.
C'est plutôt logique : le "coupable" en cas de commit foireux est d'abord l'intégrateur qui a accepté le code, qui se retourne ensuite vers l'auteur original si besoin.
Perso, je vois ça comme une limite de la plupart des gestionnaires de configuration, mais ce n'est pas mon sujet du jour.
Maintenant, regardons comment git est (parfois) utilisé dans les grosses entreprises. Vous avez des équipes, chacune travaille sur un projet, composées de plusieurs développeurs, et en général un intégrateur. Les développeurs travaillent sur leur propre branche, et quand ils sont contents, ils envoient le tout à l'intégrateur, qui merge dans la branche principale. En général, c'est moins rigoureux que pour le noyau, et le log du commit fait référence uniquement à la fiche Jira/Bugzilla/... Et vous n'avez que la version finale du code. L'intégrateur est juste là pour faire le taf d'intégration, il ne comprend pas grand chose au code, et par ailleurs il s'en fout.
Avec un peu de malchance, la branche qui avait servi au développement a été supprimée pour gratter de la place (ou était uniquement sur le poste local du développeur, un presta qui a depuis fini sa mission ; le poste a donc été reformaté).
Du coup, vous avez juste :
- le commit qui dit "merge de la fiche XXX-1234 dans le tronc principal"
- votre bug tracker qui indique le nom de la personne assignée au bug, mais sans certitude que ce soit bien elle qui ait produit le code
- perdu le détail des itérations du code
Et là, vous avez un doute. Ce qui semble être un bug à la lecture du code (mal commenté) est peut-être volontaire. Le dev a peut-être été obligé d'écrire ça pour contourner autre chose. Après tout, ce damné soft est un cauchemart, le résultat de plusieurs années de retouches successives que personne ne maîtrise plus depuis bien longtemps.
Bref...
En gros, la question c'est :
- est-il préférable d'avoir tout le détail du code dans un arbre unique, avec tous les micro-commits, mais au moins on garde tout, pour toujours, et on peut tout retrouver
- ou est-il préférable de n'avoir que les commits "finaux", quitte à perdre le ou les auteurs intermédiaires et les versions intermédiaires en cas de stratégie de stockage merdique/très contrainte
- ou avez-vous d'autres approches ?