• 12 heures
  • Facile

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 26/08/2019

Identifiez la structure de fichier de Git

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Maintenant que vous savez utiliser les fonctionnalités de base de Git, nous allons voir sa façon de structurer les dossiers et son fonctionnement. Il est primordial de connaître le fonctionnement interne d'un programme afin de pouvoir par la suite l'utiliser au mieux !

Découvrez l’arbre Git et sa structure

Il existe trois types d'objets et demi. :D Si si !  Et demi. :pirate: En effet, il existe trois types d'objets principaux et un qui est un peu plus secondaire.

Les trois principaux types d'objets sont :

  • le "tree" ou l'arbre Git qui est une forme de répertoire. Il va référencer une liste de trees et de blobs (sous-répertoires et fichiers) ;

  • le "commit" qui va pointer vers un arbre spécifique et le marquer, afin de représenter son état à un instant donné ;

  • Le "blob" qui représente en général un fichier (Binary Large Object).

Il existe un dernier objet qui ne l'est pas vraiment. o_O C'est l'objet Tag. Le tag va représenter un commit d'une version spécifique. Mais ne nous étalons pas dessus. Le plus important est que vous reteniez le tree, le blob et le commit. :)

Tree, Blob et Commit
Tree, Blob et Commit 

Représentation cryptographique d'un commit

Toutes les informations nécessaires pour décrire l’historique d’un projet sont stockées dans des fichiers référencés par un identifiant de 40 caractères qui ressemble à quelque chose comme ça :

8gh96c4636981e4759825791c8ea3bcf5f2278t9

Pour chacun des objets dans Git, vous trouverez cette chaîne de 40 caractères que nous appelons le hash SHA-1. Celui-ci représente le contenu de l'objet. Pour deux objets différents, il est donc impossible d'avoir le même nom. Cela a l'avantage que par conséquent, Git peut tout de suite reconnaître deux objets identiques. Le commit étant un objet, lui aussi a son empreinte SHA-1. Il est donc tout à fait possible d'appeler n'importe quel commit à n'importe quel moment grâce à cet identifiant unique.

Exemple de générateur ici.

Je vous conseille fortement d'aller y jeter un œil afin de comprendre que le générateur vous donnera toujours la même clé pour le même texte. :)

Comment fonctionne la fusion sous Git ?

Il est très courant sous Git de vouloir fusionner le travail fait sur différentes branches. Pour cela, nous avons la fonction Merge. Un  git merge  ne devrait être utilisé que pour la récupération fonctionnelle, intégrale et finale d’une branche dans une autre, afin de préserver un graphe d’historique sémantiquement cohérent et utile, lequel représente une véritable valeur ajoutée. Comme son nom l’indique,  merge  réalise une fusion.  git merge  va combiner plusieurs séquences de commits en un historique unifié. Le plus souvent,   git merge  est utilisé pour combiner deux branches.  git merge  va créer un nouveau commit de merge. 

Imaginons que vous ayez votre branche master et une branche "Nouvelle fonctionnalité". Nous souhaitons maintenant faire un merge de cette branche de fonctionnalité dans la branche master. Appeler cette commande permettra de merger la fonctionnalité de branche spécifiée dans la branche courante, disons master.

Vous devez toujours vous assurer d'être sur la bonne branche. Pour cela, vous pouvez réaliser un  git status. Si vous n'êtes pas sur la bonne, réalisez un   git checkout, pour changer de branche. Maintenant que le terrain est prêt, vous pouvez réaliser votre merge.

git merge Nouvelle Fonctionnalité

Votre branche Nouvelle fonctionnalité va être fusionnée sur la branche master en créant un nouveau commit.

Fusion
Fusion

Les options Git pull/Git push

La commande Git pull permet de télécharger les modifications qui ont eu lieu sur le dépôt distant, dans le but de les rapatrier sur le dépôt local. Git pull est en réalité la fusion de deux commandes Git :  git merge  que nous venons de voir et  git fetch  que nous verrons juste après.  git pull va créer un nouveau commit de fusion comme le fait  git merge. La commande  git pull  exécute d'abord  git fetch  qui télécharge le contenu du référentiel distant spécifié. Ensuite, un git merge  est exécuté pour fusionner les modifications du dépôt distant et créer un nouveau commit de merge en local. 

git pull <remote>

À l'inverse, la commande Git push permet d'envoyer des modifications que l'on a réalisées en local sur le dépôt à distance.

git push <remote>
Pull et Push
Pull et Push

Nous allons voir maintenant la commande Git fetch d'un peu plus près. Elle aussi permet de récupérer les modifications d'un dépôt distant.

À quoi sert Git fetch ?

Git fetch, contrairement à Git pull, va aller chercher les modifications sur le dépôt distant mais ne va pas les fusionner avec nos modifications locales. Git isole le contenu récupéré en tant que contenu local existant, cela n'a absolument aucun effet sur votre travail de développement local. La commande Git fetch va récupérer toutes les données des commits effectués sur la branche courante qui n'existent pas encore dans votre version en local. Ces données seront stockées dans le répertoire de travail local, mais ne seront pas fusionnées avec votre branche locale. Si vous souhaitez fusionner ces données pour que votre branche soit à jour, vous devez utiliser ensuite la commande Git merge.

La commande Git pull automatise la mise à jour des données, mais peut entraîner de nombreux conflits si vous avez modifié beaucoup de fichiers. Utiliser la commande Git fetch permet de garder son répertoire de travail à jour et de contrôler le moment où l'on souhaite fusionner les données.

Voici un petit récapitulatif du fonctionnement des fonctions que nous avons vues :

Push et Pull
Push et Pull

Maintenant que vous maîtrisez les commandes Pull et Push, passons au rebasage !

Exemple de certificat de réussite
Exemple de certificat de réussite