Discussion :

[boboss123]

Bonjour,

On me demande d'auditer un dépôt GIT de référence (origin) d'un projet.

Je dois vérifier les points suivants :
- Un ensemble de modification de code permettant une évolution doit être réalisé sur une branche de feature nommée avec une référence de fonctionnalité.
- L’entête d’un fichier ajouté au projet doit contenir un commentaire permettant de savoir l’usage prévu du fichier.
- Un fichier commité doit avoir été modifié pour réaliser une évolution.
- Un fichier commité ne doit pas contenir de code ajouté inutilisé (code mort).


Pour le moment, je sais :
- identifier le hash du commit d'une branche : git log -n 1.
- identifier le hash du commit lié à un tag : git rev-list -n 1 <nom_du_tag>.
- voir les noms de fichiers qui ont été modifiés entre deux commits : git diff --name-only <commit_old> <commit_new>.
- liste les commits liés à un fichier : git log -- <chemin-du-fichier>.

Je ne sais pas trop comment faire ça : avez-vous des pistes ?
... par exemple, je sais répérer les hash de tous les commit d'un fichier qui a été modifié mais je ne sais pas dans quelle branche ça a été fait.

Structure du projet :
- Une branche /master où l'on de commit que les versions livrées (donc chaque commit de cette branche est aussi tagué)
- Une dev qui liste touts les commits de la branche en cours /dev. Cette branche est mergée dans /master lorsque d'une version de programme est prête à être livrée.
- Des branches feature/x issues de /dev qui liste les commits d'une fonction en particulier. Ces branches sont mergées exclusivement dans /dev lorsque la fonction a été développé (le nom des ces branches ne sont jamais supprimés... c'est une obligation que je dois suivre).

Merci d'avance

[Obsidian]

Bonjour,

Pour le moment, je sais :
- identifier le hash du commit d'une branche : git log -n 1.
- identifier le hash du commit lié à un tag : git rev-list -n 1 <nom_du_tag>.

Tu peux faire plus court en utilisant directement git show <branche ou tag ou n'importe quel ref>.

Il faut se souvenir que sous Git, l'historique est formé par les références successives de chaque commit à son ou ses parents, comme une liste chaînée (mais avec des branches, ce qui en fait un graphe). Les branches et les tags sont donc simplement des références qui « pointent » l'emplacement ou le sommet de la branche en contenant tout simplement le hash de la révision concernée, comme le ferait un lien symbolique. Tu peux d'ailleurs les voir physiquement sous .git/refs.

- voir les noms de fichiers qui ont été modifiés entre deux commits : git diff --name-only <commit_old> <commit_new>.

Si tu utilises --name-only, tu ne verras effectivement que les noms de fichiers mais si tu lances la même commande sans cette option, tu verras l'intégralité des différences entre les deux commits, tous fichiers confondus, même si les révisions n'ont rien à voir entre elles ou sont très lointaines. C'est un des points forts de Git de pouvoir faire cela aussi rapidement.

Je ne sais pas trop comment faire ça : avez-vous des pistes ?
... par exemple, je sais répérer les hash de tous les commit d'un fichier qui a été modifié mais je ne sais pas dans quelle branche ça a été fait.

Comme indiqué plus haut, une branche est formé par ses commits successifs et remontent forcément vers le « passé ». Donc si tu veux savoir sur quelle branche cela a été fait, il suffit de lancer git log sur le nom de la branche elle-même. En remontant, tu vas effectivement retrouver tous les commits en question mais il se peut qu'à un certain moment, tu retombes sur un tronçon qui soit commun à plusieurs branches, justement parce qu'ils se trouvent avant le point où les différentes branches ont bifurqué.

A contrario, si tu fais git log <nom de fichier>, tu ne récupéreras pas les modifications qui ont été portées à ton fichier si celles si ne sont pas accessibles depuis le point où tu appelles la commande.

Souviens-toi également que lorsque tu appelles une commande sans référence à une révision là où elle est censé en attendre une (cas de git log, donc), Git utilise par défaut ta position courante « HEAD », qui correspond à la révision actuellement développée dans ton répertoire de travail (avec git checkout) et à laquelle le prochain commit fera référence si tu enregistres de nouvelles modifications.

Enfin, sache que tu peux généralement passer plusieurs révisions de départ à git log et aux commandes qui parcourent l'historique. Ce qui te permet de remonter plusieurs branches à la fois si nécessaire.

Je te suggère également, dans cette situation, d'utiliser git log --graph dans un premier temps pour voir comment les branches sont articulés entre elles, puis d'utiliser un client dédié comme tig (en ligne de commande sous Linux), gitk (client graphique sous GTK), SourceTree ou l'explorateur natif de VSCode.

Je dois vérifier les points suivants :
- Un ensemble de modification de code permettant une évolution doit être réalisé sur une branche de feature nommée avec une référence de fonctionnalité.

Ce n'est pas très clair. Si tu veux vérifier si une branche portant un nom spécifique existe, git branch suffit. Si tu veux vérifier si le code disponible à une révision donnée contient du matériel attendu, alors il faudra l'examiner directement et cela ne concerne plus Git. Ce que Git peut faire pour toi dans cette situation, en revanche, c'est te permettre de comparer une révision donnée à une révision de référence que tu sais être à jour. Le différentiel ainsi obtenu te permettra de voir rapidement s'il manque certaines choses.

- L’entête d’un fichier ajouté au projet doit contenir un commentaire permettant de savoir l’usage prévu du fichier.

Pas clair non plus : il doit contenir ce commentaire à partir de quel moment ? Si c'est au sommet de la branche courante (dernier commit en date), alors là encore, il suffit de l'examiner directement (avec git show).

- Un fichier commité doit avoir été modifié pour réaliser une évolution.

C'est automatique sous Git parce qu'il fonctionne par comparaison et en établissant le hash du contenu du fichier. Un fichier inchangé ne peut donc jamais être ajouté au prochain commit même par accident, sauf options spéciales prévues pour cela.

- Un fichier commité ne doit pas contenir de code ajouté inutilisé (code mort).

Là encore, Git lui-même ne peut pas le savoir a priori. Il faut faire du profilage de code pour cela. Par contre, pour rechercher où et quand une modification passée inaperçue jusqu'ici a été introduite (provoquant généralement un bug), il existe git bisect pour t'aider à la retrouver facilement.

[boboss123]

Bonjour,

Merci pour les informations.

Je dois vérifier les points suivants :
- Un ensemble de modification de code permettant une évolution doit être réalisé sur une branche de feature nommée avec une référence de fonctionnalité.

Ce n'est pas très clair. Si tu veux vérifier si une branche portant un nom spécifique existe, git branch suffit. Si tu veux vérifier si le code disponible à une révision donnée contient du matériel attendu, alors il faudra l'examiner directement et cela ne concerne plus Git. Ce que Git peut faire pour toi dans cette situation, en revanche, c'est te permettre de comparer une révision donnée à une révision de référence que tu sais être à jour. Le différentiel ainsi obtenu te permettra de voir rapidement s'il manque certaines choses.

Il faut que je vérifie entre deux versions de tag que chaque ajout/modification/suppression de fichier soit commité dans une branche dont le nom contient "/feature/".
Et tous ça uniquement avec les commandes GIT.

Donc je pensais faire le truc comme ça :
1- Identifier tous les noms des fichiers ajoutés/modifiés/supprimés.
2- Identifier pour chacun de ces fichiers la liste des commits.
3- Pour chacun de ces commits, vérifier qu'ils font partie d'une branche dont le nom contient "/feature/" et vérifier que le contenu du commit correspond au nom de la feature. Si ce n'est pas le cas, le commit doit correspondre à un merge de la branche feature vers /dev ou de /dev vers /master.

Je bloque sur le point 3. Si je fais un :

git log --graph <nom_du_fichier>

... je ne vois pas apparaitre le nom de la branche associé à chaque de commit

[boboss123]

- L’entête d’un fichier ajouté au projet doit contenir un commentaire permettant de savoir l’usage prévu du fichier.

Pas clair non plus : il doit contenir ce commentaire à partir de quel moment ? Si c'est au sommet de la branche courante (dernier commit en date), alors là encore, il suffit de l'examiner directement (avec git show).

Entre deux versions de tags, je dois identifier tous les fichiers qui ont été ajoutés puis vérifier pour chacun de ces fichiers qu'ils ont en entête un commentaire décrivant leur usage.

Le problème est que si je fais un "git diff" sans "--name-only", ça m'affiche aussi les modifications et suppression. Et si je laisse "--name-only", ça ne me dis pas si le fichier a été ajouté, modifié ou supprimé.
Il n'y a pas une commit git qui permet de n'afficher que les noms des fichiers ajoutés ?

[Obsidian]

Il faut que je vérifie entre deux versions de tag que chaque ajout/modification/suppression de fichier soit commité dans une branche dont le nom contient "/feature/".
Et tous ça uniquement avec les commandes GIT.

D'accord, mais ces deux tags se trouvent-ils sur une même branche ? Rien ne les y oblige, mais si ce n'est pas le cas, l'approche à suivre risque d'être bien différente.

Donc je pensais faire le truc comme ça :
1- Identifier tous les noms des fichiers ajoutés/modifiés/supprimés.
2- Identifier pour chacun de ces fichiers la liste des commits.
3- Pour chacun de ces commits, vérifier qu'ils font partie d'une branche dont le nom contient "/feature/" et vérifier que le contenu du commit correspond au nom de la feature. Si ce n'est pas le cas, le commit doit correspondre à un merge de la branche feature vers /dev ou de /dev vers /master.

D'accord mais il faut d'abord se souvenir que sous Git, ce sont les commits eux-mêmes qui forment les branches. Plus précisément, chaque commit référence au moins un parent (sauf le commit initial bien sûr) voire plusieurs dans le cas de la fusion de deux branches ou plus. Toutes ces références successives forment un graphe, et les branches vont être matérialisées en plaçant une étiquette au sommet d'un des chemins de ce graphe. Les tags font d'ailleurs exactement la même chose. La seule chose qui va distinguer tags et branches sous Git est le fait que l'étiquette d'une branche est automatiquement mise à jour quand on y pousse de nouveaux commits alors qu'un tag est fait, par nature, pour rester sur le commit sur lequel on l'a placé.

De là, il faut voir de quelle manière chaque feature a été intégrée dans la branche principale. Normalement, c'est avec une fusion de branches (merge) et dans ce cas, tu dois la voir apparaître dans l'historique avec git log --graph ou avec tig. Si en revanche, telle ou telle fonctionnalité a été intégrée avec un cherry-pick, alors dans ce cas, le commit concerné sera en fait un « rejeu » des modifications appliquées par un autre et si l'auteur n'a pas pensé à mettre une référence explicite vers l'original (option -x, notamment), alors rien ne le reliera à lui officiellement.

Je bloque sur le point 3. Si je fais un : git log --graph <nom_du_fichier>

... je ne vois pas apparaitre le nom de la branche associé à chaque de commit

Oui, c'est normal, mais ça appelle là encore une petite explication : comme expliqué plus haut et contrairement à d'autres SCM, sous Git, une branche n'est pas un « container à commits ». C'est une partie du graphe dont on repère le point le plus récent avec une étiquette et que l'on remonte ensuite jusque vers le commit initial. Si une branche « forke » à un moment donné pour donner naissance à une nouvelle branche et continuer à vivre sa vie à côté, un commit peut très bien appartenir à deux branches à la fois s'il fait partie de la partie commune avant la bifurcation.

Cela signifie déjà qu'il faut passer un ou plusieurs noms de branches à git log si l'on veut qu'il les remonte. Sinon, par défaut, il utilisera la position HEAD, c'est-à-dire l'endroit où l'on se trouve au moment de l'appel à la commande. Il y a des chances qu'il s'agisse de la branche master, mais si tu as développé un commit donné avec git checkout sans revenir ensuite au sommet de la branche, ton git log partira de cet endroit.

Tu peux donc déjà écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

git log --graph master

… pour remonter l'intégralité de la branche master. Tu peux ajouter des noms de branches pour les explorer en parallèle jusqu'à ce qu'elles se rejoignent :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

git log --graph master dev

… mais tu peux aussi et surtout spécifier une plage : avec la notation « a..b », tu demandes à récupérer tous les commits accessibles depuis b mais pas depuis a, ce qui revient en fait, si ces commits se trouvent sur une même branche, à récupérer tous les commits déposés sur la branche depuis « a » exclu jusqu'à « b » inclus. Donc, si tu le fais entre deux tags :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

git log --graph tag1..tag2

… et enfin, à ce stade et dans tous les cas, tu peux ajouter des noms de fichiers si tu le souhaites. Ceux-ci agissent comme des filtres : initialement, le parcours est le même mais sur la collection de commits retrouvés, Git ne te présentera ensuite que ceux qui agissent sur au moins un des fichiers spécifiés.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

git log --graph tag1..tag2 <nom de fichier>

Entre deux versions de tags, je dois identifier tous les fichiers qui ont été ajoutés puis vérifier pour chacun de ces fichiers qu'ils ont en entête un commentaire décrivant leur usage.

Le problème est que si je fais un "git diff" sans "--name-only", ça m'affiche aussi les modifications et suppression. Et si je laisse "--name-only", ça ne me dis pas si le fichier a été ajouté, modifié ou supprimé.
Il n'y a pas une commit git qui permet de n'afficher que les noms des fichiers ajoutés ?

Si : tu peux utiliser --name-status à la place de --name-only. Tu obtiendras une lettre en vis-à-vis de chaque nom de fichier t'indiquant le traitement subi. Les plus courantes sont A, M et D, mais la signification complète peut être trouvée dans la man page :

Select only files that are Added (A), Copied (C), Deleted (D), Modified (M), Renamed (R), have their type (i.e. regular file, symlink, submodule, ...) changed (T), are Unmerged (U), are Unknown (X), or have had their pairing Broken (B). Any combination of the filter characters (including none) can be used. When * (All-or-none) is added to the combination, all paths are selected if there is any file that matches other criteria in the comparison; if there is no file that matches other criteria, nothing is selected.

[boboss123]

Merci pour les information, avec tout ça, je pense pouvoir me débrouiller.