Git & Version Control
Ouvrez un diff unifié et naviguez entre les fichiers avec les numéros de ligne avant et après.
Le patch reste dans ce navigateur. Aucun envoi, accès au dépôt ou exécution de patch.
Limites : 1 MiB en UTF-8, 20 000 lignes et 200 fichiers. Le filtre ignore la casse.
Entrée modifiée. Relancez l’analyse avant d’exporter.
Les exports contiennent toujours le patch ou le résumé complet, quels que soient le filtre et la pagination.
Git diff en ligne aide à relire une modification reçue sous forme de pièce jointe. Il suffit du fichier patch : le dépôt et les deux versions complètes du code ne sont pas nécessaires pour consulter les changements décrits.
Ce visualiseur de différences ne recalcule pas la comparaison. Il conserve les lignes ajoutées et supprimées et rattache chaque bloc au bon fichier.
Passez du patch reçu au fichier à relire.
Git diff en ligne sépare les côtés avant et après d’un diff unifié. Les suppressions et ajouts voisins sont alignés dans leur ordre d’apparition, avec le contexte des deux côtés. Aucune ligne absente du patch n’est inventée.
Recherchez une partie de l’ancien ou du nouveau chemin. Le filtre modifie la navigation, tandis que les totaux et les exports restent complets. La lecture d’un seul fichier ne produit donc pas un patch partiel à votre insu.
Utilisez git diff --no-color ou un diff standard avec ses deux en-têtes de fichier. Pour un patch reçu sous forme de courriel, exportez le diff brut depuis le dépôt source.
La vue côte à côte aligne les groupes de suppressions et d’ajouts selon leur ordre. La vue unifiée convient mieux pour suivre exactement la succession des opérations.
Comparez le nombre total de fichiers, de blocs et de lignes avec le fichier sélectionné. Les marqueurs binaires sont comptés séparément car ils ne livrent aucun contenu à inspecter.
Un ajout utilise /dev/null côté ancien, une suppression côté nouveau. Renommages, copies et changements de permissions restent visibles même sans bloc de texte. Les chemins cités par Git sont décodés pour faciliter la navigation.
L’en-tête @@ annonce les nombres de lignes des deux côtés. L’analyse les confronte au contexte, aux suppressions et aux ajouts. Elle rejette les blocs tronqués ou superposés et indique la ligne d’entrée, sans réparer les compteurs.
Le résumé JSON contient chaque chemin, état, mode fourni, nombre d’ajouts, de suppressions et de blocs. Les marqueurs binaires sont distincts : zéro ligne ajoutée ne signifie pas qu’une image ou un autre fichier binaire est identique.
Les patchs Git bruts et les diffs unifiés standard avec en-têtes --- et +++ sont acceptés. Les deux modes lisent les mêmes données. Les diffs combinés, enveloppes de courriel, couleurs et données binaires sont exclus.
Non, les pixels et les contenus binaires ne sont pas comparés. Si le patch contient Binary files … differ, le fichier et le marqueur sont affichés. Aucune quantité de lignes fictive ne représente ces changements binaires.
Le diff unifié décrit les plages avec @@ et distingue contexte, suppressions et ajouts par espace, moins et plus. Cette page lit un patch existant ; son téléchargement conserve le texte original sans le régénérer.
Oui. Collez le patch existant ou ouvrez un fichier local, puis naviguez dans l’arborescence. L’extension .patch ne prouve pas que la structure est correcte : les en-têtes et les blocs sont réellement analysés.
Oui : 1 MiB en UTF-8, 20 000 lignes et 200 fichiers. Si une limite est franchie, toute l’analyse est refusée. Exportez des patchs plus petits par fichier ou par commit depuis la source.
Une autre question ?
Ouvrez Git diff en ligne, vérifiez un chemin modifié et ses compteurs, puis conservez le patch original complet.
La validation du format ne garantit pas l’application dans un dépôt.