Analyse des sessions Git

Responsabilité centrale

Générer une analyse structurée de l'activité git pour une période ou une plage de commits spécifiée, incluant l'historique des commits, les changements de fichiers, les statistiques et des diffs optionnels.

Entrées

Accepter de l'utilisateur :

Plage temporelle : "last 2 hours", "since 10am", "today", "since 2025-10-23 14:00"
Plage de commits : "abc123..def456", "HEAD~5..HEAD", "feature-branch..main"
Filtres optionnels : Chemins spécifiques, auteurs ou types de fichiers
Profondeur de sortie : Concise (défaut), Détaillée ou format Code Review

Processus de travail

Étape 1 : Analyser et valider l'entrée

Déterminer le type de plage :
- Basée sur le temps : Parser le temps relatif ou absolu
- Basée sur les commits : Valider que les références de commits existent
- Basée sur les branches : Résoudre les noms de branches en commits
Valider le repository git :
```
git rev-parse --git-dir
```
Vérifier que la plage contient des commits :
```
git log <range> --oneline | head -1
```
Si vide, informer l'utilisateur et quitter.

Étape 2 : Extraire l'historique des commits

# Obtenir tous les commits dans la plage
git log <range> --oneline --no-decorate

# Obtenir les infos détaillées des commits
git log <range> --format="%h|%an|%ar|%s" --no-decorate

# Compter les commits
git log <range> --oneline | wc -l

Stocker les données des commits pour le résumé.

Étape 3 : Générer les statistiques

Statistiques de changement globales :

# Stats résumées (insertions/suppressions par fichier)
git diff <start>..<end> --stat

# Stats numériques pour parsing
git diff <start>..<end> --numstat

# Compter les changements totaux
git diff <start>..<end> --shortstat

Répartition par auteur (si plusieurs auteurs) :

git shortlog <start>..<end> -sn

Catégorisation des fichiers :

Identifier les nouveaux fichiers (statut "A")
Identifier les fichiers supprimés (statut "D")
Identifier les fichiers renommés (statut "R")
Fichiers modifiés avec magnitude de changement

Étape 4 : Identifier les fichiers clés pour analyse détaillée

Règles de priorité :

Changements importants (>100 lignes modifiées) : Toujours inclure
Nouveaux fichiers : Inclure (surtout si >50 lignes)
Fichiers supprimés : Noter mais ne pas diffuser
Fichiers d'architecture : build.gradle.kts, AndroidManifest.xml, configs de modules
Fichiers de test : Signaler séparément pour évaluation de couverture de test

Extraire la liste des fichiers clés :

# Fichiers modifiés avec comptage de lignes
git diff <start>..<end> --numstat | sort -rn -k1 -k2

Limiter aux 10 premiers fichiers par défaut pour éviter le débordement de contexte.

Étape 5 : Générer les diffs sélectifs (selon la profondeur)

Mode concis : Pas de diffs, statistiques uniquement

Mode détaillé : Diffs pour 3-5 fichiers clés

git diff <start>..<end> -- path/to/key/file.kt

Mode Code Review : Diffs pour tous les fichiers modifiés, groupés par module

# Grouper par répertoire
git diff <start>..<end> --name-only | cut -d'/' -f1-2 | sort -u

# Générer les diffs par module
for module in modules; do
  git diff <start>..<end> -- $module/
done

Protection contre le débordement de contexte :

Si >10 fichiers changés significativement, limiter aux 5 meilleurs diffs
Avertir l'utilisateur : "Showing top 5 files by change size. Request specific files for full diffs."

Étape 6 : Présenter le résumé structuré

Format selon la profondeur :

Résumé concis

## Git Session Summary

**Range**: <start-commit> to <end-commit> (<timeframe>)
**Commits**: X commits by Y author(s)
**Files Changed**: A modified, B added, C deleted
**Net Changes**: +X -Y lines

### Commits

- abc123 Commit message 1
- def456 Commit message 2
  ...

### Top Files Changed

1. path/to/file1.kt (+50 -20)
2. path/to/file2.kt (+30 -15)
   ...

Résumé détaillé

Inclut :

Liste complète des commits avec auteurs et timestamps
Liste complète des fichiers avec stats de changement
Répartition par auteur
Diffs pour 3-5 meilleurs fichiers pour relecture

Format Code Review

## Code Review Summary

### Overview

- **PR Title**: [Suggested from commit messages]
- **Changes**: X files across Y modules
- **Scope**: [Inferred from changed files]

### Commits

[Formatted commit list suitable for PR description]

### Changes by Module

**Module: app**

- file1.kt: Description of changes
- file2.kt: Description of changes

**Module: core**
...

### Key Changes

[Diffs for significant modifications]

### Test Coverage

- Test files modified: X
- New tests added: ~Y

Lignes directrices de sortie

Messages de commit

Afficher le hash court (7 caractères)
Afficher seulement la première ligne du message de commit
Tronquer les longs messages à 80 caractères
Grouper par auteur si plusieurs contributeurs

Chemins de fichiers

Utiliser les chemins relatifs depuis la racine du repo
Formater comme code : path/to/file.kt
Inclure la magnitude du changement de lignes : (+X -Y)
Mettre en évidence le type de fichier (source, test, config)

Statistiques

Présenter dans des tableaux clairs :

| Metric        | Count |
| ------------- | ----- |
| Commits       | 15    |
| Files Changed | 23    |
| Insertions    | +450  |
| Deletions     | -180  |

Diffs

Inclure le chemin du fichier comme en-tête : ### path/to/file.kt
Utiliser des blocs de code avec coloration syntaxique
Afficher les lignes de contexte (défaut git : 3 lignes avant/après)
Tronquer les diffs très volumineux (>200 lignes) avec résumé

Gestion du budget de contexte

Surveiller les tailles des diffs :

Petite session (<10 fichiers, <500 lignes) : Sûr pour le mode détaillé
Session moyenne (10-30 fichiers, 500-2000 lignes) : Utiliser des diffs sélectifs
Grande session (>30 fichiers, >2000 lignes) : Mode concis avec avertissements

Divulgation progressive :

Toujours commencer avec un résumé concis
Demander à l'utilisateur : "Would you like detailed diffs for specific files?"
Générer les diffs sur demande plutôt qu'à l'avance

Secours pour les grandes sessions : "This session modified 45 files with 5000+ line changes. Showing concise summary. Request specific files or modules for detailed diffs."

Anti-patrons à éviter

À ne pas faire :

Générer des diffs pour tous les fichiers dans les grandes sessions (débordement de contexte)
Inclure les diffs complets sans demander (perte de contexte sur des détails non nécessaires)
Ignorer les types de fichiers (traiter les changements de test comme des changements de source)
Perdre le contexte de ce que l'utilisateur veut savoir
Utiliser des résumés génériques ("modified 10 files") sans spécificités

À faire :

Demander à l'utilisateur quel niveau de détail il souhaite
Prioriser les fichiers clés par magnitude de changement
Catégoriser les fichiers (source, test, config, docs)
Fournir des résumés actionnables
Proposer de détailler des fichiers spécifiques

Critères de succès

Une bonne analyse de session git devrait :

Informer : L'utilisateur comprend la portée des changements en un coup d'œil
Cibler : Met en avant les changements les plus significatifs en premier
Être actionnelle : Fournit des chemins et des diffs pour une relecture plus approfondie
Être efficace : Ne gaspille pas le contexte sur des détails inutiles
S'adapter : Ajuste la profondeur selon la taille de la session et les besoins de l'utilisateur

Exemples de sortie

Voir contexts/example-outputs.md pour des exemples détaillés de résumés concis et de formats Code Review.

analyzing-git-sessions