Ici on a un gitlab, des merge requests qui conservent l'historique, et des intégrateurs qui font leur travail pour vérifier que le code est bien écrit, commenté et documenté. Sinon, il n'est pas intégré.
Il faut peut-être aller expliquer leur travail à vos intégrateurs.
On a déjà bien assez de dette technique comme ça, on a tout intérêt à ce que au moins le code qu'on écrit soit propre. On est prestataires (grosse équipe, une quarantaine de personnes sur différents projets) et le dépôt git est évidemment synchronisé chez le client toutes les nuits, de façon à ce qu'il aie accès à l'historique (sauf les branches "internes" qui restent chez nous avec les devs en cours pas encore livrés). Si vos prestataires vous envoie le code en vrac par mail et sans contrôle de sources, vous avez là aussi un problème.
On ne développe pas de code sur nos propres machines, mais sur un serveur partagé avec un environnement de travail maîtrisé. Ce qui fait que formater un PC n'est jamais un problème, et aussi qui permet au client de savoir exactement dans quelle configuration on travaille et de reproduire l'environnement chez lui si nécessaire.
Pour les commits, on ne garde pas tout, l'idée est que le développeur fait son développement et prend le temps de découper ça en commits "atomiques" apportant chacun une fonctionnalité précise, et étant fonctionnel et indépendant des commits suivants. Gitlab ni Github ne mettent pas vraiment cette façon de travailler, si j'avais le choix je pencherais plutôt pour un outil comme Gerrit, qui permet de faire une revue de code en travaillant sur un commit à la fois.
Mais de toutes façons, les développements sont découpés en tâches qui peuvent être complétées en quelques jours, au pire une à deux semaines si vraiment ça se passe mal. Les revues et intégrations sont donc très fréquentes et concernent peu de commits à la fois. Les commits de développement sont au nom de l'auteur, le commit d'intégration au nom du relecteur/intégrateur. Tout est donc tracé.
L'historique git est un outil précieux pour comprendre le fonctionnement du code, et s'il est bien tenu, souvent plus efficace que des commentaires ou de la documentation d'architecture.
[^] # Re: Tiens, à propos, comment-vous gérez vos repos, vous ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Remonter l'historique du noyau avec git depuis le début. Évalué à 8.
Ici on a un gitlab, des merge requests qui conservent l'historique, et des intégrateurs qui font leur travail pour vérifier que le code est bien écrit, commenté et documenté. Sinon, il n'est pas intégré.
Il faut peut-être aller expliquer leur travail à vos intégrateurs.
On a déjà bien assez de dette technique comme ça, on a tout intérêt à ce que au moins le code qu'on écrit soit propre. On est prestataires (grosse équipe, une quarantaine de personnes sur différents projets) et le dépôt git est évidemment synchronisé chez le client toutes les nuits, de façon à ce qu'il aie accès à l'historique (sauf les branches "internes" qui restent chez nous avec les devs en cours pas encore livrés). Si vos prestataires vous envoie le code en vrac par mail et sans contrôle de sources, vous avez là aussi un problème.
On ne développe pas de code sur nos propres machines, mais sur un serveur partagé avec un environnement de travail maîtrisé. Ce qui fait que formater un PC n'est jamais un problème, et aussi qui permet au client de savoir exactement dans quelle configuration on travaille et de reproduire l'environnement chez lui si nécessaire.
Pour les commits, on ne garde pas tout, l'idée est que le développeur fait son développement et prend le temps de découper ça en commits "atomiques" apportant chacun une fonctionnalité précise, et étant fonctionnel et indépendant des commits suivants. Gitlab ni Github ne mettent pas vraiment cette façon de travailler, si j'avais le choix je pencherais plutôt pour un outil comme Gerrit, qui permet de faire une revue de code en travaillant sur un commit à la fois.
Mais de toutes façons, les développements sont découpés en tâches qui peuvent être complétées en quelques jours, au pire une à deux semaines si vraiment ça se passe mal. Les revues et intégrations sont donc très fréquentes et concernent peu de commits à la fois. Les commits de développement sont au nom de l'auteur, le commit d'intégration au nom du relecteur/intégrateur. Tout est donc tracé.
L'historique git est un outil précieux pour comprendre le fonctionnement du code, et s'il est bien tenu, souvent plus efficace que des commentaires ou de la documentation d'architecture.