Fonctionnement de Git
Comprenez les concepts fondamentaux de Git : commits, dépôts, répertoire de travail et zone de préparation. Découvrez la terminologie essentielle que tout développeur doit maîtriser.
Avant d'aborder le fonctionnement interne de Git, il est nécessaire que vous connaissiez les termes ainsi que les différents mécanismes et concepts qui le régissent.
Terminologie de Git
Le Commit
Un commit est un point dans l'évolution d'un fichier. Prenons une image pour expliquer cette phrase :
Comme vous pouvez le voir sur ce schéma, les commits sont stockés au sein d'un historique, cet historique permet de traquer l'évolution des fichiers de votre dépôt local (nous aborderons ce terme juste après). Le terme "commit" pourrait se traduire comme "validation" dans ce contexte. Un commit est effectué manuellement par le développeur. Prenons un exemple :
Note:
Vous avez développé une fonction au comportement complexe, la dernière chose que vous voudriez c'est la réécrire car vous l'auriez perdue. Dans ce cas vous allez interagir avec Git et effectuer un "commit" (effectuer une validation) pour que cette fonction soit gravée dans le marbre, pour que même si vous veniez à la supprimer par inadvertance, elle continuerait d'exister quelque part dans une version antérieure de votre fichier (stockée dans votre dépôt local).
En demandant à Git de faire un "commit", vous dites en fait à Git de créer une nouvelle version de votre fichier. Une version dans laquelle votre fonction existe quoi qu'il advienne de votre fichier. Un commit est donc une validation de modification.
Il existe certaines options pour les commits. En fait, pour effectuer un commit il y a un impératif : donner un "nom" à ce commit. On parle plutôt de message, ce message va servir à décrire les modifications apportées par ce commit. Si nous reprenons l'exemple du dessus, un message de commit correct serait quelque chose ressemblant à : "Implémentation de ma super fonction très utile". En attribuant un message à votre commit c'est comme si vous annotiez votre modification. De la même manière que vous écrieriez des commentaires de code. Un message de commit est obligatoire.
Note:
Conseil : Plus votre message de commit est descriptif, plus vous vous remercierez lorsque vous chercherez une modification bien particulière et que vous la trouverez grâce à la clarté de vos messages.
Maintenant que nous avons parlé du message du commit, nous allons parler de la façon dont vous allez dire à Git quel fichier vous voulez inclure dans votre commit. Et pour cette partie, nous allons avoir besoin d'un bon vieux schéma :
Les commits peuvent affecter 1 fichier ou un ensemble de fichiers. Par exemple (et c'est très généralement recommandé) vous pourriez vouloir qu'un commit affecte un seul et unique fichier, pour des raisons d'atomicité. Si c'est le cas, prenez un cookie et ne changez rien, c'est ce qu'il faut. Mais parfois, vous avez des modifications qu'il serait illogique de scinder dans des commits différents. Dans ce cas, vous pouvez très bien dire à Git de créer 1 commit pour 2 fichiers.
En réalité, le fait qu'un commit affecte un ensemble de fichiers n'est pas dramatique du tout, il faut simplement que ça vous paraisse logique de le faire de cette façon, et surtout le plus important, que ça ne devienne pas une contrainte dans le futur. Ce n'est pas le genre de chose qui peuvent être expliquées, seule votre expérience avec Git vous le fera comprendre. Mais sachez qu'une fois que vous aurez compris (en pratique) comment fonctionnent les commits et à quoi ils servent, vous ne pourrez plus vous passer de Git.
Mais étant donné que vous lisez cet article pour en apprendre plus sur Git et plus précisément, cette section pour en apprendre plus sur les commits, nous allons quand même essayer de comprendre pourquoi ceux qui ont pris un cookie en ont eu le droit.
Note:
Exemple de scénario sans commits appropriés :
Imaginons que vous travaillez sur un projet avec Git et vous faites des modifications mais un peu moins de commits, vous effectuez beaucoup de modifications tant et si bien qu'au bout d'un moment... votre programme ne fonctionne plus du tout. Alors vous en cherchez la cause en mettant les mains dans le code. Mais pas moyen de mettre la main sur la ou les modifications responsables. Et évidemment, votre dernier commit remonte à il y a deux heures.
Vous n'avez pas d'autre choix que de vous torturer l'esprit et passer en revue tout ce que vous avez fait depuis deux heures, ou restaurer la version de votre code qui supprime toutes les modifications que vous avez effectuées depuis ces deux heures.
En fait, votre erreur a été de ne pas faire de commits au fur et à mesure de votre avancée. Voyez ça comme une aubaine. Vous ne referez jamais l'erreur de ne pas estimer Git à sa juste valeur. Si vous aviez fait vos commits au fur et à mesure vous auriez pu revenir à une version antérieure, la tester, voir si cela réglait votre souci ou non et restaurer une version fonctionnelle qui n'était pas si loin en arrière dans le temps.
On ne parle pas ici de régularité dans le temps (faire un commit tous les x temps) mais plutôt en terme de progression. Pour vous donner une image :
Un puzzle est un ensemble de pièces qui, une fois assemblées forment une image.
Un projet est un ensemble de morceaux de code qui, une fois assemblés forment une application.
Vous trouveriez sans doute stupide que lorsque l'on fait un puzzle et que l'on se trompe de pièce, plutôt que de changer la pièce mal placée on défasse entièrement le puzzle. Et bien c'est exactement la même chose avec une application.
Bonnes Pratiques pour les Commits
En fait, l'idée est qu'il ne faut pas que vos commits fassent trop de chose, un commit ne devrait pas à la fois :
- Créer une interface graphique
- Créer un algorithme de génération de mot de passe
- Corriger un bug
Tout dans le même commit.
En général, il est recommandé de faire un commit pour une modification significative et ses modifications connexes, par exemple :
Note:
Exemple de commit acceptable :
Vous devez corriger un bug dans votre algorithme de génération de mot de passe et ajouter une fonctionnalité à cet algorithme.
Il est acceptable que ces deux modifications apparaissent dans le même commit, mais il sera toujours mieux de limiter vos commits à une action significative.
Par action significative nous entendons : des modifications qui apportent un intérêt à votre code :
- Ajouter un commentaire à une ligne de code n'est pas significatif
- Commenter une classe complexe l'est
- Ajouter une fonctionnalité à votre application est significatif
- Corriger un bug l'est aussi
En fait lorsque vous travaillez avec Git vous pouvez vous demander :
- Est-ce que j'ai envie que ma modification soit indépendante des autres ?
- Si je dois revenir à ce commit, est-ce que je vais devoir refaire quelque chose d'autre ?
- Est-ce que cette modification mérite vraiment un commit ?
Le Dépôt local
Git fonctionne avec des dépôts, le principe de dépôt est assez simple à comprendre. Un dépôt est un endroit dans lequel un historique de commits est stocké. Quand nous parlons de dépôt local, vous pourriez traduire par dossier.
Pour être tout à fait exact, un dépôt local n'est pas un dossier, disons plutôt qu'il est stocké dans un dossier. Avec Git un dépôt local est stocké dans un dossier caché nommé .git. La présence de ce dossier à la racine de votre projet fait de ce dernier un projet Git.
Ce schéma démontre que le réel dépôt local est contenu dans le dossier .git qui se trouve à la racine de votre projet Git. Voilà pourquoi dire qu'un dépôt Git est le dossier qui contient vos fichiers est un raccourci un peu simpliste (mais surtout incorrect).
Note:
Important : Si vous veniez à supprimer votre dépôt local (le dossier .git), tous vos commits seraient perdus et donc votre fonction avec. Puisque c'est dans votre dépôt local qu'est stocké votre historique de commits et donc vos commits, le supprimer signifie perdre tout votre historique de versions.
Note:
Terminologie : Nous utilisons le terme "dépôt" mais il est certain que vous serez majoritairement confronté au terme "repository" abrégé "repo". Le terme repository est simplement la traduction anglaise de "dépôt".
Le Working Directory (Répertoire de travail)
Nous entrons là dans le cœur de Git. Le working directory est l'endroit qui contient vos fichiers, cela peut paraître abstrait, nous allons prendre un schéma pour comprendre :
Le working directory est l'endroit dans lequel vous allez effectuer vos modifications, d'où son nom "répertoire de travail", vous passerez la plupart de votre temps à le manipuler. C'est la raison pour laquelle dire que le dossier de votre projet Git est votre dépôt local est incorrect, c'est votre working directory.
La Stage Area (Zone de préparation)
La stage area est la seule zone Git qui n'est pas aussi tangible que le working directory ou que le dépôt local. Dans le sens où cette dernière n'inscrit rien dans le marbre, cette zone Git sert à préparer les modifications que vous effectuez dans vos fichiers au sein du working directory à un envoi vers votre dépôt local. Elle sert de "zone tampon" entre votre working directory et votre dépôt local.
Voilà comment on peut représenter la stage area. Elle se situe entre le working directory et le dépôt local, d'où cette appellation de "zone tampon".
Note:
Analogie du théâtre : Imaginons que nous soyons au théâtre, les loges des comédiens représentent le working directory. La stage area est l'arrière-scène, là où les comédiens se préparent à entrer en scène. Et le dépôt local représente la scène.
Maintenant prenons un cas d'utilisation typique de Git :
Vous travaillez sur une classe quelconque, vous êtes dans les loges (working directory). Puis vous préparez vos modifications à entrer en scène, vous êtes derrière la scène (stage area). Vous faites un commit pour votre classe, vous l'envoyez sur le devant de la scène (dépôt local).
En pratique, la stage area n'est rien d'autre qu'une zone de préparation aux commits. Nous allons à nouveau prendre un schéma :
Voilà ce qu'il se passe lorsque vous souhaitez faire un commit sur deux fichiers, vous allez demander à Git de préparer vos deux fichiers à un commit. Git déplace alors ces deux fichiers dans la stage area, il ne vous reste plus qu'à faire votre commit, et les deux versions de vos fichiers seront envoyées dans votre dépôt local sous le même commit.
Note:
Note : Vous ne pouvez pas demander à Git de préparer un fichier qui n'a subi aucune modification depuis sa dernière version dans votre dépôt local.
Conclusion
Maintenant que vous connaissez les bases de Git, vous êtes capable de commencer à travailler avec Git. Il vous reste encore à découvrir quelques notions que nous n'avons pas abordées dans un souci de brièveté, nous les aborderons un peu plus tard. Vous avez une base solide pour commencer à l'utiliser.
Résumé
- Un commit est une validation des modifications qu'un fichier a subies
- Le working directory est l'espace où l'on opère des modifications sur un fichier
- La stage area est une zone tampon entre le working directory et le dépôt local qui sert à préparer le(s) fichier(s) à inclure dans le prochain commit
- Le dépôt local est l'espace qui sert à enregistrer/traquer vos commits
- Supprimer votre dépôt local revient à supprimer tous vos commits et donc toutes les versions de vos fichiers (exceptée celle se trouvant dans le working directory)
Note:
Dans le prochain article, nous explorerons les commandes Git pour commencer à utiliser Git de manière pratique.