GIT c'est quoi

• Traduction

  Le terme GIT peut se traduire par "connard". Mais son auteur Linus TORVALD, imbu de lui même, lui a donné ce nom à cause de ses utilisateurs "cons comme une bite" (sic) qui peut se traduire aussi par GIT

• outil de versionning

  GIT est un outil de versionning, c'est à dire un outil qui aura pour but de stocker les évolutions de vos développements

A quoi ca sert

• Maintenir des versions de fichiers

  Cet outil vous permet de faire une maintenance de vos fichiers, dans le temps. C'est la raison pour laquelle GIT a comme principal but d'effectuer une maintenance des versions de vos fichiers. Pour un même fichier, ou un ensemble cohérent et fonctionnel de fichiers (dans le cas, par exemple, de MVC, ouy encore de fichiers HTML+CSS), l'utilisation de Git va vous permettre de pouvoir historiser vos propres créations et ou modifications de votre code, dans un but de pouvoir revenir en arrière. Le "retour en arrière à une version donnée", c'est l'unique fonctionnalité de git

• Fichiers généralement au format texte

  Bien que l'outil vous permettent d'historiser n'importe quel fichier, que ce soit un fichier binaire ou un fichier au format texte, l'auteur de cet outil à comme principal priorité l'historisation de documents au format texte. Je vous rappelle que l'auteur de cet outil est le même auteur que le système d'exploitation Linux. Linus Torvald à développé ce logiciel dans le but d'avoir une facilité de maintenance de son noyau. C'est ainsi qu'en une nuit il a développé l'outil pour pouvoir effectuer parmi ensemble de ses contributeurs au noyau, des mises à jour et des intégrations de code. C'est la raison pour laquelle, cet outil ne pas fait pour historiser des fichiers binaire, mais des fichiers texte. Ceci explique pourquoi dans les interfaces graphiques des logiciel clients GIT, vous avez toujours la possibilité de visualiser le contenu du fichier. Si vous versionnez un fichier binaire, cet outil effectuera correctement l'opération, mais vous ne pourrez pas visualiser son contenu. Toutefois, si vous versionnez tout un répertoire d'un outil de compilation dans lequel votre exécutable est contenu à l'intérieur, il ne se passera aucun problème il sera bien dans votre historisation. Il sera juste inexploitable directement puisque els outils clients de versionning comme GIT GUI ne savent n'afficher que du texte !

• un sens unique : upgrade

  L'une de mes premières préoccupations, notamment lorsque l'on développe en équipe, était de ne pas faire de bêtises dans le but de supprimer des fichiers intégrés au versioning de GIT. Il faut avoir à l'esprit que cette opération n'est pas possible en utilisant GIT comme je vous le conseille. En revanche, apporter une modification au dernier commit reste possible, notamment pour changer le libellé. En effet, avec ce logiciel, vous allez toujours ajouter des modifications. J'ai bien dit ajouter. L'opération de soustraction, qui pourrait correspondre par exemple à une suppression d'un bout de code de votre projet, correspond dans GIT à un ajout d'un nouveau fichier. Ainsi, lorsque vous allez créer une correction qui va supprimer une fonctionnalité de votre code, vous n'avez pas créer une suppression au niveau conceptuel dans GIT, mais vous allez ajouter une nouvelle mise à jour d'un fichier, dans lequel vous avez ajouté une modification correspondant à une suppression de code, un ajout ou une modification dans ce fichier. Ainsi, au niveau de GIT, vous allez rajouter un élément. Peu importe que ce nouvel ajout corresponde dans votre code à un ajout de code ou une suppression de code. Avec cette manière de faire (largement recommandé par Linus TORVALD) à une grande importance. En effet, vous allez toujours rajouter une nouvelle version à votre historisation de GIT, quelle que soit l'opération faite dans votre code. Ainsi, dans l'historique de vos modifications, vous allez pouvoir retracer et retrouver le moment de votre comit qui vous intéresse

Les outils

• GIT = CLI =  ligne de commande

  Quand on connaît l'auteur de cet outil, nous ne sommes pas étonnés de savoir que GIT est un outil qui fonctionne en ligne de commande. C'est la raison pour laquelle, sur le site officiel de Git, chacune des opérations est nommé par la commande correspondant au logiciel GIT. Ainsi, vous allez lancer la commande par GIT suivi de l'opération que vous souhaitez faire. Nous ne rentrerons pas dans ce détail technique, puisque nous avons pris le parti de travailler avec une interface graphique. Mais sachez que chaque action lancée via vos interfaces graphiques correspondent à une ligne de commande. Par ailleurs, comme nous travaillons avec des interfaces graphiques, nous savons pertinemment que l'interface graphique d'un outil et forcément plus compliqué à mettre en œuvre qu'une simple ligne de commande. C'est la raison pour laquelle, par exemple, l'outil git GUI ne propose pas l'étendue des fonctionnalités de GIT CLI. C'est aussi la raison pour laquelle, ayant très longtemps été obligé de travailler avec Git GUI, je ne recommande pas cet outil car il offre très peu de fonctionnalités par rapport à d'autres outils graphiques. Toutefois, le gros intérêt dans les dernières versions de GIT GUI, c'est que vous pouvez directement installer GIT GUI sans avoir forcément à relier votre outil à GIT CLI sur votre ordinateur. Mais si vous êtes enfin connaisseur de GIT ou que vous souhaitez utiliser avec ses fonctionnalités relativement avancées, il faut se tourner vers des outils graphiques nettement plus évolués que GIT GIT

• il y a plein de clients

  Des logiciels à interface graphique qui servent à utiliser cet outil de versionning, il en existe pléthore. Même si pour GIT GUI, par défaut graphique, et fonctionnant avec git cli, vous pourrez retrouver sur le site http://git-scm.org/downloads/guia>, plusieurs dizaines de logiciels graphiques vous permettant de gérer votre versioning, que ces outils soient des logiciels libres, propriétaires, gratuits ou encore payants. Il existe même des outils pour Windows que vous pouvez intégrer directement à votre explorateur de fichiers, qui vous permettent d'utiliser ce dernier comme un outil de versionning Dans ce cas, l'ensemble des fonctionnalités de GIT se retrouvent sur le clic droit de la souris lorsque vous cliquez sur un fichier. Certains autres vous permettent même en un clic, d'ajouter directement à votre dépôt l'ensemble des fichiers d'un ou plusieurs répertoires Vous pourrez retrouver ces outils sur le site https://git-scm.com/downloads/guisa> Et bien que je ne sois pas super fan de Git CLI, c'est cet outil que nous allons utiliser dans ce tutoriel

L'utilisation de GIT

• Pour le développeur auteur de base

  J'entends ici par développeur de base, le développeur qui départ son projet de rien : pas de fork, pas de fichiers récupérés de départs. Dans ce cas, les étapes à effectuer sont dans l'ordre : Créer son dépôt Ajouter ses fichier "à suivre" dans le dépôt Créer ses commit. Notez qu'une fois "supervisés" par GIT, le dossier dans lequel les fichiers se trouvent aura un dossier caché (il commence par un point) sauf sous Windows qui ne sait pas que les autres systèmes d'exploitation dont le nom de fichier commence par un point sont cachés.

  • Créer son dépot

    Pour créer un dépot sous Git GUI, cliquer sur Create a new dépository, sélectionnez dans la deuxieme fenêtre, le dossier à superviser, puis cliquer sur create. Notez que je parle ici d'un dépôt local. Mais ce dépot pourrait etre distant sur un serveur de dépôts

  • Ajouter ses fichiers

    La fenêtre est découpée en 4 zones. Dans la zone en bas à gauche, vous avez les derniere fichiers modifiés. Lors du premier chargement du projet GIT, tous les fichiers seront dans cette zone puisque GIT ne les à pas encore en "supervision". Il suffit de sélectionner chacun des fichier à intégrer dans le commit que vous souhaitez créer. Une fois les fichiers sélectionnés, vous êtes prête à commiter.

  • créer ses commits

    Un commit DOIT NECESSAIREMENT être commenté. Sans ce commentaire, Git GUI refuse d'aller plus loin. Le commentaire est un chainon essentiel dans le versionning et nous le verrons pllus loin. Saisissez votre commentaires et vous pourrez alors procéder au commit en cliquant sur le bouton commit. Une fois le commit correctement effectué, dans les deux zones du bas, elles deviendront vides. "L'arbre des commits" va alors se construire au fur et à mesure.

    • un commit = un identifiant

      Chaque commit est identifié par un identifiant unique SHA1. Dans le menu repository->Visualise Master's history, vous découvrirez l'ensemble des modifications apporter, accompagnées des commentaires que vous avez mis dans chacun de vos commit. C'est pour cela que ces commentaires sont importants, ils vous permettront de retrouvez l'endroit, le commit où vous avez apporté telle ou telle modification

• Pour le développeur "forkeur"

  J'ebntends pas développeur forkeur un développeur qui se base sur un dépot pour recupérer une source à un moment donné et la développer differemment que le suivi des développeurs d'origine.

  • Créer sa propre branche et récupérer d'un autre dépot

    Au sens GIT, une branche correspond à un fork de votre projet. Alors je sais expliquer un terme abscon par un autre terme, c'est très con...pliqué. Alors nous allons voir le rôle et le but de cette opération. Mais avant cela, présentons le contexte pour mieux comprendre le but de cette opération. Soit votre rôle de développeur au sein d'une équip. Dans cette équipe, vous travaillez tous sur un même projet, mais chacun de vous à un sous-projet qui lui est attribué : Un développeur va travailler sur la partie métier, un infographiste va travailler sur la partie graphique, un 3e développeur va travailler sur la partie interface graphique client. Vous n'êtes donc pas le seul sur le projet. Partant de ce contexte, et sachant que chacun des développeurs travaillent sur son propre serveur local, même si cette fonctionnalité est un peu tirée par les cheveux, elle est essentielle pour comprendre la problématique. Cette problématique on la retrouve si chacun des développeurs travaillaient sur un projet en défi par exemple ou Visual Basic, ou chacun des compilateurs n'est pas installé sur un serveur mais sur chacun des postes clients. Ainsi, les développeurs ne peuvent pas mettre en commun leur fichier sur un serveur commun. C'est la raison pour laquelle dans la philosophie de Git, chaque développeur va avoir son "propre environnement" de développment, son petit coin à lui. Au sens GIT, cette partie s'appelle une branche.

  • Apporter ses propres modifications dans sa branche

    Dans chacune des branches du projet, les développeurs vont venir apporter à l'édifice chacun de ses développements spécifiques. Le projet global va alors se construire branches par branches. Mais vous êtes bien d'accord que à un moment donné, nous avons besoin d'un développeur "chef d'orchestre" qui va devoir récupérer l'ensemble des branches, afin de générer le projet final. Dans le cas d'outils compliqués, c'est ce même chef d'orchestre qui aura le dernier mot du projet en complément le logiciel final. Même si cela est très théorique, c'est cette philosophie qu'il faut appliquer avec l'outil GIT.

  • faire un push sur le serveur

    Pour résumer, chaque développeur va avoir sa propre branche dans l'accueil il va travailler, et dans cette même branche, il va effectuer tous les comits dont nous avons déjà parlé précédemment. Lorsque le chef d'orchestre estime que sa branche est terminée, il demande au gestionnaire du projet GIT (dont j'ai oublié le nom de sa fonction), de lui prendre sa branche pour intégrer au projet final. Petite parenthèse sur le sujet, il peut donner sa branche de deux manières différentes : Soit il la donne de lui-même c'est ce que l'on appelle un "push" au chef d'orchestre, Soit c'est le chef d'orchestre qui va chercher et à branche c'est ce que l'on appelle un pull. point q Que ce soit un push ou un pull, le résultat doit être le même, c'est intégrer chacune des branches dans le projet final. D'expérience, le push ou le pull est un choix plus politique que technique

• Les commandes

  • Commandes de sa propre branche

    • add

      La commande git add ajoute un changement dans le répertoire de travail à la zone commune. Il indique à Git que vous souhaitez inclure les mises à jour d'un fichier particulier dans le prochain commit. Cependant, git add n'affecte pas vraiment le référentiel de manière significative - les modifications ne sont réellement enregistrées que lorsque vous exécutez git commit. Il faut voir git add comme une liste des fichier préparatoires au commit https://git-scm.com/docs/git-add

    • status

      La commande git status affiche l'état du répertoire de travail et de la zone de staging. Il vous permet de voir les modifications et les fichiers suivis par Git. La sortie d'état ne vous montre aucune information concernant l'historique du projet validé. https://git-scm.com/docs/git-status

    • diff

      Afficher les changements entre l'arbre de travail et l'index ou un arbre, les changements entre l'index et un arbre, les changements entre deux arbres, les changements résultant d'une fusion, les changements entre deux objets blob ou les changements entre deux fichiers sur le disque https://git-scm.com/docs/git-diff

    • commit

      Crée un nouveau commit contenant le contenu actuel de l’index et avec le message de validation décrivant la modification. Le nouveau commit est un fils direct de HEAD, habituellement au sommet de la branche actuelle et la branche est mise à jour pour pointer dessus (à moins qu’aucune branche ne soit associée avec l’arbre de travail actuel, auquel cas HEAD est « détachée » comme décrit dans git-checkout https://git-scm.com/docs/git-commit/

    • notes

      Ajoute, supprime ou lit des notes attachées à des objets, sans toucher les objets eux-mêmes. https://git-scm.com/docs/git-notes/

    • restore

      Restaurez les chemins spécifiés dans l'arborescence de travail avec du contenu provenant d'une source de restauration. Si un chemin est suivi mais n'existe pas dans la source de restauration, il sera supprimé pour correspondre à la source. https://git-scm.com/docs/git-restore/

    • mv

      Déplacer ou renommer un fichier, un répertoire ou un lien symbolique https://git-scm.com/docs/git-mv

    • reset

      Sns vouloir rentrer dans les détail, git-reset permet de rempalceer un arbre https://git-scm.com/docs/git-reset

  • Fusions de branches

    • branch

      Lister, créer ou supprimer une branche

    • checkout

      Changer de branche ou restaurer les fichiers de l'arborescence de travail

    • switch

      Changer de branche

    • merge

      Fusionner les branches

    • mergetool

      Exécutez des outils de résolution de conflits de fusion pour résoudre les conflits de fusion

    • log

      Affiche le log des commits effectués

    • stash

      Cachez les modifications dans un répertoire de travail "sale"

    • tag

      Créer, répertorier, supprimer ou vérifier un objet tag signé avec GPG

    • worktree

      Gérez plusieurs arborescences de travail attachées au même référentiel.

• Cas d'utilisation pour un intégrateur

  J'utilise ce cas spécifiquement car : l'intégrateur ne CREE pas de fonction métier (qui, en MVC, comportent au moins 3 fichier : le modele, la vue et le controleur), il INTEGRE des éléments de certains développeurs tiers cependant l'INTEGRATEUR peut être amené à apporter ses modifications et va pouvoir historiser ses modifications pour éventuellement revenir en arrière

  • Quand faire son GIT ?

    D'une manière générale, il faut faire son GIT quand l'ensemble d'une fonctionalité est perminée. L'idée étant, en cas de besoin, de pouvoir repartir sur un "pécédent" git FONCTIONNEL

• les outils graphiques

  https://git-scm.com/downloads/guis

FAQ

• Puis-je utiliser GIT comme un puissant outil de sauvegarde ?

  NON !! GIT m'avait paru super interessant pour sauvegarder l'historisation? Mais une sauvegarde, c'est au départ une copie des fichiers éventuellement compressé. GIT ne duplique pas les fichiers, il eneregistre les différences de fichiers !

vocabulaire

• Fork ou branche

  Un fork est une branche issue d'une branche existante, à laquelle des modifications peuvent être apportées

• dépot

  Un dépôt au sens GIT est une espace de stockage où seront stockés l'ensemble du travail "suivi" des modification du projet