Git : les bases pour un code plus sûr et propre

Lorsque l’on développe sur un projet, seul ou à plusieurs, une bonne pratique est d’utiliser un logiciel comme Git.

En effet, celui-ci offre la possibilité de stocker le code ailleurs que sur votre ordinateur ou une clé USB (pas pratique pour travailler avec vos camarades/collègues), de travailler sur différents fichiers en même temps que d’autres personnes et garder un historique de toutes les modifications des fichiers.

Git appartient à la famille des VCS (Version Control System) ou logiciel de gestion de versions qui sont pensés pour le travail collaboratif.

Qu’est-ce que Git ?

Git est un logiciel libre et open-source créé par Linus Torvalds, le créateur du noyau Linux.
Git ne repose pas sur un serveur centralisé car il utilise un système Peer2Peer. Cependant, il est très souvent utilisé avec un serveur intermédiaire comme Gitlab ou encore Github qui sont des services d’hébergement de code et sont compatibles avec les systèmes VCS.

Un logiciel similaire à Git est Mercurial même si Git reste le plus utilisé à ce jour.

Avantages d’utiliser un VCS

Toutes les versions de fichiers sont au même endroit.
Traçabilité des modifications et historique de tous les changements.
Sauvegarde du code sur plusieurs ordinateurs / serveurs.
Partage du code de manière publique ou privé.

Et bien d’autres avantages que vous trouverez par vous-mêmes en fonction de votre utilisation !

Installation de Git

Git est disponible quasiment partout et pour l’installer, rien de plus simple :

rendez-vous sur https://git-scm.com/downloads.
sélectionnez votre système d’exploitation.
pour Linux/Unix, la suite des étapes sont précisées et pour Windows et Mac, ça déroule tout seul.

Premiers pas avec Git

La première chose à faire sur votre machine est de définir votre nom d’utilisateur et votre adresse email afin que dans l’historique nous puissions identifier qui a modifié quoi.

Pour ça, il suffit de rentrer dans votre terminal les commandes :

git config --global user.name "Votre_pseudo" 
git config --global user.email "votre_adresse@email.com"

Maintenant, deux options s’offrent à vous. Vous pouvez commencer à versionner un tout nouveau projet ou un code existant. Pour la suite, j’utiliserai Gitlab mais sachez que Github ou Bitbucket fonctionnent de la même manière et vous donnent les commandes de départ pour initialiser un projet.

Versionner un tout nouveau projet

Créez-vous un compte sur Gitlab puis cliquer sur New Project. Vous verrez qu’il y a plusieurs options, nous allons choisir « Create Blank Project« .

Pour ma part :

project_name : article_safecode
project_slug : article_safecode (il se génére tout seul mais vous pouvez l’éditer)
description : (optionnel)
visibility_level : comme vous voulez, l’un est visible pour tout le monde, l’autre n’est que pour vous et les personnes que vous invitez.

Cochez Initialize repository with a README.

Désormé notre projet est initialisé et hébergé sur Gitlab avec, pour l’instant, un fichier nommé README.md. C’est un fichier en Markdown qui permet de fournir des informations sur le projet (documentation, description du projet, mise à jour, etc). Notre projet est en fait un Dépot aussi appelé Repository.

Maintenant, il nous suffit de cloner le projet sur notre ordinateur en cliquant sur le bouton clone, alors vous pouvez choisir en SSH ou en HTTPS. Pour la suite j’utiliserai HTTPS mais si vous souhaitez utiliser SSH, il vous suffit de renseigner votre clé publique dans les paramètres.

Le clone créera un dossier avec le nom du projet, pour moi ça sera donc un dossier nommé article_safecode.

git clone https://gitlab.com/thibault/article_safecode.git

On me demande alors mon username Gitlab et mon mot de passe :

Cloning into 'article_safecode'...
Username for 'https://gitlab.com': 
Password for 'https://thibault@gitlab.com': 
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), 223 bytes | 223.00 KiB/s, done.

Versionner un code existant

Pour versionner un code existant vers un hébergeur, il faut d’abord créer le repository sur Gitlab mais sans initialiser le README.md.

Comme le repository est totalement vide, Gitlab est gentil et vous donne les commandes à effectuer.

La partie qui nous intéresse est Push an existing folder. En local, je me suis créé un dossier nommé article_safecode avec un fichier hello_world.txt.

cd existing_folder
git init
git remote add origin https://gitlab.com/thibault/article_safecode.git
git add .
git commit -m "Initial commit"
git push -u origin master

Et le tour est joué ! Pour les commandes, ne vous inquiétez pas, on va les voir en détail par la suite.

Qu’est-ce que git init ?

La commande git init est assez explicite, elle permet d’initialiser git (et plus particuliérement .git dans le répertoire courant.

git init
Initialized empty Git repository in /home/thibault/Downloads/article_safecode/.git/

Voilà ce qu’il y a dans le dossier que la commande génére :

$ tree
.
├── branches
├── config
├── description
├── HEAD
├── hooks
│   ├── applypatch-msg.sample
│   ├── commit-msg.sample
│   ├── fsmonitor-watchman.sample
│   ├── post-update.sample
│   ├── pre-applypatch.sample
│   ├── pre-commit.sample
│   ├── pre-merge-commit.sample
│   ├── prepare-commit-msg.sample
│   ├── pre-push.sample
│   ├── pre-rebase.sample
│   ├── pre-receive.sample
│   └── update.sample
├── info
│   └── exclude
├── objects
│   ├── info
│   └── pack
└── refs
    ├── heads
    └── tags

Cette commande n’est utile que si vous initialisez un git. Si vous rejoignez un projet, vous n’aurez pas à l’utiliser.

Git remote add origin

Cette commande est aussi à faire uniquement lorsque vous liez votre projet à un repository et non lorsque vous rejoignez un projet. Elle permet d’associer l’origin avec en paramètre l’url du projet.

Git clone

Cette commande permet de cloner le repository distant vers votre machine.

git clone https://gitlab.com/votre_pseudo/votre_projet.git

Qu’est-ce que git add ?

La commande git add permet d’ajouter des fichiers modifiés à la zone de staging (d’attente) qui est souvent suivi d’un message et d’un envoi vers le serveur Gitlab. À la suite de cette commande, le paramètre est le fichier en question.

git add . # ajoute tous les fichiers modifiés du répertoire courant

Dans le cas précédent, nous aurions pu faire aussi :

git add hello_world.txt # ajoute à la zone de staging uniquement ce fichier

Pour en ajouter plusieurs on ajoute les noms de fichiers à la suite :

git add bye_bye.txt test.txt # De la même manière vous pouvez ajouter plusieurs fichiers simultanément ou non

Status des fichiers avec git status

git status # vous donne un aperçu de l'état local

Exemple de retour de commande :

$ git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
	new file:   bye_bye.txt
	new file:   test.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	hello_world.txt

On peut remarquer tout en haut le nom de la branche, c’est un concept que nous allons voir par la suite. Pour l’instant il n’y a qu’une branche : master.

Nous voyons les fichiers qui ont été ajoutés au suivi mais qui n’ont pas de commit (c’est un message qui est associé à la modification).

En dessous la partie untracked files sont les fichiers qu’on n’a pas add.

Valider des modifications avec git commit

$ git commit -m "ajout du chiffrement"
[master (root-commit) ed96f08] ajout du chiffrement
 2 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 bye_bye.txt
 create mode 100644 test.txt

Cette commande permet d’ajouter un message aux fichiers qui étaient dans la zone de staging tout en validant les modifications. Le paramètre -m permet d’ajouter un message à la suite, sinon votre éditeur par défaut s’ouvrira pour écrire ledit message.
Pour plus d’informations sur les paramètres :

man git-commit

Si on refait un git status on ne voit plus rien dans la zone de staging :

On branch master
Untracked files:
  (use "git add <file>..." to include in what will be committed)
	hello_world.txt

nothing added to commit but untracked files present (use "git add" to track)

Si, par mégarde, le message du dernier commit que vous venez d’effectuer contient une erreur ou que vous souhaitez le modifier, c’est possible avec la commande :

git commit --amend

Récupérer le code distant avec git pull

Si quelqu’un d’autre a travaillé sur le code et l’a envoyé sur le serveur distant, vous pouvez récupérer son travail avec la commande :

git pull

De gitlab, j’ai ajouté un fichier salut.md. Voilà donc le résultat :

remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), 299 bytes | 299.00 KiB/s, done.
From gitlab.com:thibault/article_safecode
   ab19447..2509b9f  master     -> origin/master
Updating ab19447..2509b9f
Fast-forward
 salut.md | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 salut.md

Envoyer son code avec git push

Une fois que les fichiers ont été commit, vous pouvez push (pousser) votre code sur Gitlab avec la commande :

git push

Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Delta compression using up to 4 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 258 bytes | 258.00 KiB/s, done.
Total 2 (delta 0), reused 0 (delta 0)
To gitlab.com:thibault/article_safecode.git
   c3a3b79..a801f8e  master -> master

Qu’est-ce que le .gitignore ?

Le fichier .gitignore est un endroit où vous pourrez écrire les chemins de tous les fichiers que vous ne souhaitez pas versionner. Ces fichiers ne seront jamais sur Gitlab et vos collègues n’auront jamais accès à ces fichiers.

Ce fichier est très pratique. Si vous utilisez un IDE comme Visual Studio Code ou Phpstorm, des fichiers qui sont propres à votre configuration d’éditeur de texte sont générés et les versionner n’est pas toujours souhaitable.
Dans le même style, si vous installez des dépendances, versionner le fichier ./vendors n’est pas nécessaire.

Ce fichier doit être spécifié dans tous les projets versionnés, fort heureusement, vous pouvez aussi avoir une configuration globale, car certaines informations sont redondantes à tous les projets. Par exemple, lorsque vous êtes sur Mac, vous ne voulez pas versionner le fichier .DS_Store qui est un fichier qui gère des informations telles les options d’affichage du dossier, la position des icônes et d’autres informations visuelles.

Pour ce faire il vous suffit d’exécuter la commande :

# Sur Linux, Mac et Git Bash Windows :
git config --global core.excludesfile ~/.gitignore
# Sur Windows : 
git config --global core.excludesfile "%USERPROFILE%\.gitignore"

Vous pourrez retrouver ce chemin à tout moment avec la commande :

git config --global core.excludesFile

Désormais on peut l’éditer (vim ) et ajouter la règle globale : je continue donc avec mon ancien exemple :

vim ~/.gitignore

# Global gitignore
.DS_Store

Les branches

Petite pause dans la liste des commandes utiles pour vous expliquer le concept des branches.

source de la photo

Actuellement, tout ce que vous avez fait est sur la branche MASTER, la branche en vert. Vous avez peut-être aperçu dans les retours des différentes commandes parfois ce terme master.
C’est la branche créée par défaut.

Pour comprendre l’intérêt de travailler avec des branches, laissez-moi contextualiser :

Vous arrivez dans une nouvelle entreprise qui développe des sites web. Chaque site est versionné dans un repository. Votre première mission est d’ajouter une fonctionnalité de vidéo conférence dans l’un d’eux mais un autre employé est entrain d’effectuer une refonte graphique depuis trois jours. Heureusement, cet employé a créé une nouvelle branche en partant de master, la version stable du code.

Vous allez donc faire de même en partant de la branche master pour avoir une base de code saine. Une fois que vous aurez terminé votre fonctionnalité vous pourrez merge votre branche vers celle de master. C’est lorsque votre branche rejoint la branche master (cf schéma).

Voir les branches existantes avec git branch

Pour voir les différentes branches, il y a la commande :

$ git branch
* master

J’ai une liste de branche, ici une seule, avec un curseur qui est l’étoile, elle m’indique sur quelle branche je suis.

Créer une branche avec git checkout -b

Pour créer une nouvelle branche il faut saisir :

$ git checkout -b ma_nouvelle_branche
Switched to a new branch 'ma_nouvelle_branche'

La paramètre -b permet de créer une nouvelle branche.
Désormais on peut voir que le git branch affiche :

$ git branch
* ma_nouvelle_branche
  master

J’ai donc créé une branche nommée ‘ma_nouvelle_branche’ et je me suis déplacé dessus.

Se déplacer d’une branche à une autre avec git checkout

On a vu que git checkout -b crée une branche et nous déplace dessus. C’est normal car c’est le but premier de checkout.

Si je veux revenir sur la branche master, il me suffit de l’indiquer ainsi :

$ git checkout master
Switched to branch 'master'
Your branch is up to date with 'origin/master'.

Sauvegarder momentanément son travail avec git stash

Encore une fois, je contextualise avec l’exemple des sites web pour que vous compreniez l’intérêt. Vous avez fait beaucoup de modifications sur votre branche, vous avez poussé (push) les quelques nouvelles fonctionnalités qui fonctionnent sur votre branche pour sauvegarder votre travail. Le chef de projet arrive pour voir sur votre environnement de développement ces nouvelles fonctionnalités mais vous êtes de nouveau en train de développer d’autres fonctionnalités qui rendent les anciennes non fonctionnelles.

La commande git stash va permettre de sauvegarder et mettre de côté vos modifications.

Ici, le travail en cours de modification est mon fichier bye_bye.txt.

$ git status
On branch master
Your branch is up to date with 'origin/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:   bye_bye.txt

no changes added to commit (use "git add" and/or "git commit -a")

Si je fais la commande git stash :

$ git stash
Saved working directory and index state WIP on master: 2509b9f Update salut.md

De nouveau si je fais git status.

On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean

Mes modifications n’apparaissent plus.

Restaurer son travail momentanément sauvegarder avec git stash apply

Une fois que le chef de projet a fini de voir les nouvelles fonctionnalités, je peux restaurer les fichiers avec la commande git stash apply.

$ git stash apply
On branch master
Your branch is up to date with 'origin/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:   bye_bye.txt

no changes added to commit (use "git add" and/or "git commit -a")

La commande effectue un git status en même temps pour me montrer que le fichier est restauré.

Conclusion

L’article commence à se faire long et le but n’est pas d’énumérer toutes les commandes ainsi que tous les paramètres. Mes deux objectifs primordiaux via ce billet étaient de vous faire comprendre l’importance de Git dans un projet collaboratif en vous donnant les quelques commandes de bases pour que vous puissiez commencer à vous amuser et jouer avec ce super outil.

D’un autre côté mon but était de vous faire comprendre à quel point cet outil était puissant et nécessaire pour sécuriser, sauvegarder et historiser les différentes versions de son code. C’est donc à mes yeux un outil qui contribue à la sécurité informatique quand il est bien utilisé. Attention de ne jamais push les mots de passe, clés API, etc !

Safecode