Cours Git GitHub GitLab

Let’s Git !
A la découverte de Git & Co

Git // GitHub // GitLab
Plan du cours
Ce que nous allons voir …
1. Introduc,on 2. Git 3. GitHub

Qu’est-ce qu’un VCS ? Comprendre Comprendre
A quoi ça sert ? Explorer Explorer
Comment ça marche ? U>liser U>liser
4. GitLab 5. Outils / Référentiels

Comprendre Outils liés à Git
Explorer Github, Gitlab
Utiliser Référentiels, Documentations
mardi 16 mars 2021 Let's Git ! 2

Plan du cours
… et surtout ce que nous allons faire !
6. Visual Git 7. Git Branching 8. Just Git-it !

Comprendre « visuellement » Suite interactive d’exercices pour Exercices interactifs pour pratiquer
ce qui se passe pratiquer et maîtriser les concepts toutes les commandes de Git
de branches
9. GitHub & GitLab

Présenta>on et prise en main

1. Introduc5on
Ø Qu’est-ce qu’un VCS ?

Ø Comment ça marche ?
Ø A quoi ça sert ?

1. Introduction : VCS ?
Version Control System (Logiciel de Gestion de Versions)
Ø Permet de stocker et partager un ensemble de fichiers (≠ cloud !)

Ø Suivre et documenter tous les changements opérés dans le temps
Ø Accéder, restaurer, comparer l’historique des versions d’un ou plusieurs fichiers
Librarian: tout 1er VCS apparu dans les années 70 sur le modèle des cartes perforées. Des
colonnes « virtuelles » étaient ajoutées pour dater la modification.

1. Introduc2on : Différents systèmes
Différents systèmes de gestion de versions :

Ø Gestion de version locale « fait main » et améliorée
Ø Gestion de version centralisée (CVCS)
Ø Gestion de version décentralisée (DVCS)

1. Introduc2on : Différents systèmes
Gestion de version locale « fait main » è A BANNIR !!!
Dossier Projet Dossier Sauvegardes
Fichier1_V3 Fichier1_V1
Fichier2_V2 Fichier1_V2
… Fichier2_V1
Uniquement en local
Pas de metadatas
Pas de suivis de l’historique
Très lourd à u8liser
1. Introduction : Différents systèmes
Gestion de version locale utilisant un VCS local èRCS
Dossier Projet VCS Local

Fichier1 Version 3
Version 2
Version 1
Fichier2 Version 2
Version 1
Uniquement en local
Très lourd à utiliser
Compliqué à utiliser à plusieurs

Gestion de version centralisée (CVCS) è CVS, Subversion, …
PC 1 Dépôt Centralisé
Fichier Base des versions
Version 3
Version 2
Version 1
PC 2
Fichier
EN CAS DE COUPURE SERVEUR, IMPOSSIBLE D’ACCEDER AUX INFORMATIONS

Gestion de version décentralisée (DVCS) è Git, Mercurial, Bazaar, …
Serveur PC 2
Fichier Fichier
Base des versions Base des versions

Version 3 Version 3
Version 2 PC 1 Version 2
Version 1 Fichier Version 1
Base des versions

Version 3
Version 2
Version 1

1. Introduc2on : Pourquoi l’u2liser ?
Ø Suivre les étapes de modification d’un programme
Ø Tester un changement complexe et pouvoir revenir facilement en arrière
Ø Travailler à plusieurs sur un projet
Ø Inviter des collaborateurs sur un projet
Ø Contribuer à un projet OpenSource

2. Git
Ø Comprendre
Ø Utiliser
Ø Explorer

2. Git : qu’est-ce que Git ?
Git est un logiciel de gestion de sources décentralisé et distribué
En ligne de commande ($git)

Voir l’introduction
Développé en C, Bash et Perl Voir l’introduction Multi-utilisateurs
Pas besoin d’un serveur
Open Source (GNU GPL 2)

2. Git : Histoire et Contexte
Git est inventé par Linus Torvald (le « papa » de Linux) en 2005 à la suite d’un désaccord
entre BitKeeper et la communauté développant le noyau Linux.
Principes fondateurs dans le développement de Git:

Ø Vitesse
Ø Concepgon simple
Ø Support pour les développements non linéaires (gesgon de milliers de branches en
parallèle)
Ø Complètement distribué
Ø Capacité à gérer efficacement des projets d’envergure (tels que le noyau Linux)

2. Git : Principes de Git
Gestion des données
Ø Traditionnellement, les CVS considèrent leur dépôt comme un ensemble de fichiers.
Ø Les informations sont donc considérées comme une liste de fichiers et de modifications
effectuées sur chaque fichier dans le temps

Gestion des données
Ø Git considère ses données comme des instantanés d’un système de fichiers
Ø A chaque enregistrement ou validation de l’état du projet, git prend un instantané du
contenu de l’espace de travail à l’instant T et enregistre une référence à cet instantané
Ø Les données sont donc vues comme un flux d’instantanés

Opéra5ons locales
Ø Git réalise la quasi totalité de ses opérations en locale
Ø Permet de gagner en rapidité et de pouvoir travailler hors connexion
Intégrité de fichiers
Ø Git vérifie l’intégralité de ses données par des sommes de contrôle avant de les stocke
Ø Cette somme de contrôle devient donc une signature unique, qui sert de référence
Ø On peut donc changer le contenu d’un fichier ou d’un répertoire sans que Git ne s’en rende
compte
Ø De fait, il est impossible de perdre des données lors du transfert ou de corrompre un fichier

2. Git : Espace de travail
Git uglise de facto 3 « espaces » de travail bien différents,
également appelés les 3 arbres de Git
Répertoire de
Index Dépôt
travail
(staging) (git repository)
(working directory)
Indexation (staging) - $git add .
Commit - $git commit
Checkout - $git checkout

2. Git : Espace de travail
Git utilise de facto 3 « espaces » de travail bien différentes
également appelés les 3 arbres de Git
Répertoire de
Index Dépôt
travail
(staging) (git repository)
(working directory)
Stockage des méta-

Simple fichier,
données et de la base de
généralement situé dans
Répertoire de travail données des objets
le répertoire .git
(working directory)
Stocke ce qui fera partie
è Ce qui est copié lors du
du prochain instantané
clonage d’un dépôt

2. Git : Vocabulaire
Repository (dépôt) è espace de stockage crée pour y déposer les fichiers du projet et
l’historique
Local Repository (dépôt local) è Ensemble des historiques (.git) et de l’espace de travail côté
client
Remote Repository (dépôt distant) è Ensemble des historiques côté serveur
Push (pousser) è Action d’envoyer toutes les modifications locales vers le serveur. Aligne les
révisions du dépôt distant avec le dépôt local.
Pull (tirer) èAction de récupérer toutes les dernières modifications présentes sur le serveur.
Cela fusionne également la branche de travail avec.
Fetch (récupérer)è Action qui récupère l’état du dépôt distant dans le dépôt local .git

Clone (cloner) è Action de cloner un projet à partir du serveur sur votre poste, tel quel. Créer
le .git et l’espace de travail sur la révision courante.
Fork (répliquer) è Action de copier un dépôt distant sur un autre serveur.
La dépôt aura sa propre vie, indépendamment du dépôt répliqué.
Commit (révision) è Entrée dans l’historique créant un instantané de l’état du projet à
l’instant T.
To commit (acter) è Action de créer un instantané, de valider les modifications.
Pull Request / PR (proposition de fusion) è Proposition de fusion de deux branches
différentes (du même projet ou entre répliques)

Branch (branche) è Congent généralement une foncgonnalité spécifique qui est ajoutée.
Congent un ou plusieurs commits.
Master (maître) è Branche principale du projet (souvent celle qui est livrée en producgon)
Origin (origine) è Alias aoribué à la réplique depuis laquelle on a fait un clone.
Upstream (référent) è Alias aoribué à la réplique originale depuis laquelle la votre a été faite.
HEAD (alias) è Alias de la révision uglisée comme état courant d’une branche.
Merge (fusionner) è Opéragon d’ajouter une branche dans une autre, on les fusionnent
Tag (égqueoe) è Egqueoe aoribuée à un certain état dans l’historique, généralement pour
des releases.

2. Git : Etat des fichiers
Git considère 4 états pour un fichier du dépôt
Fichier non suivi Fichier inchangés Fichier modifié Fichier indexé

(untracked) (unmodified) (modified) (staged)
Ajout du fichier ($git add)
suppression du fichier Édition du fichier
Reset du fichier Indexa7on du fichier ($git add)
Desindexation du fichier ($git reset)
Commit ($git commit)

2. Git : Ges2on des données
Schéma complet des commandes pour gérer les données dans Git
$ git init
Initialisation
$ git clone
$ git commit -a
Modifications
$ git add (-u) $ git commit $ git push
Local Remote
Workspace Index
Repository Repository
$ git merge // $ git rebase $ git fetch
Récupérations $ git pull
$ git checkout HEAD // $ git reset --hard HEAD

Retours $ git checkout $ git reset HEAD
$ git diff HEAD

Comparaisons $ git diff

2. Git : Quelques commandes
Utilisation basique de Git

Utilisation basique de Git

Rappel des convengons pour la suite des exemples

Commandes : Diff

Commandes : Commit

Commandes : Commit

Commandes : Commit

Commandes : Commit (avec une « Detached HEAD »)

Commandes : Commit (avec une « Detached HEAD »)
Dans le 1er cas on peut perdre son commit. Dans le 2 cas on va créer une nouvelle branche
avec ce commit

Commandes : Checkout



Commandes : Reset

Commandes : Reset

Commandes : Reset

Commandes : Merge

Commandes : Merge

Commandes : Cherry Pick

Commandes : Rebase

Commandes : Rebase

Passons à la pratique…
Installer Git:
https://git-scm.com/downloads

A faire pour le prochain cours
1/ Créer un répository local nommé "Cours_Git"
2/ Créer un fichier readme dans lequel vous pouvez écrire quelques enseignements que vous gardez en
tête
3/ Indexer ce fichier et le valider avec pour commentaire "Version initiale"
4/ Faire l'ensemble de commandes vous permettant d'arriver à l'état suivant:
a) un historique contenant votre version initiale ci-dessus
b) un index allant contenir une version 2 contenant le même fichier que dans votre version initiale dans
lequel vous avez rajouté des éléments
c) un répertoire de travail avec un nouveau fichier dans lequel vous détaillez les quelques commandes
dont vous vous rappelez que vous nommerez "commandes"
d) un fichier "rendu" dans votre répertoire de travail, que vous aurez indexé et validé, qui contiendra
l'ensemble des commandes que vous avez utilisé pour réaliser les différents points.
5/ Cloner un dépôt distant, que vous irez trouver sur github (choix libre)
6/ Créer une nouvelle branche "ma branche"
7/ Créer/modifier et supprimer des fichiers ainsi que des bouts de fichiers
8/ Indexer et Valider vos modifications

2. Git : Les branches
Ø Git permet et propose de travailler avec des branches, de façon simple, rapide et légère :
Ø On créer une branche pour chaque nouvelle fonctionnalité ou ensemble logique de
fonctions (ex: ajout de commentaires, ajout de liens de partages, hotfix, bugfix, etc.)
Ø Cela permet de tester une branche indépendamment du tronc principal (généralement
master)
Ø Une fois testé ou dans un état stable, on le fusionne avec le tronc commun
Ø Maîtriser ce concept de git est primordial !

Voici un commit et son arbre :

Si vous faites des modifications et validez à nouveau, le prochain commit stocke un pointeur
vers le commit le précédant immédiatement.
Voici le commit ci-avant et ses parents:

Visuellement, une branche et l’historique de ses commits associés se représente ainsi :

Si je créer une nouvelle branche sur l’arbre précédent, cela créer simplement un pointeur
sur le commit courant :
$ git branch testing

A ce stade, mes 2 branches pointent vers la même série de commits.
$ git log --oneline –decorate
f30ab (HEAD, master, test) add feature #32 - ability to add new
34ac2 fixed bug #ch1328 - stack overflow under certain conditions
98ca9 initial commit of my project

Pour basculer entre mes branches, je dois faire un checkout sur la branche souhaitée :
$ git checkout testing

Dorénavant, lorsque je travaille sur ma branche testing, elle « avance » à chaque nouveau
commit :
$ vim test.rb
$ git commit -a -m 'made a change'

Si je rebascule sur la branche master, et que je réalise des modificagons dessus :
$ git checkout master

Si je rebascule sur la branche master, et que je réalise des modifications dessus :
$ vim test.rb
$ git commit -a -m 'made other changes'

Si je regarde mon historique
$ git log --oneline --decorate --graph --all
* c2b9e (HEAD, master) made other changes
| * 87ab2 (test) made a change
|/
* f30ab add feature #32 - ability to add new formats to the
* 34ac2 fixed bug #ch1328 - stack overflow under certain conditions
* 98ca9 initial commit of my project

Git permet de fusionner des branches entre elles. Partons de l’exemple suivant :

Je décide de créer une branche pour corriger l’issue #53
$ git checkout –b iss53
Switched to a new branch "iss53"

Je réalise ma correction et je la commit :
$ vim index.html
$ git commit -a -m "ajout d'un pied de page [problème 53]"

Je bascule de nouveau sur ma branche master
Switched to branch 'master'
Dans le même temps, j’ai un correctif à faire sur ma branche master

$ git checkout -b hotfix
Switched to a new branch ‘hotfix'
$ vim index.html
$ git commit -a -m "correction de l'adresse email incorrecte"
[hotfix 1fb7853] "correction de l'adresse email incorrecte"
1 file changed, 2 insertions(+)

Voici l’état de mon dépôt à cet instant :

Mon correcgf est sagsfaisant, je décide de le fusionner dans master :
$ git merge hotfix
Updating f42c576..3a0874c
Fast-forward
index.html | 2 ++
1 file changed, 2 insertions(+)

Mon correctif est fusionné dans master, je décide de supprimer la branche :
$ git branch -d hotfix
Deleted branch hotfix (3a0874c).
Je décide de retourner sur ma branche de l’issue 53 et de la terminer :

$ git checkout iss53
Switched to branch "iss53"
$ vim index.html
$ git commit -a -m 'Nouveau pied de page terminé [issue 53]'
[iss53 ad82d7a] Nouveau pied de page terminé [issue 53]
1 file changed, 1 insertion(+)

Mon dépôt ressemble désormais à ceci :

Je suis satisfait de ma nouvelle branche, je décide de la fusionner dans ma branche master :
Switched to branch 'master'
$ git merge iss53
Merge made by the 'recursive' strategy.
README | 1 +
1 file changed, 1 insertion(+)
Ici, Git va réaliser une fusion à 3

sources (three-way-merge)

Git a réalisé la fusion, avec un commit « spécial » (car il a plus d’un parent) appelé commit
de fusion (merge commit). Mon dépôt ressemble à ceci dorénavant :

2. Git : Les conflits
Que se passe-t-il en cas de conflit dans 2 branches à fusionner ?

è Git renvoie une erreur et vous invite à corriger manuellement le conflit
$ git merge iss53
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.

Je peux vérifier ce qui se passe dans le statut de mon dépôt :

$ git status
On branch master
You have unmerged paths.
(fix conflicts and run "git commit")
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified: index.html
no changes added to commit (use "git add" and/or "git commit -a")

Git note dans le fichier en conflit ce qui diverge :

<<<<<<< HEAD:index.html Contenu du fichier dans la branche
<div id="footer">contact : email.support@github.com</div> dans laquelle je me trouve (ici master)
======
<div id="footer"> Contenu de mon fichier dans la
please contact us at support@github.com branche iss53
</div>
>>>>>>> iss53:index.html

Une fois que j’ai résolu le conflit, je peux ajouter mon fichier à l’index et faire mon commit :
$ git add index.html

$ git commit –m "ma correction"

2. Git : Les conflits
Git me retournera un message un peu différent des autres commits :
Merge branch 'iss53'
Conflicts:
index.html
#
# It looks like you may be committing a merge.
# If this is not correct, please remove the file
# .git/MERGE_HEAD
# and try again.
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# All conflicts fixed but you are still merging.
#
# Changes to be committed:
# modified: index.html
#

Maintenant que nous savons travailler avec les branches, comment devons-nous / pouvons-
nous nous en servir ?
Ø Garder une approche linéaire du développement ?
Possible MAIS:
è Pas très agile
è Que se passe-t-il si l’on veut paralléliser les développements à plusieurs ?
è Très itéra8f

Ø Prendre une approche par « silo » pour s’assurer d’une stabilité progressive ?

Ø Prendre une approche par « thématiques »

Ø Prendre une approche par « thématiques »
Nous avons jeté la 1ère correc,on

proposée pour l’issue #91
Nous avons décidé que l’idée idiote
proposée devait être gardée

2. Git : Les dépôts distants
Travailler avec un dépôt distant se représente ainsi :

SI je travaille sur mon dépôt local et qu’en même temps quelqu’un pousse une modification
sur le dépôt distant :

Si je synchronise mon dépôt local avec le dépôt distant, cela donne :
$ git fetch origin master

Pour rappel, git permet l’usage de multiples serveurs distants

Pour rappel, git permet l’usage de multiples serveurs distants
$ git remote add teamone git://git.team1.mycompany.com

Continuons la pratique…
1/ Visualizing Git
http://git-school.github.io/visualizing-git/
2/ Git Branching
https://learngitbranching.js.org/?locale=fr_FR&NODEMO=
3/ Git-it
https://github.com/jlord/git-it-electron#what-to-install

3. GitHub
Comprendre
Utiliser
Explorer

4. GitLab
Comprendre
Utiliser
Explorer

5. Outils / Référentiels
Outils liés à Git

Github, Gitlab
Référentiels, Documentations

Référen5els, Documenta5ons
Manuel de référence Tutoriel officiel git
https://git-scm.com/docs hdps://git-scm.com/docs/gidutorial
Pro git book Immersion dans git

https://git-scm.com/book/en/v2 hdps://gi8mmersion.com
(ce cours prend beaucoup d’exemples de ce livre)
Everyday git
Quelques vidéos hdps://git-scm.com/docs/giteveryday
https://git-scm.com/videos
Backlog Git Tutorial

Git & GitHub Cheat Sheet
hdps://backlog.com/git-tutorial
https://training.github.com/downloads/fr/github-git-
cheat-sheet.pdf
https://training.github.com/downloads/fr/github-git-
cheat-sheet/
Merci

Cours Git GitHub GitLab

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cours Git GitHub GitLab

Transféré par

Droits d'auteur :

Formats disponibles

Let’s Git !

A la découverte de Git & Co

Ce que nous allons voir …

1. Introduc,on 2. Git 3. GitHub

4. GitLab 5. Outils / Référentiels

mardi 16 mars 2021 Let's Git ! 2

… et surtout ce que nous allons faire !

6. Visual Git 7. Git Branching 8. Just Git-it !

9. GitHub & GitLab

mardi 16 mars 2021 Let's Git ! 3

Ø Qu’est-ce qu’un VCS ?

mardi 16 mars 2021 Let's Git ! 4

Version Control System (Logiciel de Gestion de Versions)

Ø Permet de stocker et partager un ensemble de fichiers (≠ cloud !)

mardi 16 mars 2021 Let's Git ! 5

Différents systèmes de gestion de versions :

mardi 16 mars 2021 Let's Git ! 6

Dossier Projet Dossier Sauvegardes

Dossier Projet VCS Local

mardi 16 mars 2021 Let's Git ! 8

Fichier Base des versions

EN CAS DE COUPURE SERVEUR, IMPOSSIBLE D’ACCEDER AUX INFORMATIONS

mardi 16 mars 2021 Let's Git ! 9

Base des versions Base des versions

Base des versions

mardi 16 mars 2021 Let's Git ! 10

Ø Suivre les étapes de modification d’un programme

Ø Tester un changement complexe et pouvoir revenir facilement en arrière

Ø Travailler à plusieurs sur un projet

Ø Inviter des collaborateurs sur un projet

Ø Contribuer à un projet OpenSource

mardi 16 mars 2021 Let's Git ! 11

mardi 16 mars 2021 Let's Git ! 12

Git est un logiciel de gestion de sources décentralisé et distribué

En ligne de commande ($git)

mardi 16 mars 2021 Let's Git ! 13

Principes fondateurs dans le développement de Git:

mardi 16 mars 2021 Let's Git ! 14

mardi 16 mars 2021 Let's Git ! 15

mardi 16 mars 2021 Let's Git ! 16

mardi 16 mars 2021 Let's Git ! 17

Indexation (staging) - $git add .

Commit - $git commit

Checkout - $git checkout

mardi 16 mars 2021 Let's Git ! 18

Stockage des méta-

mardi 16 mars 2021 Let's Git ! 19

mardi 16 mars 2021 Let's Git ! 20

mardi 16 mars 2021 Let's Git ! 21

mardi 16 mars 2021 Let's Git ! 22

Fichier non suivi Fichier inchangés Fichier modifié Fichier indexé

suppression du ﬁchier Édition du fichier

Reset du fichier Indexa7on du ﬁchier ($git add)

Desindexation du fichier ($git reset)

Commit ($git commit)

mardi 16 mars 2021 Let's Git ! 23

$ git checkout HEAD // $ git reset --hard HEAD

$ git diff HEAD

mardi 16 mars 2021 Let's Git ! 24

mardi 16 mars 2021 Let's Git ! 25

mardi 16 mars 2021 Let's Git ! 26

mardi 16 mars 2021 Let's Git ! 27

mardi 16 mars 2021 Let's Git ! 28