La première information utile est "gestion de versions" : Le but principal d'un système de contrôle de version est de conserver un historique détaillé d'un projet ainsi que la possibilité de travailler sur différentes versions de celui-ci. Avoir un historique détaillé permet de voir l'avancement du projet au fil du temps. Si nécessaire, il est également possible de revenir à n'importe quel point du projet pour récupérer des données ou des fichiers. C'est également un outil robuste pour travailler à plusieurs sur des fonctionnalités différentes au sein en s'assurant de la perennité et de la compatibilité des données.
La deuxième information utile est la notion de logiciel décentralisé ou encore distribué. Pour faire simple, dans le cas d'un modèle centralisé, tous les utilisateurs se connectent à un serveur central appelé le dépôt maître pour interagir avec les données du projet. Dans le cas d'un modèle distribué, comme pour le logiciel Git, chaque utilisateur à l'ensemble des données du projet sur son ordinateur personnel.
Dans le cadre de cette UE ainsi que durant le reste de votre longue vie de développeur, vous serez amener à une utiliser Git pour archiver et travailler sur vos projets. Vous pourrez ainsi avancer étape par étape sur chaque feature de vos projets, travailler à plusieurs et conserver des historiques en cas d'erreurs.
Pour aller plus loin : Quels sont les avantages et les inconvénients de ces deux types de modèles ?
Lorsque vous travaillerez sur un projet, vous travaillerez la plupart du temps en local, sur votre machine. Dès que vous aurez terminé une fonctionnalité précise, vous aurez envie de la sauvegarde et de l'ajouter à votre projet. Pour cela, dans Git, vous effecturez un commit (pour enregistrer l'état de votre projet dans Git). Git prendra alors une photo de ce à quoi ressemblent tous les fichiers ajoutés à votre commit à ce moment et stockera une référence à cet instantané. C'est un point de sauvegarde de votre progression - Git enregistre les fichiers de votre projet et toutes les informations les concernant à un moment donné.
Le commit est donc l'unité fondamentale de Git. C'est l'action qui vous permettra de nourrir votre projet par l'ajout de nouvelles versions, les unes à la suite des autres.
On retrouve également le mot-clé repository ou repo dans sa version courte. Il désigne simplement des dossiers de travail. Ces répertoires peuvent être présent localement sur votre ordinateur ou en tant que copie distante (remote) sur un autre ordinateur/serveur. Un répertoire de votre machine suivi par Git sera appelé un dépôt et il évolura au fur et à mesure de votre travail et des commits réalisés.
Avant d'aller plus loin, commençons par mettre en pratique les différents points que l'on vient d'aborder.
TO DO :
git config --global user.name "Mon Nom" git config --global user.email
"votreemail@votreemail.com"
.git a bien été créé dans le dossier.~/Desktop mkdir usrs46
~/Desktop git init usrs46
Initialized empty Git repository in C:/Users/Azerolie/Desktop/usrs46/.git/
~/Desktop cd usrs46
~/Desktop/usrs46 (master) ls -a
./ ../ .git/
~/Desktop git status
On branch master
No commits yet
On apprend avec cette dernière commande que l'on se trouve sur la branche Master et qu'il n'y a pour le moment aucun commit. La branche Master est la seule disponible en début de projet, les commits vont s'organiser les uns derrière les autres (un commit parent, un comit enfant) pour former cette branche Master (voir l'illustration ci-dessous après la réalisation de 4 commits).
Pour aller plus loin : A quoi sert l'ajout de nouvelles branches et comment est-ce que ça fonctionne ?
Revenons à notre exemple, nous avons pour le moment une branche Master vide et aucun commit. Nous allons y remédier.
TO DO :
~/Desktop/usrs46 (master) touch helloworld.txt
~/Desktop/usrs46 (master) git status
[...]
Untracked files:
(use "git add ..." to include in what will be committed)
helloworld.txt
Git détecte qu'il y a un nouveau fichier dans le dépôt usrs46 mais que ce fichier n'est pas tracké par Git. C'est-à-dire qu'il n'est pas encore ajouté à votre branche master et qu'il n'est donc pas encore concerné par la gestion de version.
Nous allons ajouter ce fichier à un nouvel arbre appelé Index (ou encore zone de staging). Il sera important de faire la différence entre le premier arbre, qui correspond à l'espace de travail observé par Git (ici le dossier usrs46 physique et tout ce qu'il contient) et le deuxième arbre, Index, qui est une forme de virtualisation du premier avec uniquement les fichiers suivis par Git.
TO DO :
~/Desktop/usrs46 (master) git add helloworld.txt
~/Desktop/usrs46 (master) git status
[...]
Changes to be committed:
(use "git rm --cached ..." to unstage)
new file: helloworld.txt
Nous avons maintenant un fichier suivi par Git. La prochaine étape va être de l'envoyer dans un troisième arbre, encore un, appelé Head. C'est également un arbre en local sur votre machine qui contiendra cette fois tout l'historique de vos commits. Voyez le comme une base de données qui pointe en permanence vers le commit qui sera le parent du dernier commit (le plus souvent ce sera donc le dernier commit, le plus récent mais il est également possible de changer le pointeur de l'arbre Head pour repartir d'une version antérieure). C'est parti pour notre premier commit !
TO DO :
~/Desktop/usrs46 (master) git commit -m "Mon premier commit ! Un Hello World !"
[master (root-commit) fccac00] Mon premier commit ! Un Hello World !
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 helloworld.txt
La commande git commit prend alors tout le contenu des fichiers qui ont été indexés avec
git add et enregistre un nouvel instantané permanent dans la base de données HEAD. Notre branche Master
avance donc d'un commit en avant et pointe maintenant vers notre premier commit.
Pour bien comprendre, il faut revenir à la notion de commit et surtout de bon commit. Qu'est-ce qu'un commit de qualité au regard de git ? Est-ce que développer en sous-marin l'entièreté d'un projet et une fois celui-ci terminé, tout envoyé à Git en un seul commit est une bonne idée ? Laissez moi vous aiguiller : Non ! Non ! Et non ! C'est à l'opposé galactique de ce à quoi sert un logiciel de gestion de versions. Un bon commit doit répondre aux deux points suivants :
Il peut donc arriver, lorsque l'on travaille sur une nouvelle fonctionnalité, d'avoir à intervenir sur différents fichiers. Plusieurs fichiers peuvent donc être concernés par un même commit. Il est aussi possible de se rendre compte d'une erreur à un autre niveau ou encore d'une faute d'orthographe dans les textes que l'on s'empresse de corriger. Pourtant, ces actions n'ont rien à voir avec la fonctionnalité que l'on est en train de développer... Et bien notre zone de staging va nous servir de zone tampon, de zone de stockage. On y ajoute tous les fichiers concernant la fonctionnalité en cours sans ajouter les autres fichiers modifiés pour d'autres raisons également présent dans notre espace de travail. On prépare ainsi un paquet de fichiers qui a du sens et qu'on est prêt à envoyer en cadeau à Git avec une belle étiquette comme "Mise en place de la fonctionnalité BlaBla". On saura ainsi où aller chercher si on souhaite revenir à notre projet avant cette fonctionnalité.
En résumé :
git add, on demande à Git de suivre certains fichiers, c'est-à-dire de
prendre en charge la gestion de l'évolution de ces fichiers,git commit, nous demandons à Git d'enregistrer un snapshot, c'est-à-dire une
photographie instantanée de l'état des fichiers suivis et des les archiver dans une base de données (aucune des
versions précédentes n'est perdue).Nous avons maintenant sur notre arbre local, la dernière version de notre commit. Nous pourrions tout à fait continuer à travailler en local jusqu'à avoir complètement terminé la résolution d'un bug ou le développement d'une nouvelle fonctionnalité. Une fois ceci fait, nous sommes prêts à envoyer nos modificatins sur un serveur distant particulièrement utile lorsque l'on travaille sur plusieurs postes ou en équipe de plusieurs personnes. Une fois les modifications poussées sur le serveurs distants, elles seront accessibles de tous. Nous allons avoir besoin pour ça de configurer notre serveur distant, aussi appelé remote. Le plus utilisé aujourd'hui est GitHub, vous en aurez besoin dans le cadre de cette UE pour travailler ensemble et faire vos rendus. Je vous invite donc à vous créer un compte si vous n'en avez pas déjà un.
Une fois que vous aurez créer un compte, rendez-vous dans l'onglet "repositories" et cliquez sur "New". Vous pourrez ainsi ajouter un nouveau dossier, nommé usrs46 pour rester cohérent. Vous aurez le choix d'un dossier privé ou public (il faudra penser à mettre vos dossiers en public au moment de soumettre votre travail pour que je puisse le récupérer). Les configurations de bases sont suffisantes, vous pourrez donc cliquer sur "Create repository".
Parfait ! Vous avez maitenant un dossier usrs46 sur un serveur distant, prêt à recevoir votre travail ! Il ne reste plus qu'à configurer en local l'adresse de ce serveur pour pouvoir y envoyer vos modifications. Sur Github, placez-vous dans votre dossier usrs46
La partie qui nous intéresse est tout en haut, elle contient l'adresse url de votre serveur distant.
TO DO :
~/Desktop/usrs46 (master) git remote add origin
https://github.com/Azerolie/usrs46.git
~/Desktop/usrs46 (master) git remote -v
origin https://github.com/Azerolie/usrs46.git (fetch)
origin https://github.com/Azerolie/usrs46.git (push)
~/Desktop/usrs46 (master) git push origin master
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 236 bytes | 118.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/Azerolie/usrs46.git
* [new branch] master -> master
Si vous rencontrez une erreur fatal: protocol 'https' is not supported, c'est qu'au moment de
copier/coller l'url de votre serveur distant, vous avez aussi copié des caractères cachés qui empêchent la connexion.
Supprimez la configuration du serveur distant git remote remove origin et recommancez les étapes
précédentes en vous assurant d'écrire vous même l'url ou de supprimer les caractères cachés via un éditeur de texte
qui les détecte.
Vous devriez maintenant voir apparaître votre fichier hellowolrd.txt dans l'interface web de GitHub ainsi que le message de commit associé. Vous avez maintenant les bases de Git, il reste bien sur énormément de choses à découvrir mais vous êtes armés pour faire vos premiers pas avec ce logiciel de gestion de versions.