<preclass="src src-org">Tout d’abord, si tu veux la version PDF du bouzin, <spanstyle="color: #975D4A; text-decoration: underline;"><ahref="https://phundrak.fr/git/tutoriel-git.pdf">c’est par là</a></span>.
Et pour le code source de cette page, c’est <spanstyle="color: #975D4A; text-decoration: underline;"><ahref="https://github.com/Phundrak/tutoriel-git">là</a></span>, sur GitHub.
Git est un logiciel de version de fichiers permettant de garder une trace de toutes les modifications apportées au fichiers suivis dans un répertoire (un dépôt) et ses sous-répertoires –sous couvert qu’ils n’aient pas été ignorés explicitement. Il permet également de conserver plusieurs versions parallèles du projet, comme par exemple une version stable et une version de développement, et permet l’ajout de modifications d’une de ces versions parallèles à une autre via des fusions partielles ou totales de branches, avec une automatisation des fusions de fichiers lorsqu’il n’y a pas de conflit entre ces derniers.
Très bonne question Kevin. Tout d’abord, il faut t’assurer que git soit installé sur ton système et utilisable depuis le terminal. Sous GNU/Linux, tu peux l’installer via ton gestionnaire de paquet, ce qui rendra la commande accessible directement depuis le terminal.
</p>
<divclass="org-src-container">
<preclass="src src-text">$ apt install git # Debian, Ubuntu et les distros basées dessus
$ yum install git # CentOS
$ dnf -y install git # Fedora
$ pacman -S git # ArchLinux et les distros basées dessus
Si tu n’es pas sous GNU/Linux mais que tu as au moins le goût d’être sous un OS de type Unix, tu peux exécuter la commande correspondante à ton OS suivant:
$ port install git +svn +doc +bash_completion +gitweb # macOS avec MacPorts
</pre>
</div>
<p>
Si tu es sous Windows… Bonne chance. Toutes les commandes seront en syntaxe Unix dans ce tutoriel, mais si tu as bien deux neurones, tu devrais pouvoir tout de même suivre le tutoriel.
Tu peux configurer Git si tu le souhaites, oui. En général, il est recommandé de paramétrer au moins son nom et son email. Tu peux les paramétrer via la ligne de commande:
Tu peux aussi éditer le fichier <code>~/.gitconfig</code> comme suit:
</p>
<divclass="org-src-container">
<preclass="src src-text">[user]
email = ton@email.truc
name = Ton nom
</pre>
</div>
<p>
Cela permettra d’associer ton nom et ton adresse mail à tes commits. Par défaut, ceux qui sont enregistrés avec ton compte utilisateur de ton PC sont mis par défaut dans ces paramètres, mais on met quasiment tous un nom à la con quand on le créé. Et ça permet d’avoir les même paramètres si tu es sur un autre ordinateur.
</p>
<p>
Il y a encore pas mal de paramètres que tu peux gérer avec ce fichier, je reparlerai de certains plus tard, mais pour le reste, la documentation en ligne sur <code>gitconfig</code> ne manque pas.
Si tu souhaites créer un dépôt git, rien de plus simple: créé ton répertoire dans lequel tu travailleras, et déplace-y-toi. Ensuite, tu pourra initialiser ton dépôt via la commande <code>git init</code>.
</p>
<divclass="org-src-container">
<preclass="src src-text">$ mkdir monsuperprojet
$ cd monsuperprojet
$ git init
Initialized empty Git repository in /tmp/monsuperprojet/.git/
</pre>
</div>
<p>
Si tu obtiens à peu près le même message après la dernière commande, félicitations! Tu viens de créer ton premier dépôt git. En l’occurence, j’ai créé mon dépôt dans <code>/tmp</code>, mais toi tu peux voir un truc du genre <code>/home/corentin/monsuperprojet</code> à la place. Tu peux vérifier que tout va bien en rentrant la commande <code>git status</code>
</p>
<divclass="org-src-container">
<preclass="src src-text">$ git status
On branch master
No commits yet
nothing to commit (create/copy files and use "git add" to track)
Maintenant tu peux commencer à travailler sur ton projet. Mais tout d’abord, on va voir ce qu’il se passe si jamais on créé un fichier dans le dépot. Créé un fichier <code>main.c</code> dans lequel tu vas entrer ce code:
En exécutant à nouveau <code>git status</code>, on peut voir la sortie suivante:
</p>
<divclass="org-src-container">
<preclass="src src-text">$ git status
On branch master
No commits yet
Untracked files:
(use "git add <file>..." to include in what will be committed)
main.c
nothing added to commit but untracked files present (use "git add" to track)
</pre>
</div>
<p>
Tu commences à comprendre un peu le bail? Git vient de détecter qu’un nouveau fichier a été créé qu’il ne connaissait pas avant. Suivons ses bon conseils et ajoutons le fichier au dépôt.
</p>
<divclass="org-src-container">
<preclass="src src-text">$ git add main.c
$ git status
On branch master
No commits yet
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: main.c
</pre>
</div>
<p>
Super, maintenant git va surveiller les changements du fichier, mais attention, il n’a pas encore enregistré son état. Pour l’instant il sait juste que le fichier est là, dans un certain état, mais rien ne garanti encore qu’on pourra retrouver cet état plus tard. On appelle ça le <i>staging</i>. Pour ce faire, il faut créer ce qu’on appelle un commit. En gros, il s’agit d’un enregistrement des modifications apportées à un ou plusieurs fichers (dans leur globalité ou partiellement, on verra ça plus tard), le tout avec un commentaire.
</p>
<divclass="org-src-container">
<preclass="src src-text">$ git commit -m "Un petit pas pour moi, un grand pas pour mon projet"
[master (root-commit) 89139ef] Un petit pas pour moi, un grand pas pour mon projet
1 file changed, 6 insertions(+)
create mode 100644 main.c
</pre>
</div>
<p>
Parfait! Certains éléments peuvent être un peu différent chez toi, comme par exemple la référence du commit juste avant le message. Ça, c’est un truc qui est géré automatiquement par git. Et voilà, on a l’état de notre répertoire qui est enregistré et qui sera disponible plus tard. Maintenant, tu sais comment enregistrer des état de ton dépôt via les commits.
Si jamais tu as un staging que tu veux annuler, tu peux utiliser la commande <code>git reset HEAD nomdetonfichier voiredautresfichiers</code> pour annuler le staging. Une fois le fichier qui n’est plus dans ton staging, tu peux même annuler toutes les modifications que tu as apporté au fichier depuis ton dernier commit avec la commande <code>git checkout -- tonfichier voiredautresfichiers</code>. Par exemple, si j’ai modifié mon <code>main.c</code> en modifiant ainsi les arguments du <code>main()</code> :
Si jamais tu veux à la place ajouter la modification d’un fichier au dernier commit (mettons, tu as oublié d’ajouter également un fichier texte), tu peux utiliser l’option <code>--amend</code> lors du commit du fichier oublié.
</p>
<divclass="org-src-container">
<preclass="src src-text">$ git add main.c # J’ai refait les modifications annulées plus tôt
$ git commit -m "second commit"
[master 97f698a] second commit
1 file changed, 1 insertion(+), 1 deletion(-)
$ echo "C’est un super projet !" > projet.txt
$ git add projet.txt
$ git commit --amend -m "second commit + oubli"
[master 9aff4c0] second commit + oubli
Date: Fri Oct 5 11:10:56 2018 +0200
2 files changed, 2 insertions(+), 1 deletion(-)
create mode 100644 projet.txt
</pre>
</div>
<p>
En gros, le commit que tu viens de faire a remplacé le précédent en conservant les informations du commit précédent, mis à part son commentaire. Si tu ne met pas l’option <code>-m "ton texte"</code> lors de l’amendement du commit, ton éditeur texte par défaut va s’ouvrir pour que tu puisses modifier le texte du commit précédent si tu le souhaite. Si jamais vi ou vim s’ouvre et que tu n’as aucune idée de comment sortir de cet enfant du démon, tu as juste à appuyer sur la touche Échap (au cas où), puis à taper <code>:wq</code> (<code>w</code> pour écrire le fichier, <code>q</code> pour quitter), puis tu appuye sur la touche Entrée. Si tu as Nano qui s’est ouvert, alors il faut taper Ctrl-X.
Pas de panique! Tu peux entrer la commande <code>git diff</code> afin de voir ce que tout ce que tu as modifié lors de ton dernier commit. Et si tu ne souhaite voir les modifications que d’un certain fichier, tu peux ajouter le nom de ton fichier à la fin de la commande.
</p>
<divclass="org-src-container">
<preclass="src src-text">$ echo "C’est un super projet !" > projet.txt
$ git diff
diff --git a/projet.txt b/projet.txt
index 03b0f20..b93413f 100644
--- a/projet.txt
+++ b/projet.txt
@@ -1 +1 @@
-projet
+C’est un super projet !
</pre>
</div>
<p>
Tu peux également voir les différences de fichiers entre deux commits en entrant leur référence. Pour avoir la référence, tu peux rentrer la commande <code>git log</code> pour avoir un petit historique des commits.
Un petit pas pour moi, un grand pas pour mon projet
</pre>
</div>
<p>
Bon, c’est un peu long et un peu trop d’infos d’un coup, généralement je préfère taper <code>git log --oneline --graph --decorate</code> afin d’avoir un affichage comme suit:
Dans ce cas, il est grand temps de te présenter le fichier <code>.gitignore</code>. Comme son nom l’indique, il permet au dépôt d’ignorer des fichiers selon ce que tu lui indiqueras. Par exemple, si tu veux ignorer tous les fichiers qui se terminent en <code>.out</code> (ou <code>.exe</code> sous Windows), tu peux éditer (ou créer) ton <code>.gitignore</code> et entrer ces lignes:
</p>
<divclass="org-src-container">
<preclass="src src-text">*.out
*.exe
</pre>
</div>
<p>
Maintenant, si tu créés un fichier en <code>.out</code> ou <code>.exe</code>, il sera complètement ignoré par git et ne sera pas stocké dans l’historique des versions.
Tu commences à me plaire Enzo! GitHub est un site web sur lequel tu peux héberger des projets libres ou open-source (si tu ne connais pas la différence, voici <ahref="https://www.gnu.org/philosophy/open-source-misses-the-point.fr.html">un article</a> pour t’aider à comprendre, et <ahref="https://www.gnu.org/philosophy/free-software-for-freedom.fr.html">un autre</a> pour la route). C’est en particulier orienté pour les projets gérés par git, ce qui tombe bien car c’est ce qu’on utilise. Cela a pour avantage de pouvoir aisément partager ton code et d’assurer qu’il est bien sauvegardé quelque part d’autre que ton disque dur (un <code>rm -rf</code> est si vite arrivé). Et surtout, ça peut te permettre de collaborer avec d’autres personnes sur le même projet sans te casser la tête.
Ou bien, tu peux télécharger le projet directement via <code>git</code>. Eh oui! git permet de gérer les dépôts dits distants, c’est à dire ceux qui sont hébergés sur un serveur en ligne, comme par exemple sur GitHub. Pour cela, il te faut te munir du lien vers le dépôt git, et le passer en argument de <code>git clone</code>. Par exemple, si tu veux télécharger de dépôt du petit logiciel de chat en réseau que j’ai codé durant ma L2 d’informatique, tu peux exécuter ceci:
Dans ce cas là, c’est simple Brigitte. Il faut que tu te créés un compte sur GitHub, puis tu cliques sur le bouton <code>+</code> et <code>New Repository</code>. Tu lui donnes le nom que tu souhaites (en l’occurence je le nomme <code>temporary-repo</code> car je vais le supprimer cinq minutes après l’écriture de ces lignes), et tu cliques sur <code>Create Repository</code>. Tu n’ajoutes rien avant, pas de description, pas de <code>.gitignore</code>, RIEN.
Bon ok, ce n’est pas aussi simple que ça. Une fois que tu as lié ton dépôt au dépôt distant, il faudra que tu mettes en ligne tes commits quand tu en auras l’occasion. Pour ce faire, tu n’as qu’à taper <code>git push</code> ; et la première fois, il faudra que tu indiques à ton dépôt où mettre en ligen précisément dans le dépôt distant, auquel cas tu ajoutes <code>-u origin master</code> pour cette première fois. Git te demandera donc tes identifiants GitHub pour pouvoir mettre tout ça en ligne.
Branch 'master' set up to track remote branch 'master' from 'origin'.
</pre>
</div>
<p>
Bon, là en nom d’utilisateur y’a le mien, faudra remplacer avec le tiens. Et ouais, ma vitesse de mise en ligne n’est pas fameuse, je suis sur une connexion 3G+ à l’heure où j’écris ces lignes, ne me juge pas. Bref, toujours est-il que je viens de mettre en ligne les fichiers du dépôt sur GitHub. Pas la peine de chercher le mien sur GitHub par contre, ça fera un bail que je l’aurai supprimé au moment où tu liras ces lignes.
Pour faire un exemple, je viens de créer un <code>README.md</code> sur GitHub directement. Ce type de fichiers est assez standard afin de présenter plus ou moins en détails le dépôt et le projet qui y est lié, et son contenu apparaitra formatté sur la page du dépôt sur GitHub s’il est au format <code>.md</code> (Markdown) ou <code>.org</code> (org-mode, le Markdown d’Emacs avec lequel est écrit ce tutoriel). Mais il n’est pas présent dans mon dépôt local, du coup je vais devoir le récupérer. On va donc entrer <code>git pull</code>.
