owned this note
owned this note
# Versionnez vos Projets artistiques « numériques »
## Introduction
Aujourd’hui, il est très intéressant pour un artiste de respecter un certain workflow dans son travail (et/ou dans sa passion) afin de gagner en productivité et en qualité. Je vous propose dans cet article un certain nombre d’outils et de techniques afin d’y parvenir.
N’hésitez pas vous aussi à proposer votre méthode de travail, car dans un domaine aussi vaste que « l’art », il existe une quantité illimitée d’outils ou de workflow différents, parfois plus adaptés à un domaine spécifique.
La musique, la photo, la vidéo, l’informatique, etc... Si vous utilisez des outils de production audio comme Ableton, FL Studio, etc… Ou des outils de production graphique pour faire des traitements sur la photo ou la vidéo comme le permet la suite Adobe, la suite Sony, la suite Kodak, etc… Vous allez pouvoir versionner votre travail (vos fichiers) dans le temps. En d’autres termes, vous obtiendrez une sorte d’arbre avec des dizaines de versions de vos fichiers au fur et à mesure du temps. Un seul projet pourrait même donner lieu à différentes releases. (Plusieurs titres, albums, images ou films)
<center>
<figure>
<img src="https://i.imgur.com/2KqW6ng.png" alt="Exemple de Workflow" />
<figcaption>Exemple de Workflow</figcaption>
</figure>
</center>
Ces outils sont énormément employés dans le domaine de l’informatique (développement ou infrastructure) car ils permettent aussi de garder une trace de qui a fait quoi lorsqu’on travail en équipe.
## Cloud storage
Une première solution consiste à utiliser des outils de sauvegarde en cloud. Ils vous permettent également de versionner, de partager ou de travailler en collaboration avec plusieurs personnes.
### Exemple avec [on-your.cloud](https://on-your.cloud) :
- Partager vos fichiers et dossiers :
<center>
</center>
Vous pouvez rendre un fichier public, ou le partager de manière privée. Vous gérez alors les droits d’accès sur ce fichier et vous pouvez par exemple n’autoriser qu’une personne en lui demandant de s’identifier ou de saisir un Mot de passe.
- Retrouver une ancienne version d’un fichier ou dossier :
<center>
</center>
Vous pouvez renvoyer sans cesse un même fichier sur votre serveur et chaque version sera conservée. Si vous souhaitez retrouver une ancienne version par exemple, il vous suffit de dupliquer le fichier et de revenir en arrière sur l’original.
## Le versioning pour les pros !
Ce domaine est très en vogue actuellement dans certaines disciplines, mais sachez qu’il existe depuis la création des fichiers informatiques !
Un des systèmes les plus utilisés actuellement s’appelle Git :
<center>
</center>
Il existe d’autres outils comme Subversion :
<center>
</center>
Subversion est plus simple à utiliser mais il est plus difficile à déployer, c’est pourquoi je n’en parlerai pas tout de suite.
Je n'évoquerai pas non plus d'autres outils comme Prinergy développé par Kodak ou Bridge d'Adobe qui sont trop spécifiques aux Industriques Graphiques et qui sont en plus très coûteux.
Je vais donc essentiellement parler de Git mais je serais ravi d’avoir votre avis sur la question et de connaitre les outils que vous utilisez. 😊
### Création d’un projet
La première étape consiste à créer un serveur qui va vous permettre de sauvegarder votre projet. Pas d’inquiétude, c’est très simple :
- Rendez-vous sur GitLab pour créer un compte (Le site commercial est en anglais mais le reste de l’application est en Français) :
<center>
https://gitlab.com/
<figure>
<img src="https://i.imgur.com/B84XbPf.png" alt="Exemple de Workflow" />
<figcaption>Exemple d’interface avec quelques projet</figcaption>
</figure>
</center>
- Cliquez sur « Nouveau projet ».
- Choisissez au moins un nom. (Pas toujours très évident, mais ne vous inquiétez pas, on peut en créer une infinité !) Ce n’est pas quelque chose d’officiel, c’est juste pour vous y retrouver.
- Choisissez aussi la visibilité : Si vous choisissez Privé, vous pourrez inviter d’autres personnes dans le cas d’un projet en équipe. Si vous choisissez Public, tout le monde aura accès à vos fichiers natifs.
- Le README, c’est un fichier Markdown (une sorte de fichier texte) qui sera créé à la racine du dossier de votre projet. Ce fichier vous permet de prendre des notes. (On peut également le créer par la suite.)
<center>
<figure>
<img src="https://i.imgur.com/F9StB2M.png" alt="Exemple de Workflow" />
<figcaption>Interface de l'application GitLab</figcaption>
</figure>
</center>
C’est bon, votre serveur est créé ! Facile non ? :-P
Maintenant il faut aussi le mettre sur votre ordinateur, on parle de « Cloner le projet ».
Autant vous le dire tout de suite, il n’y a qu’une manière de faire simple et efficace, c’est d’apprendre, ou de noter les quelques commandes que je vais vous donner. Il existe des outils graphiques (plus jolis) comme [GitCraken](https://www.gitkraken.com/) mais ils sont souvent assez complexes à prendre en main.
### Adhérer à un projet
- Si ce n'est pas déja fait, rendez-vous à cette adresse, téléchargez et installez git :
<center>
https://git-scm.com/downloads
(Laissez tous les réglages par défaut.)
</center>
- Ensuite, choisissez un endroit où vous souhaitez avoir une copie de votre projet.
(Pas besoin de disque externe, le projet est sauvegardé sur le serveur ! Ici, il vous faut un max de performance ! Je vous recommande d’utiliser votre disque système, qui serait de préférence un SSD).
Créez un dossier, rendez-vous dedans, puis cliquez droit (dans le vide) pour ouvrir Git Bash.
<center>
</center>
**Toutes ces étapes ne sont à faire qu’une seule fois :**
> Saisissez la ligne sur laquelle se trouve un $ puis tapez *entrée*. Les lignes suivantes sont la sortie de chaque commande.
- **Après une nouvelle installation de Git :**
Remplacez par votre nom et par **le même email que vous avez renseigné sur le serveur**.
```
$ git config --global user.name "Gaël GRZELAK"
$ git config --global user.email "gael.grzelak@gmail.com"
```
- **Après chaque création de projet :**
Retrouvez l’adresse sur le bouton clone de votre serveur GitLab (en ligne).
```
$ git clone git@gitlab.com:GGRZELAK/mon_projet.git .
Cloning into '.'...
Warning: Permanently added the ECDSA host key for IP address '172.65.251.78' to the list of known hosts.
warning: You appear to have cloned an empty repository.
```
Fini, vous avez récupéré le projet ! 😊
> Avec certains logiciels, il faudra créer un fichier *.gitignore* (le point de début est important car c’est un fichier caché). Mettez-y dedans tout ce qui ne doit pas être sauvegardé par le serveur. Par exemple, si à la création d’un projet Ableton, un dossier *.local_backup* est créé, il faut ajouter une ligne *.local_backup* dans votre fichier *.gitignore*.
### Produisez et envoyez une nouvelle version !
Vous pouvez commencer à produire votre chef œuvre ! 😉
Après « une étape importante » dans la réalisation de votre projet, ou tout simplement à la fin de la journée, il faut faire une sauvegarde sur le serveur !
Commandes à connaitre par cœur ou à noter :
- **Vérifier ce qu’il s’est passé :**
```
$ git status
On branch master
No commits yet
Untracked files:
(use "git add <file>..." to include in what will be committed)
gros_son_qui_tue.mp3
nothing added to commit but untracked files present (use "git add" to track)
```
Ici on voit que j’ai ajouté un nouveau sample mp3 à mon projet. Je peux avoir modifié une image dans un gabarit. Ou peut-être ai-je simplement modifié mon montage vidéo.
- **Valider les modifications :**
```
$ git add .
$ git commit -m "Ajout d'un sample"
[master (root-commit) f1eebc1] Ajout d'un sample
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 gros_son_qui_tue.mp3
```
- **Envoyer au serveur :**
```
$ git push
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 243 bytes | 121.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To gitlab.com:GGRZELAK/mon_projet.git
* [new branch] master -> master
```
« Putain mais c’est quoi ce charabiât ! »
Oui ça parait compliqué au début, mais accrochez vous car c’est ici que ça devient puissant ! Et une fois qu’on a l’habitude, tout ça se passe très rapidement !
Vous venez de créer un point de sauvegarde dans votre arbre ! En effet, vous êtes en train de peupler l’historique de votre projet. Allez voir dans GitLab, vous retrouverez votre travail.
Maintenant, si vous voulez, vous pouvez filer l’url à un ami pour que lui aussi puisse faire des modifications en parallèle. Il peut ensuite envoyer une nouvelle version de votre œuvre depuis son ordinateur !
- **Récupérer les modifications :**
(Dans le cas d’un travail de groupe)
```
$ git pull
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), done.
From gitlab.com:GGRZELAK/mon_projet
f1eebc1..d611dd0 master -> origin/master
Updating f1eebc1..d611dd0
Fast-forward
README.md | 1 +
1 file changed, 1 insertion(+)
create mode 100644 README.md
```
Par exemple ici, on a récupéré un nouveau fichier :
<center>
</center>
Oui mais voilà, le problème, c’est que je n’aime pas la nouvelle modification… (Ca peut être moi qui l’ai faite hier, ou une autre personne, ca reste le même principe)
Aucun problème ! Vous pouvez revenir en arrière, et ce sans supprimer ce qui a été fait avant !
### Naviguer dans l'historique
Pour se déplacer dans l’arbre on utilise **les commandes les plus importantes et les plus intéressantes** comme ceci :
- **Consulter l’historique :**
```
$ git log
commit d611dd034213ecd15412d1f5a266b41a65489330 (HEAD -> master, origin/master)
Author: Gaël GRZELAK <gael.grzelak@gmail.com>
Date: Sun Mar 29 05:46:53 2020 +0000
Ajout de README.md
commit f1eebc1ca541ccabe6fab3d723bc6cab3182fd75
Author: Gaël GRZELAK <gael.grzelak@gmail.com>
Date: Sun Mar 29 07:36:50 2020 +0200
Ajout d'un sample
```
On voit les petits messages, écrits par un collègue ou moi-même, et on choisit la version qui nous intéresse.
- **Se déplacer sur une autre version :**
```
$ git checkout f1eebc1ca541ccabe6fab3d723bc6cab3182fd75
Note: switching to 'f1eebc1ca541ccabe6fab3d723bc6cab3182fd75'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:
git switch -c <new-branch-name>
Or undo this operation with:
git switch -
Turn off this advice by setting config variable advice.detachedHead to false
HEAD is now at f1eebc1 Ajout d'un sample
```
Ces messages nous expliquent ce qui se passe. Le cas échéant, ils permettent de nous aider en cas de problème.
Maintenant regardez dans votre dossier, vous êtes revenu sur une ancienne version sans pour autant avoir supprimé les fichiers (en effet, ils sont toujours sur le serveur) ! On ne sait jamais, ça peut toujours servir à créer un nouveau titre par exemple. 😉
D’ailleurs, pour éviter d’écraser ces modifications, on va créer une nouvelle branche.
- **Créer une branche :**
```
$ git checkout -b version-secondaire
Switched to a new branch 'version-secondaire'
```
On est passé sur une nouvelle branche, on peut maintenant effectuer des modifs, les ajouter, et les envoyer au serveur. (Cf. Commandes à cet effet)
Si je me rends sur le serveur, je constate dans la partie *Dépôt -> Graphique* que j’ai bien mes 2 branches (représentant chaucune une version différente de mon projet) !
<center>
</center>
On peut par exemple imaginer quelques variations dans certains morceaux, ou dans la timeline d’un film par exemple…
Pour rebasculer sur l'autre branche, référez vous à : **Se déplacer sur une autre version**.
Cette dernière partie est nettement plus complexe car on peut facilement se perdre dans l’historique et faire des mauvaises manipulations qui, dans le pire des cas, mèneraient à la perte des données.
Dans cette dernière partie, on pourrait garder les deux versions ou choisir de les fusionner. Dans ce cas, on peut être confronté à des **conflits** car en effet, si un même élément a été modifié (un même sample par exemple), il faudra choisir l’une ou l’autre version.
Ces commandes sont : **git rebase et git merge**.
Je n’en parlerai pas ici car il s’agit d’un article général traitant des bases sur le versionning d’un type de projet très spécifique.
## Conclusion
Les possibilités sont, comme vous l'aurez constaté, illimitées ! A vous d’adapter l’utilisation des outils en fonction de vos besoins et de vos moyens. Par exemple, n'utilisez pas le système de branche immédiatement sur un vrai projet. Faites des expériences, cela vous permettra d'apprendre et de vous entrainer. Au bout d'un an, on peut devenir expert du versionning !
Un super site web pour s'entrainer : https://learngitbranching.js.org/
