Tutoriel de démarrage avec Git

mercredi 18 décembre 2019, par _Eric_

Sommaire

Introduction
Initier un dépôt Git local
- Initier un dépôt à partir d’un répertoire vide
- Cloner un dépôt distant
Consigner les modifications du dépôt local
Pousser les modifications locales sur un dépôt distant

Introduction

Ce tutoriel a pour but de vous familiariser avec les commandes de base et les cas d’usage simples que vous rencontrerez souvent. Il illustre tous les changements d’états décrits dans la figure suivante :

Tous les tutoriels se déroulent en ligne de commande pour continuer l’apprentissage des fondements de Git sans le décor et les raccourcis mise en place par les GUI.

Initier un dépôt Git local

Il y a deux façons d’initier un projet local sous Git : en partant juste d’un répertoire travail vide ou en récupérant (on dit cloner en Git) un dépôt distant. Ce tutoriel adresse successivement les deux cas.

Initier un dépôt à partir d’un répertoire vide

On commence par créer le répertoire de travail monprojet/ à la racine de l’utilisateur par exemple et on se rend dans le nouveau répertoire créé.

$ cd ~
$ mkdir monprojet
$ cd monprojet

Ensuite, on initie la gestion du projet sous Git en lançant la commande git init.

$ git init
Initialized empty Git repository in /Users/eric/monprojet/.git/

De fait, le répertoire .git/ a été créé et initialisé. Vous pouvez naviguer à l’intérieur pour étudier sa structure et noter que la zone d’index (fichier .git/index) n’est pas encore créé et qu’il existe bien un fichier .git/config comme indiqué dans l’article Configuration de Git. La zone de travail est encore vide mais tout est prêt pour commencer à développer votre projet.

En lançant la commande git status on obtient les informations suivantes :

$ git status
On branch master
No commits yet
nothing to commit (create/copy files and use "git add" to track)

Il est important de noter que sans précision, la branche créée par défaut en local s’appelle « master ». C’est la seule qui existe à cet instant.

Cloner un dépôt distant

Pour ce tutoriel on considère que l’accès à la forge SPIP (ici les plugins) est autorisé. Si ce n’est pas le cas, il vous faudra demander l’accès à la forge et faire la configuration SSH comme expliqué dans l’article Configuration de Git.

On se propose donc de cloner le plugin Rainette en local. Pour ce faire, on se positionne à la racine de l’utilisateur et on utilise la commande git clone en fournissant l’URL du dépôt :

$ git clone git@git.spip.net:plugin/rainette.git
Cloning into 'rainette'...
remote: Counting objects: 2603, done.
remote: Compressing objects: 100% (886/886), done.
Receiving objects:  79% (2057/2603), 2.37 MiB | 4.73 MiB/seceiving objects:  78% (2031/2603), 2.37 MiB | 4.73 MiB/s
Receiving objects: 100% (2603/2603), 2.82 MiB | 5.02 MiB/s, done.
Resolving deltas: 100% (1643/1643), done.

Etant donné qu’on n’a pas précisé le répertoire destination, Git a créé le répertoire de travail ~/rainette/ et l’a peuplé avec une copie des fichiers de la dernière version du plugin. On peut aussi noter la création du ./git qui contient quasiment toutes les données dont le serveur dispose. Toutes les versions de tous les fichiers pour l’historique du projet sont téléchargées.

En lançant un git status à partir du répertoire rainette/ on obtient :

$ git status
On branch master
Your branch is up to date with 'origin/master'.
nothing to commit, working tree clean

Il est à noter que la branche locale se nomme encore « master » et que la branche distante d’où provient les fichiers extraits se nomme par défaut « origin/master ».

Consigner les modifications du dépôt local

Ce tutoriel explique comment ajouter des fichiers au dépôt Git et enregistrer les modifications sur des fichiers existants. Les exemples choisis permettent d’illustrer les différents états des fichiers décrits dans l’article Les bases de l’utilisation de Git.

Ajouter un fichier au dépôt Git

Reprenons le premier tutoriel avec notre répertoire de travail ~/monprojet/ vide à l’exception du répertoire de base Git (.git/). Ajoutons un fichier README.md dans le répertoire de travail et lançons la commande git status.

$ git status
On branch master
No commits yet
Untracked files:
  (use "git add <file>..." to include in what will be committed)
	README.md
nothing added to commit but untracked files present (use "git add" to track)

Git a bien détecté l’ajout du fichier README.md dans la zone de travail mais indique qu’il est non suivi (untracked) et qu’il est possible d’utiliser la commande git add pour l’inclure dans les fichiers suivis :

$ git add README.md
$ git status
On branch master
No commits yet
Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
	new file:   README.md

Le fichier README.md vient de passer dans l’état indexé (staged) : il est donc prêt à être validé (commited) et à être intégré dans le premier instantané (commit) de Git. On lance donc la commande git commit en n’oubliant pas de préciser un message :

$ git commit -m "ajout du fichier readme"
[master (root-commit) 8049316] ajout du fichier readme
 1 file changed, 2 insertions(+)
 create mode 100644 README.md
$ git status
On branch master
nothing to commit, working tree clean

Dans la commande git commit le fichier a été omis ce qui enjoint Git de valider tout le contenu de la zone d’index qui cette fois est réduit au fichier README.md. La commande git status confirme que la branche « master » ne contient plus de modifications non intégrées au dépôt.

Modifier un fichier suivi par Git

Supposons maintenant que nous souhaitions faire des corrections dans notre fichier README.md. On édite le fichier et on y rajoute une ligne par exemple. On sauvegarde et on lance la commande git status :

$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   README.md
no changes added to commit (use "git add" and/or "git commit -a")

Git a bien détecté un changement sur un fichier suivi dans le dépôt et il le précise en disant que le changement n’est pas indexé (not staged). Il est donc nécessaire d’utiliser encore la commande git add pour insérer la modification dans la zone d’index afin qu’elle soit prise dans le prochain commit :

$ git add README.md
$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   README.md

Git nous informe que le fichier README.md est prêt à être validé (to be committed). On lance donc la commande git commit avec un message :

$ git commit -m "première modification du fichier readme"
[master 6c1d1c9] première modification du fichier readme
 1 file changed, 1 insertion(+)
$ git status
On branch master
nothing to commit, working tree clean

Pour visualiser notre travail jusqu’à maintenant on lance la commande git log qui fournit la liste des commits effectués sur la branche master de notre dépôt classés du plus récent au plus ancien :

$ git log
commit 6c1d1c9d6ea265117da0ea8d523c9ae4b2bad111 (HEAD -> master)
Author: Jean Martin <jean@martin.net>
Date:   Wed Dec 18 16:09:53 2019 +0100
    première modification du fichier readme

commit b5d9bd0a40d88d6bfeeefb6d47cc9a94a8715d0c
Author: Jean Martin <jean@martin.net>
Date:   Wed Dec 18 14:24:07 2019 +0100
    ajout du fichier readme

Supprimer un fichier suivi par Git

Avant de démarrer le tutoriel, il faut adapter notre zone de travail sous Git en rajoutant deux fichiers quelconques sous suivi Git (copie des fichiers, git add et git commit) :

$ git add *.txt
$ git commit -m "ajout de 2 fichiers a supprimer"
[master 5e5763e] ajout de 2 fichiers a supprimer
 2 files changed, 146 insertions(+)
 create mode 100644 INSTALL.txt
 create mode 100644 htaccess.txt

Pour supprimer l’un des deux fichiers, le premier réflexe est d’envoyer le fichier dans la corbeille de son explorateur/finder ou d’utiliser le shell avec la commande rm. Lançons donc la commande shell rm sur l’un d’eux et regardons le résultat sur le dépôt :

$ rm htaccess.txt
$ git status
On branch master
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	deleted:    htaccess.txt
no changes added to commit (use "git add" and/or "git commit -a")

Comme on pouvait s’y attendre, même si le fichier a bien disparu de la zone de travail Git considère que cette modification n’est pas prête à être enregistrée et considère toujours le fichier htaccess.txt comme étant suivi sous. Il faut donc encore une fois, indexer la modification par git add et l’enregistrer dans le dépôt Git avec git commit.

$ git add htaccess.txt
$ git commit -m "suppression du fichier htaccess"
[master 6dea8f5] suppression du fichier htaccess
 1 file changed, 133 deletions(-)
 delete mode 100644 htaccess.txt

Néanmoins, il est possible de réaliser cette opération autrement en utilisant uniquement des commandes Git. La commande git rm supprime le fichier physiquement de la zone de travail et indexe la suppression dans la zone d’index. Ensuite la commande git commit va enregistrer la suppression dans le dépôt.

$ git rm INSTALL.txt
$ rm 'INSTALL.txt'
$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	deleted:    INSTALL.txt
$ git commit -m "suppression du fichier INSTALL par git rm"
[master d14d34a] suppression du fichier INSTALL par git rm
 1 file changed, 13 deletions(-)
 delete mode 100644 INSTALL.txt

Pour conclure, on peut afficher le contenu de notre répertoire de travail et lancer un git log pour consulter tous les commits effectués depuis le début de ce tutoriel :

$ ls -l
total 8
-rw-r--r--@ 1 jean  staff  74 18 déc 19:32 README.md
$ git log
commit d14d34a28cc8bbe8cbf153e0ab1a6a0a97a766c8 (HEAD -> master)
Author: Jean Martin <jean@martin.net>
Date:   Wed Dec 18 21:09:39 2019 +0100
    suppression du fichier INSTALL par git rm

commit 6dea8f5a2e422cef94ea398ec001e8b08384e751
Author: Jean Martin <jean@martin.net>
Date:   Wed Dec 18 20:51:11 2019 +0100
    suppression du fichier htaccess

commit 5e5763e3db5c128b96dac6c3474af0151db2a9bf
Author: Jean Martin <jean@martin.net>
Date:   Wed Dec 18 20:44:32 2019 +0100
    ajout de 2 fichiers a supprimer

commit 0897426ef844462048157ab32c44eefdb666aec3
Author: Jean Martin <jean@martin.net>
Date:   Wed Dec 18 19:34:06 2019 +0100
    premiere modification du fichier readme

commit 804931660f1f9681ba11a92f077f910413f75e56
Author: Jean Martin <jean@martin.net>
Date:   Tue Dec 17 20:38:40 2019 +0100
    ajout du fichier readme

Pousser les modifications locales sur un dépôt distant

Supposons que nous avons cloné un dépôt de la forge SPIP et fait des modifications en locales, modifications que nous avons bien validées dans la branche master locale. Même si Git nous permet de travailler aisément en local il arrive un moment où il faut partager nos modifications avec le dépôt distant. On dit alors qu’on pousse (push) les modifications locales sur le serveur.

La commande pour ce faire est la suivante :

$ git push origin master
...

On reconnait le serveur distant origin et la branche locale dont on pousse les modifications, à savoir, master (origin et master sont créés par défaut lors de la commande git clone, voir le début de l’article). Cette commande ne fonctionne que si vous avez cloné depuis un serveur sur lequel vous avez des droits d’accès en écriture et si personne n’a poussé dans l’intervalle. Mais nous reviendrons sur ce sujet dans l’article sur la gestion des branches.

La Taverne à Tonton