Brendan Abolivier
M2 Robotique
Alternant @ Cozy Cloud
- Travail collaboratif
- Gestion de version
- Trace de tous les changements
- "Voyage dans le temps"
- Ubuntu :
sudo apt-get install git - Archlinux :
sudo pacman -S git - Windows : https://git-scm.com/download/win
- Notions théoriques
- Mises en pratique
- Démos
Deux utilisations distinctes
Garder une trace de toutes ses modifications
Utile pour :
- Travailler hors ligne
- Garder une trace d'un état stable
- Revenir en arrière sur un mauvais travail
- ...
Sur mon ordinateur !
Travailler en équipe
Utile pour :
- Développer un projet à plusieurs
- Garder une sauvegarde de son travail en ligne
- Publier les sources de son projet
- ...
Sur l'infrastructure d'un hébergeur
- GitHub (https://github.com/)
- GitLab (https://gitlab.com/)
Sur ma propre infrastructure
- GitLab (https://gitlab.com/)
- Gitea (https://gitea.io/)
- SSH
- ...
- Push : J'envoie mes modifications
- Pull : Je récupère des modifications
Sur le serveur, et en local
Versionner son projet
Copie du projet au moment du push
Trace datée du moindre changement dans le projet
- Mon projet est à deux endroits à la fois :
- Sur mon ordinateur
- Sur un serveur
- Il se trouve dans un dépôt
- Je décris mes modifications dans un commit
- J'envoie mes modifications sur le serveur avec un push (je pousse mes modifications)
- Je récupère les modifications d'un autre depuis le serveur avec un pull (je tire les modifications)
Ça se fait côté serveur
Configuration initiale
git config --global user.name "Brendan Abolivier"
git config --global user.email "[email protected]"git clone https://web.isen-bretagne.fr/gitlab/baboli18/test.gitIci, l'adresse de mon dépôt est https://web.isen-bretagne.fr/gitlab/baboli18/test.git
Voir les fichiers modifiés/ajoutés/supprimés
$ git status
Sur la branche master
Votre branche est en avance sur 'origin/master' de 20 commits.
(utilisez "git push" pour publier vos commits locaux)
Modifications qui ne seront pas validées :
(utilisez "git add <fichier>..." pour mettre à jour ce qui sera validé)
(utilisez "git checkout -- <fichier>..." pour annuler les modifications dans la copie de travail)
modifié : slides.md
aucune modification n'a été ajoutée à la validation (utilisez "git add" ou "git commit -a")
Voir les modifications dans les fichiers modifiés
git diffCréation du commit
git add [...]
git rm [...]
git commit -m "Mon super commit"Envoi du commit
git pushCréation de plusieurs commits
git add app.js
git commit -m "Fonctionnalité X"
git rm obsolete.js
git commit -m "Suppression de obsolete"Envoi
git pushgit pullgit loggit checkout [hash du commit]git checkout [fichier]git revert [commit]On peut récupérer le hash du commit avec git log
Exemple : Annuler les deux derniers commits
git revert HEAD~2(fonctionne aussi avec git checkout)
Copie du dépôt à l'instant t
Le fork se comporte comme un dépôt
La plupart du temps, on gère son projet en suivant ces conventions :
- Pour contribuer à un projet, on fork son dépôt
- On intègre nos modifications sur une nouvelle branche
- On ouvre une merge request sur le dépôt d'origine
Ton dépôt est un arbre
- Branche initiale : master
- Généralement une copie à un moment t de master + changements
- On "tire une branche" pour :
- Développer des fonctionnalités
- Effectuer des relectures de code
- Assurer la stabilité du projet
La plupart du temps, on gère son projet en suivant ces conventions :
- master : Branche principale du dépôt
- dev : Contient les développements en cours
- feature/[...] : Développement d'une fonctionnalité
- fix/[...] : Développement d'une correction de bug
Note : Seule master est créée automatiquement
On demande la fusion d'une branche dans une autre
- GitLab : Merge requests
- GitHub : Pull requests
(mais en vrai, c'est la même chose)
Alice et Bob travaillent sur un projet, sur un dépôt de Bob.
Alice veut ajouter un formulaire au projet.
- Elle fork le dépôt
- Elle crée la branche feature/formulaire sur son fork
- Elle y développe le formulaire
- Elle ouvre une merge request de feature/formulaire sur son fork vers dev sur le dépôt de Bob
- Bob relit le code d'Alice et fusionne sa branche sur son dépôt
Le formulaire d'Alice est maintenant dans dev
- Branche principale du dépôt
- État stable du projet
- N'importe qui doit pouvoir l'utiliser
On fusionne dans master quand :
- On sort une nouvelle version du projet
- On sort un correctif d'un bug critique
Alice et Bob ont rajouté plusieurs fonctionnalités à leur projet.
- L'un.e des deux ouvre une merge request de dev vers master
- Les deux relisent les changements depuis la dernière mise à jour de master
- L'autre fusionne dev dans master
Encore une fois, des conventions !
- Je travaille sur le dépôt d'un autre à l'aide d'un fork
- Je travaille sur une branche qui décrit ma modification
- Je demande l'ajout de mes changements via une merge request
masterfait référence à une version stable de mon projet
Côté serveur
Récupération de la nouvelle branche
git fetchPassage sur la nouvelle branche
git checkout [nom de la branche]git push --set-upstream origin [nom de la branche]la première fois, puis
git pushles fois suivantes
- Travis (https://travis-ci.org/)
- Gitlab CI (https://about.gitlab.com/gitlab-ci/)
Lancement des tests unitaires à chaque push et merge request
Exemple : Caddy (et son module git)
Mettre des modifications en production avec un push
Questions ?