IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

GitHub publie un nouvel outil nommé git-sizer
Afin d'aider les mainteneurs à optimiser leurs dépôts

Le , par Marco46

324PARTAGES

8  0 
Contexte

GitHub, s'il est encore besoin de la présenter, est une entreprise américaine fournissant un service d'hébergement de dépôts git sur Internet. Le service a été ouvert en octobre 2007 et depuis s'est imposé comme le standard pour un grand nombre de projets open source. De nombreuses entreprises utilisent également le service en ligne pour y héberger leurs dépôts privés, certaines autres utilisent la version "enterprise" qui leur permet de bénéficier du service tout en conservant le contrôle de leurs données en installant dans leur propre réseau une version payante de GitHub.

Github héberge désormais plus de 80 millions de dépôts (données de mars 2018), lui permettant de disposer de statistiques inégalées sur l'usage et le contenu des dépôts.


Le 5 mars dernier, GitHub a dévoilé sur son blog un nouvel outil nommé git-sizer publié sous licence MIT. Cet outil écrit avec le langage Go analyse le contenu du dépôt dans lequel il est exécuté et fournit un rapport affichant une vue globale des métriques principales associées à un indicateur d'alerte sous la forme d'un astérisque (*) ou d'un point d'exclamation (!) relatif à l'usage standard constaté sur leur plateforme.

Installation

L'installation de git-sizer se fait très simplement en téléchargeant le binaire correspondant à votre système ou bien en compilant depuis les sources.

À noter que la version locale du CLI git doit être au minimum la 2.6.

Il est conseillé d'ajouter le répertoire d'installation du binaire au PATH pour un usage plus facile.

Usage

Il suffit de se placer dans le répertoire racine d'un dépôt et d'exécuter le binaire. L'option --verbose permet d'obtenir un compte rendu détaillé (par exemple sur le dépôt du noyau Linux) :

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
$ git-sizer --verbose
Processing blobs: 1652370
Processing trees: 3396199
Processing commits: 722647
Matching commits to trees: 722647
Processing annotated tags: 534
Processing references: 539
| Name                         | Value     | Level of concern               |
| ---------------------------- | --------- | ------------------------------ |
| Overall repository size      |           |                                |
| * Commits                    |           |                                |
|   * Count                    |   723 k   | *                              |
|   * Total size               |   525 MiB | **                             |
| * Trees                      |           |                                |
|   * Count                    |  3.40 M   | **                             |
|   * Total size               |  9.00 GiB | ****                           |
|   * Total tree entries       |   264 M   | *****                          |
| * Blobs                      |           |                                |
|   * Count                    |  1.65 M   | *                              |
|   * Total size               |  55.8 GiB | *****                          |
| * Annotated tags             |           |                                |
|   * Count                    |   534     |                                |
| * References                 |           |                                |
|   * Count                    |   539     |                                |
|                              |           |                                |
| Biggest objects              |           |                                |
| * Commits                    |           |                                |
|   * Maximum size         [1] |  72.7 KiB | *                              |
|   * Maximum parents      [2] |    66     | ******                         |
| * Trees                      |           |                                |
|   * Maximum entries      [3] |  1.68 k   |                                |
| * Blobs                      |           |                                |
|   * Maximum size         [4] |  13.5 MiB | *                              |
|                              |           |                                |
| History structure            |           |                                |
| * Maximum history depth      |   136 k   |                                |
| * Maximum tag depth      [5] |     1     | *                              |
|                              |           |                                |
| Biggest checkouts            |           |                                |
| * Number of directories  [6] |  4.38 k   | **                             |
| * Maximum path depth     [7] |    14     | *                              |
| * Maximum path length    [8] |   134 B   | *                              |
| * Number of files        [9] |  62.3 k   | *                              |
| * Total size of files    [9] |   747 MiB |                                |
| * Number of symlinks    [10] |    40     |                                |
| * Number of submodules       |     0     |                                |

[1]  91cc53b0c78596a73fa708cceb7313e7168bb146 (91cc53b0c78596a73fa708cceb7313e7168bb146)
[2]  2cde51fbd0f310c8a2c5f977e665c0ac3945b46d (2cde51fbd0f310c8a2c5f977e665c0ac3945b46d)
[3]  4f86eed5893207aca2c2da86b35b38f2e1ec1fc8 (refs/heads/master:arch/arm/boot/dts)
[4]  a02b6794337286bc12c907c33d5d75537c240bd0 (refs/heads/master:drivers/gpu/drm/amd/include/asic_reg/vega10/NBIO/nbio_6_1_sh_mask.h)
[5]  5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c (refs/tags/v2.6.11)
[6]  1459754b9d9acc2ffac8525bed6691e15913c6e2 (589b754df3f37ca0a1f96fccde7f91c59266f38a^{tree})
[7]  78a269635e76ed927e17d7883f2d90313570fdbc (dae09011115133666e47c35673c0564b0a702db7^{tree})
[8]  ce5f2e31d3bdc1186041fdfd27a5ac96e728f2c5 (refs/heads/master^{tree})
[9]  532bdadc08402b7a72a4b45a2e02e5c710b7d626 (e9ef1fe312b533592e39cddc1327463c30b0ed8d^{tree})
[10] f29a5ea76884ac37e1197bef1941f62fda3f7b99 (f5308d1b83eba20e69df5e0926ba7257c8dd9074^{tree})
La sortie de la commande peut être convertie au format json via l'option --json.

Notez que les Blobs correspondent aux contenus des fichiers versionnés, et les Trees à la gestion des répertoires.

Bonnes pratiques

C'est l'occasion pour l'équipe GitHub de rappeler certaines bonnes pratiques concernant la gestion des dépôts.

  • Taille sur le disque 

    La taille d'un dépôt ne devrait pas dépasser 1 Go, des problèmes de performances apparaissent sur les dépôts dépassant les 5 Go. Il convient donc d'éviter de versionner les binaires, fichiers multimédias de grande taille et archives.


  • Nombre de références 

    Le nombre de références (branches et tags) a également un gros impact sur les performances d'utilisation, car elles sont transmises en intégralité à chaque git fetch <remote> exécuté par un utilisateur même lorsque son dépôt local est à jour. Au-delà de quelques dizaines de milliers de références des problèmes de performances importants peuvent apparaître.


  • Nombre d'objets 

    Plus un dépôt contient d'objets, plus il faut de temps à git pour traverser l'historique. Un projet contenant un très grand nombre de petits fichiers peut avoir des problèmes de performances de ce fait. La bonne pratique consiste à diviser un énorme dépôt en plusieurs dépôts.


  • Taille des blobs 

    Un dépôt ne devrait pas contenir de fichiers de taille trop importante. Des fichiers de plusieurs Mo devraient être des exceptions.


  • Gros fichiers textes ayant beaucoup de versions différentes 

    Git optimise très bien le stockage des fichiers textes, mais certaines opérations peuvent être extrêmement gourmandes en ressources lorsqu'un très grand nombre de versions d'un gros fichier texte existe. Par exemple avec la commande git diff.


  • Profondeur de l'arbre des répertoires 

    Au-delà de 2000 entrées dans un répertoire des problèmes de performances peuvent apparaître.


  • Longueur des chemins d'accès (fichiers ou répertoires) 

    Au-delà de 200 caractères pour un chemin d'accès sur un grand nombre de fichiers ou de répertoires des problèmes peuvent apparaître.


Sources
- Blog officiel : "Measuring the many sizes of a Git repository"
- Dépôt GitHub de git-sizer

Et vous ?
Constatez-vous des problèmes de performances sur les dépôts sur lesquels vous travaillez ?
Envisagez-vous d'utiliser git-sizer ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Marco46
Expert éminent sénior https://www.developpez.com
Le 12/03/2018 à 10:27
T'as raison hash bang c'est pour #! sur les SPA qui utilisent pas l'API de gestion d'historique du HTML5.

Je corrige.
2  0 
Avatar de Neckara
Inactif https://www.developpez.com
Le 12/03/2018 à 8:08
Citation Envoyé par Marco46 Voir le message
d'un hash bang (!)
Chez moi ça s'appelle un point d'exclamation
0  0 
Avatar de Obsidian
Modérateur https://www.developpez.com
Le 12/03/2018 à 17:21
On ne pas « shebang », plutôt ?
0  0 
Avatar de Marco46
Expert éminent sénior https://www.developpez.com
Le 13/03/2018 à 10:20
Les deux se disent. A l'oreille je préfère hash bang
0  0