100% ont trouvé ce document utile (1 vote)

70 vues61 pages

Travailler avec GitLab en équipe

Transféré par

Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.

Formats disponibles

Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd

100% ont trouvé ce document utile (1 vote)

70 vues61 pages

Travailler avec GitLab en équipe

Transféré par

ekoue andreas

Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.

Formats disponibles

Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd

1

Travailler à plusieurs avec

GitLab ou GitHub

Bruno Mermet
Université du Havre
2018

Bruno Mermet
2

Plan
● Présentation générale du principe
● Démarche avec gitlab

Bruno Mermet
3

Travailler à 2 avec git

Bruno Mermet
4

Travailler à 2 avec git

Fetch :
Les branches distantes
sont importées dans le
dépôt local avec un nom de
la forme
1: fetch dépôtDistant/nomBranche

Bruno Mermet
5

Travailler à 2 avec git

Fetch :
Les
Mergebranches
: distantes
sont importées
On fusionne dans
dans la le
dépôt
branchelocal avec un
courante la nom de
la forme distante de même
branche
1: fetch dépôtDistant/nomBranche
nom

2: merge

Bruno Mermet
6

Travailler à 2 avec git

Fetch :
Les
Merge branches
: distantes
sont
On importées
fusionne dans
dans la le
Commit
dépôt : avec un nom de
local
branche
On archivecourante la de la
le résultat
la forme
branche distante de même
1: fetch fusion
dépôtDistant/nomBranche
nom

2: merge

3: commit

Bruno Mermet
7

Travailler à 2 avec git

Fetch :
Les
Merge branches
: distantes
sont
On importées
fusionne dans
dans la le
Commit
dépôt : avec un nom de
local
branche
On archivecourante
le la de la
résultat
la forme
Push : distante de même
branche
1: fetch 4: push fusion
dépôtDistant/nomBranche
On transfère sur le dépôt
nom
distant l'historique de la
branche courante

2: merge

3: commit

Bruno Mermet
8

Travailler à 2 avec git

Fetch :
Les branches Pull
distantes
Merge :
sont
On importées
fusionne dans
dans la le
Commit
dépôt : avec un nom de
local
branche
On archivecourante
le la de la
résultat
la forme
Push : distante de même
branche
1: fetch 4: push fusion
dépôtDistant/nomBranche
On transfère sur le dépôt
nom
distant l'historique de la
branche courante

2: merge

3: commit

Bruno Mermet
9

Travailler à plusieurs avec git

1. Version complètement décentralisée

Bruno Mermet
10

Travailler à plusieurs avec git

2. Version complètement centralisée

Bruno Mermet
11

Travailler à plusieurs avec git

2. Version complètement centralisée

Bruno Mermet
12

Travailler à plusieurs avec git

3. En résumé…
● On travaille toujours avec 2 dépôts
– Le dépôt local
– Un dépôt « distant » (remote) auquel on associe un nom
● Les 4 principales commandes git permettant d’interagir avec
un dépôt distant sont :
– git fetch : on récupère en local le contenu du dépôt distant
– git pull : équivalent d’un git fetch suivi d’un git
merge
– git push : on transfère l’état actuel de la branche courante (et
son historique) vers le dépôt distant
– git clone : on crée un dépôt local à partir d’un dépôt distant
Bruno Mermet
13

Travailler à plusieurs avec git

4. Faciliter les choses

Gitlab

+ Interface
Web

Bruno Mermet
14

Gitlab et consorts (Github, Gitbucket)

Structure générale

Interface Gitlab
Web

Groupe 1 Groupe 2

Bruno Mermet
15

Gitlab et Github
Résumé
● Fonctionnalités offertes
– Gestion de multiples dépôts git, permettant de faciliter le travail à
plusieurs
– Interface Web pour interagir avec le dépôt git
– Gestion de « pull request » ou « merge requests »
– Approche de l'intégration continue
● Utilisation
– Soit depuis gitlab.com / github.com
– Soit via une installation locale (gratuite pour gitlab)

Bruno Mermet
16

Travailler à plusieurs avec un dépôt

commun
● Principe de base
– Dépôt « en ligne » accessible par tous, au moins
occasionnellement
– Chacun « clone » le dépôt commun sur sa machine
– Périodiquement :
● Mise à jour de son dépôt local à partir du dépôt commun

● Transfert de versions stables de son travail dans le dépôt

commun
● Principe « évolué »
– Faire un « fork » du dépôt commun et travailler avec ce dépôt
personnel distant
– Faire des « pull request » vers le dépôt commun lorsqu'on a atteint
une version stable sur son dépôt personnel distant

Bruno Mermet
17

Gestion de la synchronisation entre

dépôts
● Un dépôt est constitué
– D'un ensemble de « versions », identifiées par un « hash »
– D'un ensemble de « références » : branches et étiquettes
● Localement, un dépôt distant est identifié par un nom
● Une branche b du dépôt distant d est suivie localement par une branche de
suivi d/b
● L'action « fetch » récupère dans le dépôt local les versions disponibles sur
un dépôt distant et met à jour ou crée les branches de suivi
● L'action « pull » fait un « fetch » puis un « merge » dans une branche
locale b à partir de la branche de suivi associée (b/d par défaut)
● L'action « push » transfère la branche locale sur le serveur. Si une branche
de même nom n'existe pas sur le serveur, elle est créée. Sinon, si un « fast-
forward » peut être effectué, la branche sur le serveur est mise à jour.
Sinon, le « push » est refusé.

Bruno Mermet
18

Commencer avec gitlab

● Se rendre sur la page https://www-apps.univ-lehavre.fr/forge
● Se connecter avec le C.A.S. de l’université
→ Crée un groupe personnel
● Ajouter une clé SSH (menu en haut à droite, option « settings » puis
menu à gauche, option « SSH Keys »)
éventuellement, sur sa machine
● ssh-keygen
● Ssh-add
● Configurer la langue (Settings → Profile → Preferred Language)
● Créer éventuellement un ou plusieurs groupe(s) et y ajouter
éventuellement des membres (menu « Groups », bouton
Nouveau Groupe)
● Pour démarrer un projet, créer un dépôt dans le groupe adéquat
Bruno Mermet
19
Créer un projet dans Gitlab (1)
(Projects → New Project)

Nom du dépôt
Nom du groupe

Optionnel… donc
indispensable !

Bruno Mermet
20
Créer un projet dans GitLab (2)
Retour de GitLab (1)
URI SSH ou
HTTPS du dépôt

SSH : pas
d’identifiant à saisir
grâce à la clé SSH

HTTPS : connexion
possible depuis
l’extérieur de
l’université

Bruno Mermet
21
Créer un projet dans GitLab (2)
Retour de GitLab (1)
URI SSH ou
HTTPS du dépôt

Rappels sur la
configuration de git si
ce n’est pas déjà fait

Exemple d’utilisation si
ce dépôt est là pour
héberger un nouveau
projet

Bruno Mermet
22
Créer un projet dans GitLab (2)
Retour de GitLab (2)
Consignes pour
utiliser ce dépôt
pour héberger un
projet qui existe
déjà en local

Consignes pour
utiliser ce dépôt
pour héberger un
projet qui est déjà
hébergé sur un
autre dépôt

Bruno Mermet
23
Démarrer un nouveau projet
1. Cloner le dépôt GitLab
●
git clone [email protected]:mermetb/MonProjet.git
● tree
.
└── MonProjet
├── .git/

● cd MonProjet ; git remote -v

origin [email protected]:mermetb/MonProjet.git (fetch)
origin [email protected]:mermetb/MonProjet.git (push)

● git branch

● git log
fatal: bad default revision 'HEAD'

Bruno Mermet
24
Démarrer un nouveau projet
1. Cloner le dépôt GitLab
●
git clone [email protected]:mermetb/MonProjet.git
● tree
.
└── MonProjet
├── .git/

● cd MonProjet ; git remote -v

origin [email protected]:mermetb/MonProjet.git (fetch)
origin [email protected]:mermetb/MonProjet.git (push)

● git branch
Origin : nom
attribué (par défaut)
● au
gitdépôt GitLab
log
que l’on vient de
cloner. fatal: bad default revision 'HEAD'

Bruno Mermet
25
Démarrer un nouveau projet
2. Initialiser la branche master
● touch README.md
● git add .
● git commit -m « création fichier ReadMe »
[master (commit racine) 30d9696] creation fichier ReadMe
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 README.md

● git branch -vv

* master 30d9696 [origin/master: disparue] creation fichier ReadMe

La branche « master » actuelle est

sensée suivre la branche
« master » du dépôt initial, nommé
« origin », mais cette branche
distante n’existe pas encore

Bruno Mermet
26
Démarrer un nouveau projet
3. Transférer une première version sur
le serveur
● git push -u origin master
Nom de la branche devant être
transférée sur le dépôt (si non
spécifié, il s’agit de la branche
courante). Donc inutile ici.

Nom du serveur vers lequel

faire le transfert (si non
spécifié, transfert fait vers le
serveur par défaut ; voir git
remote -v). Donc inutile ici.
Raccourci de « --set-
upstream » : permet de fixer la
branche distante suivi par la
branche locale si ce n’es déjà
fait. Donc inutile ici.

Bruno Mermet
27
Démarrer un nouveau projet
3. Transférer une première version sur
le serveur
● git push -u origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 220 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://www-apps.univ-lehavre.fr/forge/mermetb/MonProjet.git
* [new branch] master -> master

● git branch -vv

* master 30d9696 [origin/master] creation fichier ReadMe

Bruno Mermet
28
Page d'accueil d'un projet (après
création d’une première version)

Bruno Mermet
29