Cours Génie Logiciel Licence Pro 2016, la gestion de versions

La gestion de versions

Concepts / Subversion / Git

IUT de Nantes – Département Informatique

LINA - Laboratoire d’Informatique de Nantes Atlantique

Cours de Licence professionnelle 2016

Version 1.10 du 05 septembre 2016 / http://florat.net/cours_vcs/cours.html / Feuille de TP

Naviguer avec les fléches ou la molette de la souris

Agenda (en vert, les TP)

1-Concepts généraux, SVN	2-Pratique de SVN	3-Présentation de Git	4-Pratique de Git	5-Travail collaboratif avec Git
TP1 : Motivations Historique Notions et terminologie Règles de l'art Focus sur SVN	Outils Règles de l'art SVN Présentation des commandes de base TP2 : commandes de base	Présentation des concepts	Présentation des commandes de base TP3 : commandes de base en équipe	Outils Règles de l'art Les différents types de workflow TP4 : utilitaires Git

Motivations

TP1 : Que serait notre vie sans VCS ?

Vous faites partie d’une équipe de développement qui intervient sur la réalisation d’une application

Comment conserver l’historique et revenir en arrière ?
Comment partager le développement entre plusieurs personnes ?

avec des contributeurs Open Source ?

Comment gérer plusieurs versions à la fois ?
Versions de maintenance, experimentation de nouvelles fonctionnailités, plusieurs clients...
Comment tracer les modifications ?

En utilisant un VCS !

Usage

Utilisateurs : les développeurs et les intégrateurs
Le VCS est avec l'IDE l'outil principal du développeur
Principalement stockage de fichiers texte

Le VCS au sein de l'usine logicielle

Quels fichiers gérer en configuration ou pas ?

Le projet (et toutes ses versions) doit être auto-porteur

Fichiers source (.java, .c, .html, .css...)
Fichiers binaires non dérivés des sources, images par exemple
Fichiers de build (maven: pom.xml, npm: package.json ...)

Pas en configuration :

Fichiers temporaires, générés ou compilés
Librairies (utiliser un dépot Maven)

Selon les politiques :

Fichiers projets de l'IDE (.project, .idea ...)
Personnalisation et historique de l'IDE

Modèles de gestion des accès concurrents

Modèle de contrôle de concurrence pessimiste: fichiers réservés en lecture seule
Modèle de contrôle de concurrence optimiste : conflits possibles mais possibilité de réconcilier
Quelques VCS (Clearcase, SVN etc) mixtes
La plupart des VCS sont à contrôle optimiste : CVS, SVN, Git, Mercurial, BitKeeper etc.
Le modèle pessismiste est obsolète et pousse à de mauvaises pratiques de développement, à éviter !

Modeles centralisés / client-serveur

Exemples : CVS, SVN, ClearCase, Perforce

Un serveur gère l'intégralité des révisions (le dépôt), les développeurs récupèrent les modifications des autres et y ajoutent les leurs

Modeles distribués

Exemples : Git, Mercurial, Baazar, BitKeeper

Chaque développeur possède un dépôt entier mais les dépôts peuvent s'échanger des modifications

Historique

Retour d'expérience : quels VCS dans les grands comptes ?

Concepts généraux

SCM, VCS, outil de versioning, GCL	Source Control Management, Version Control System : outils permettant de gérer plusieurs versions de sources
dépôt, référentiel [repository, depot]	Un dépôt est une sortie de base de données de sources contenant toutes les révisions (tout l'historique) des fichiers ainsi que des données de gestion (méta-données) associées
Copie locale, espace de travail [working copy/directory/workspace]	Copie locale éditable d'une révision du dépôt et dont les modifications peuvent ensuite être validées (commitées) dans le dépôt

Concepts généraux

Commit, validation, "mettre en conf", [commit,checkin]	(verbe) Enregistrer des modifications de la copie locale vers dépôt. (nom) modifications elles-mêmes.
Checkout	Récupération dans la copie locale de la version du dépôt
Update	Mise à jour dans sa copie locale d'un fichier du dépôt

Concepts généraux

Branche [branch]	Une ligne de développement d'un projet. Sert par exemple à : Gérer une version spécifique pour un client Gérer des branches de maintenance corrective Tester une idée, un refactoring sans risques
Fork [fork]	Créer une nouvelle branche

Concepts généraux

Merge, fusion [merge]	Fusion des modifications de deux branches
Tag, étiquette [tag, label]	Photo du dépôt à un moment précis. Etiquette d'un ensemble cohérent de sources. Un tag peut présenter un aspect contractuel (signature numérique)

Concepts généraux

Modification concurrente

Tentative de mise à jour de sources ayant divergées

Concepts généraux

Conflit [conflict]

Modification concurrente d'une même zone de texte. La résolution est manuelle.

Exemple de conflit :

<<<<<<< commit A'
int i = 0; 
======= 
int i = 1; 
int j=0;
>>>>>>> commit A''

Bonnes pratiques

Le code commité doit toujours compiler
Commiter et merger souvent, mettre à jour régulièrement
Utiliser avec un outil de gestion de tickets (Trac, Mantis, GitHub...)
Grouper les modifications en commits cohérents
Ne jamais commiter du code mort (en commentaire ou pas)
Formatage coersitif des sources ASAP
Version scheme : [X].[Y].[Z], exemple : 1.2.3

Programme : [major (refonte complète)].[minor (évolution)].[no fix (correction) en partant de zéro]
Librairie : [compatibilite API].[évolution].[fix], voir le semantic versionning http://semver.org/

Bonnes pratiques / Convention message de commit

Une ligne de contexte (max 50 caractères)
Une ligne vide (options -m " et retour charriot)
Un paragraphe détaillé (largeur 72 caractères max), liens vers numéros de tickets
Présent : "corrige", pas "a été corrigé"
Exemple :

							Correction bug #1456:Problème fichier bootstrap vide 
										
							Corrige une NPE se produisant quand le fichier bootstrap existe mais 
							est vide. 
							Reproduit uniquement par TU, non reporté par les utilisateurs 
							à ce point. 
							Voir aussi le bug #1674.

Zoom sur Subversion (SVN)

Open Source (licence Apache et BSD), écrit par CollabNet, projet fondation Apache depuis 2010
Réécriture de CVS : SVN = sorte de "CVS++"
SVN est très populaire dans les grands comptes
Outil facile d'accès, intuitif
VCS de type centralisé (client-serveur)
VCS principalement à verrouillage optimiste (merge)

Fonctionnement spécifique de SVN

Révision de niveau dépôt, donc no révision fichiers augmente même sans modification
Branche = Tag = répertoire
Une copie locale par branche*

* il est néanmoins possible d'utiliser svn switch

Outils SVN

[Tous OS] client en ligne de commande
[Tous OS] Plugins Eclipse : Subclipse ou Subversive
[Windows] TortoiseSVN (intégration dans l'OS)

Initalisation d'un dépôt SVN

Sur le serveur SVN :

svnadmin create nom depot
mkdir trunk tags branches

Si le projet existe déjà :
- [soit import initial] sur le serveur SVN
```
$ svn import
```
- [soit commit d'initialisation] sur un client SVN, checkout du projet vide puis ajout des sources et commit :
```
$ svn checkout url
$ svn add * --force
$ svn commit
```

URL d’accès au dépot

Accès direct au référentiel (par répertoire)
```
file:///répertoire
						
```
Accès distant par le protocole HTTP (par WebDAV)
```
http://[user@]server/chemin
						
```
Accès distant par le protocole https (i.e. avec SSL)
```
https://[user@]server/chemin
						
```
Accès distant par un serveur svnserve (daemon lancé sur un serveur, port par défaut : 3690)
```
svn://[user@]server/chemin
						
```
Accès distant par un serveur svnserve (avec tunnelling SSH)
```
svn+ssh://[user@]server/chemin
						
```

Commande de récupération et de mise à jour

Récupération

svn checkout url [nom personnel]

Crée une copie locale des fichiers présents dans le dépôt pour le chemin demandé dans l'URL

Mise à jour

svn update

Synchronise la version de travail avec les modifications présentes dans le référentiel (si nécessaire)
Effectue un merge le cas échéant
Si le merge échoue, résolution manuelle des conflits

Commande de commit

svn commit [-m "message"]

Met à jour le référentiel avec les modifications locales
Peut échouer si le référentiel a été mis à jour entre temps : update obligatoire

Commandes de manipulation des fichiers et répertoires

Ajout de fichiers ou répertoires
```
svn add fichier|répertoire
						
```
Suppression de fichiers ou répertoires
```
svn rm fichier|répertoire
					
```

Renommage/déplacement de fichiers ou répertoires

svn mv fichier|répertoire(source) nom|répertoire(cible)

Il faut ensuite commiter pour intégrer ces modifications dans le dépôt

Détecter et visualiser les modifications

svn info url affiche des informations de l'élement (auteur dernière modification, date etc.)

svn status affiche l'état de la copie locale par rapport au dépôt

' '   No modifications.
'A'   Item is scheduled for addition.
'D'   Item is scheduled for deletion.
'M'   Item has been modified.
'R'   Item has been replaced in your working copy.
'C'   The contents of the item conflict with updates received from the repository.
'I'   Item is being ignored (e.g., with the svn:ignore property).
'?'   Item is not under version control.
'!'   Item is missing (e.g., you moved or deleted it without using svn).

svn diff affiche les différences entre révisions ou fichiers

svn diff -r7:13 toto.c 
svn diff referentiel/tags/release-1-0 referentiel/branches/feature

Visualisation des messages des logs et des auteurs de révisions

svn log affiche les différents messages de commit
svn blame affiche l'auteur de modifications d'un fichier ligne par ligne

Résolution de conflits

svn update propose de résoudre le conflit de façon interactive (forcer nos modifs, les leurs, éditer...)
Si la résolution est remise plus tard (p=postpone), il faudra utiliser: svn resolve --accept <option de résolution> <fichier> quand le conflit sera corrigé. puis faire un svn commit.

Options de résolution : working: version résolue manuellement, base: version du serveur avant modifications locales, mine-full : notre version modifiée localement avant le conflit, theirs-full : révision serveur

Note : ne pas utiliser la commande svn resoved qui est dépréciée

Pointeurs pour une utilisation plus avancée

Voir la commande svn propset svn:ignore fichier_a_ignorer . pour ignorer des fichiers ou répertoires
Les externals svn propset svn:externals
Voir fonctions de branching et merge : svn copy, svn switch et svn merge
Voir fonctions de tagging : svn copy
Keywords comme $$Date$$, $$Author$$, $$Rev$$, à éviter.
Voir manuel SVN : [1] et refcard : [3]

Bonnes pratiques (spécifiques SVN)

Convention de la structuration dépôt :
```
/tags
/trunk
/branches
```
Ne pas copier, renommer ou déplacer des fichiers ou des répertoires avec les commandes systèmes. Utiliser svn (add|mv|rm) et commiter à chaque modification
Un problème ? svn help commande

Quelles structurations pour un dépot multi-projets ?

Copyright CC BY-NC-ND Bertrand Florat

Quelques limitations

Impact du réseau : latences
Pas possible de travailler off-line ou sans le serveur
Limitations pour merges complexes (modification + déplacement)
Impose un modèle organisationnel simple mais limité
Problème du choix de structures du dépôt : par branches/tags ou par projets ?
Un workflow de validation nécessite des tags ou branches
Forte utilisation espace disque des copies locales sur les clients et du dépôt sur le serveur (malgré le cheap-copy)

-> Talk de Linus Torvalds, comparaison entre Git et SVN: [9]

TP2 Commandes SVN de base

Voir la feuille de travaux pratiques

Zoom sur Git

I'm an egotistical bastard, and I name all my projects after myself. First Linux, now git

Linus Torvalds + 3 semaines = Git (utilisé pour le kernel Linux dès avril 2005)
VCS le plus puissant et le plus performant mais non trivial
Open Source (licence GPL)
VCS de type distribué et contrôle optimiste uniquement
Programme "Unix-like" : commandes de haut niveau (porcelain) utilisant commandes bas niveau (plumbing)

Quand utiliser Git ?

Equipes formées
Projets Open-Source (GitHub/Bitbucket)
Organisations décentralisées, développement non linéaire
Latences réseau importantes
Très grosses volumétries

Note : possible d'utiliser client git vers dépôt SVN (git-svn mais pas recommendé)

Quelques clients Git

Tous OS
- egit/jgit (plugin Eclipse)
Gnu/Linux

git (ligne de commande) + gitk (GUI pour l'historique)
tig : navigateur Git en ncurses

Microsoft Windows
- Git for Windows : git en ligne de commande + un éditeur graphique d'historique
- TurtoiseGit : éditeur graphique intégré dans l'OS
Mac OSX
- Tower
- GitBox

Différences immédiates vis à vis de SVN

Tout est beaucoup plus rapide :-)))
Un seul projet dans l'IDE par branche/tag
Impossible de commiter un répertoire vide
L'index (staging area)
On utilise beaucoup plus les branches

Configurer git

Attention! ne surtout pas oublier de configurer Git avant tout commit, plus possible ensuite de changer nom/e-mail (sauf perte historique)

Trois niveaux de configuration :

/etc/gitconfig : configuration multi-dépôt pour tous les utilisateurs de la machine
~/.gitconfig : configuration multi-dépôt pour l'utilisateur (en général, seul ce fichier est à modifié)
/chemin dépôt/.git/config : configuration du dépôt

Configuration globale (multi-dépôts) de l'utilisateur courant :

$ git config --global user.name "John Doe"  //Obligatoire !
$ git config --global user.email johndoe@example.com   //Obligatoire !
$ git config --global push.default simple //Mode de push
$ git config --global core.editor vim   //choix de l'éditeur, vi par défaut
$ git config --global merge.tool vimdiff //choix de l'outil de diff

Création d'un nouveau dépôt

Note : un seul projet par dépôt pour raison d'isolation et de performances

$ cd ~/depots/my-app
$ git init

Le contenu du répertoire (projet Maven/Eclipse) sera :

~/depots/my-app
                   /.git  //dossier des meta-données git
                   /.project
                   /.classpath
                   /pom.xml
                   /src/main/java
                   /...

Dépôt nu (sans copie locale) :

Créé avec : git init --bare
Convention nommage : repertoire my-app.git

Récupération d'un dépôt existant

$ git clone url

Format des URLs :

ssh://[user@]host.xz[:port]/path/to/repo.git/
git://host.xz[:port]/path/to/repo.git/
http[s]://host.xz[:port]/path/to/repo.git/
ftp[s]://host.xz[:port]/path/to/repo.git/
rsync://host.xz/path/to/repo.git/
file:///path/to/repo.git/  =  /path/to/repo.git/

Le dépôt que l'on vient de cloner est spécial : il est appelé origin (upstream repository)

Structure de base de Git

Git stocke des : trees, blobs, tags et commits, tous référencés par un hash SHA-1 unique (intégrité)
Les références (refs) sont des noms symboliques des hashs

Copyright CC BY-SA-NC Scott Chacon

SHA-1 transforme une suite de caractères de 1 à 2^64 bits en un nombre de 160 bits. Non réversible. Exemple : a6e757a90e389270e75428473858e04f8c71121b. Versions réduites : a6e757a. Risque collisions infinitésimaux.

Les commits dans Git

Chaque commit possède [1..n] parents
Donc l'historique forme un graphe
Le commit est de niveau dépôt (pointe sur le tree racine)
Notation : ref^n (nième père) et ref~n (nième premier père)

Copyright CC BY-SA-NC Scott Chacon

Branching

Branche = ref (pointeur) vers un commit

Créer une branche (fork) et s'y positionner :

$ git branch mabranche
$ git checkout mabranche
ou : $ git checkout -b mabranche

Note : si changement de branche avec des modifications non commitées, git merge les copies locales sauf si conflit detecté (dans ce cas, on peut forcer tout de même le merge avec checkout -m).

Branching (suite)

Branche 'HEAD' = ref vers branche courante

Images Copyright CC BY-SA-NC Scott Chacon

Conventions :
- master : branche par défaut
- develop : branche de développment (instable)

Merge de branches

Merge branche develop dans la branche master (courante):
```
$ git merge develop
```
Applique tous les commits de develop dans master depuis le dernier merge entre ces deux branches.
Plusieurs algorithmes, défaut : "three ways merge"
Si la branche courante n'a pas évolué depuis dernier merge, fast-forward (ff)
Si divergence (non-ff), merge automatique. Conflits possibles

Images Copyright CC BY-SA-NC Scott Chacon

Branches remote

Branche remote (distante) : branche locale cache d'une branche d'un dépôt distant

Exemples :

remotes/origin/HEAD -> origin/master
remotes/origin/develop
remotes/origin/master
remotes/bob/feature300

Lecture seule, se resynchronise avec son dépôt distant avec git fetch et git push
Par défaut, push refusé si branche distante a divergé
git pull = git fetch + git merge

Tracking remote branch : branche remote avec refspec, push/fetch/pull sans arguments (le '+' signifie qu'on met à jour la référence même si ce n'est pas un ff)

							
[remote "origin"]  
url=git@gitorious.org:/my-app.git 
fetch=+refs/heads/*:refs/remotes/origin/* 
pull=refs/heads/*:refs/remotes/origin/*
push = refs/heads/master:refs/heads/qa/master

Après un git clone, branches tracking remote automatiquement créées : refs/origin/branche

Branches remote

Cycle de vie d'un fichier dans la copie locale

Index/staging area : sas (facultatif) de "pré-commit"
Permet de sélectionner les modifications à commiter
Débrayable avec l'option -a de git commit
Attention : il faut obligatoirement faire git add pour un nouveau fichier
Status des fichiers : git status
Une fois prêt, commit : git commit
Commit interactif de partie de fichier avec l'option -p (patch)

Commandes git de base

Voir aussi la cheat sheet [5]

Référence par défaut : HEAD, branche par défaut : master

Commandes de changement de statut de la copie locale : checkout [-m], add, rm, mv, commit, stash
Commandes de correction : revert, reset (soft|mixed|hard), commit --amend
Commandes de branching : branch, merge, cherry-pick, rebase
Commandes d'informations : log, status, diff, show, blame, reflog
Commandes de travail sur branches distantes : remote, push, fetch, pull

Historique avec git log

Spécifier des intervales de temps
```
git log --since=2.weeks
```
Voir les diff de chaque révision : option -p
Voir un graphe des révisions : option --graph
branche1..branche2 : tous les nouveaux commits de la branche2 depuis le fork d'avec la branche1
[--left-right] branche1...branche2 : tous les nouveaux commits des deux branches depuis le fork

Comparaison avec git diff

Comparer deux références ('..' et 'HEAD' optionnels) :

git diff HEAD..origin/hotfix/release-1_0
git diff ..origin/hotfix/release-1_0
git diff origin/hotfix/release-1_0

Options -w pour ignorer les différences de formatage
Toutes les différences entre deux branches :
```
$ git diff branche1..branche2
```
Seulement les différences de la branche2 avec le dernier commit commun entre branche1 et branch2 (qu'ai-je fait dans la branche2 depuis que mes deux branches ont divergées ?) :
```
$ git diff branche1...branche2
```
Note : les notations '..' et '...' n'ont pas la même signification que les ranges utilisés (entre autres) par git log

Attention ! git diff sans arguments compare copie locale et index, pas HEAD

Merging

$ git checkout master
$ git merge iss53

C'est la copie locale de la branche courante qui est modifiée
Si conflit, plus possible de commiter :
- Soit résolution manuelle des conflits
- Soit git checkout --ours fichier
- Soit git checkout --theirs fichier
- puis (dans les trois cas), add et commit
- Revenir à l'état antérieur : git reset --merge

Bonne pratique : option --no-ff pour créer un commit de merge même en cas de FF

Images Copyright CC BY-SA-NC Scott Chacon

Rebasing

$ git checkout experiment
$ git rebase master

Sérialise deux branches
Rend l'historique beaucoup plus lisible (linéaire)
Utiliser avec git pull :
```
$ git pull --rebase
```
Permet de réécrire son historique (rebase interactif)
Attention : n'utiliser rebase qu'avec ses branches locales, ne jamais rebaser un commit qui a déjà été pushé

Images Copyright CC BY-SA-NC Scott Chacon

Utilitaires

Rebase interactif pour réécrire son historique local
```
git rebase -i
```

debugage multi-révisions avec bisect

git bisect [good|bad|start|skip|run|reset]

Commit partiel dans un même fichier :
```
git add -p
```
(option patch)
Les alias
```
git config --global alias.co checkout
```
L'IHM gitk
Changelog avec shortlog :
```
$ git shortlog
```

Fancy CLI

Coloriser :
```
git config --global ui.color true
```

.bashrc

Templates de messages de commit

git config --global commit.template fichier

Recherche multi-revisions avec git grep :

$ git grep [--name-only] texte ref

Ignorer des fichiers

Fichier .gitignore à la racine de la copie locale (lui-même commité). Exemples :

# a comment - this is ignored
# no .a files
*.a       
# but do track lib.a, even though you're ignoring .a files above
!lib.a    
# only ignore the root TODO file, not subdir/TODO
/TODO     
# ignore all files in the build/ directory
build/    
# ignore doc/notes.txt, but not doc/server/arch.txt
doc/*.txt 
# Exemple réél :
.metadata
bin
build
.settings
*.class

Possible de positionner un fichier .gitignore n'importe où
Peut être défini au niveau utilisateur dans le fichier donné par ~/.gitconfig propriété core.excludesfile

Bonnes pratiques Git, à faire

Configurer Git (nom et e-mail) avant tout commit
Utiliser les commandes git rm, git mv au lieu des commandes sytème
Bloquer les push forcés et les suppressions coté serveur publique avec les options receive.denyNonFastForwards=true et receive.denyDeletes=true
Nettoyer son historique avant de le pousser si confus
Utiliser l'option merge -no-ff
N'utiliser rebase que sur les branches locales

Bonnes pratiques Git, à éviter

Pas de merge avec modifications non commitées (retour arrière difficile)
Ne pas forcer les push (avec push -f ou via refspecs), risque de perte de commits
Ne pas pousser des branches privées
Ne pas modifier un commit publié

TP3 Commandes Git de base

Voir la feuille de travaux pratiques

Le coding social

Réseaux sociaux de code comme
- GitHub
- Bitbucket
"Zone grise" entre l'équipe et les utilisateurs
Discussions sur le code (mode wiki)
Exemple de politique "grise" :

Les types d'organisations

Centralisé (SVN/CVS like) avec un "blessed server"
Hiérarchisé, par exemple à 3 grades : contributeur, vérificateur, intégrateur
Patch/pull request : un projet + des contributeurs externes

Voir [12]

Worflows avec Git, comment gérer ses branches ?

Forker, commiter et merger souvent
Historique flexible sur les branches privées, stable en public
Branches privées (topic, experimentation) ou publiques
Branches "Short life" (topic, maintenance) ou "long run" (master)
Structuration des branches dépend du nombre de versions maintenues
Graduation : de plus en plus stable (voir git-flow)

Voir aussi man gitworkflows

Un worflow pré-cablé très populaire : git-flow

Voir [8]

Les forges Git

GitHub (https://github.com/)
BitBucket (https://bitbucket.org/)
Une forge privée : GitLab (https://gitlab.com/)

GitLab

Non abordé dans ce cours

Voir [4] pour approfondir

Détail des différents types de protocoles
Les commandes plumbing
L'administration server-side (gitolite, gitweb etc.)
Les hooks client et serveur
La gestion des contributions exterieures (git format-patch, git request-pull et git am)
Les attributs (comportement spécifique par chemin)
Les sous-modules
L'adaptateur git-svn
...

Un Dropbox-like basé sur git : Sparkleshare

TP4 Utilitaires Git

Voir la feuille de travaux pratiques

Références

[1] Manuel SVN : http://svnbook.red-bean.com
[3] Refcard SVN : http://www.open.collab.net/community/subversion/articles/CollabNet_SVNQuickReferenceCard.pdf
[4] Pro-git : http://git-scm.com/book. Version fr : http://git-scm.com/book/fr/.
[5] Git cheat sheet : http://ndpsoftware.com/git-cheatsheet.html
[7] Script d'autocomplétion git : https://raw.github.com/git/git/master/contrib/completion/git-completion.bash
[8] Git-flow : https://github.com/nvie/gitflow
[9] Talk Linux Torvalds Google : http://www.youtube.com/watch?v=4XpnKHJAok8
[10] A Visual Git Reference : http://marklodato.github.io/visual-git-guide/index-en.html
[11] Git Ready (astuces et références vers docs) : http://gitready.com/
[12] Typologies de workfow par Atlassian : https://www.atlassian.com/fr/git/workflows#!workflow-feature-branch
[13] Tutorial interactif sur les branches avec Git : http://pcottle.github.io/learnGitBranching/

La gestion de versions

Agenda (en vert, les TP)

Motivations

Usage

Le VCS au sein de l'usine logicielle

Quels fichiers gérer en configuration ou pas ?

Modèles de gestion des accès concurrents

Modeles centralisés / client-serveur

Modeles distribués

Historique

Concepts généraux

Concepts généraux

Concepts généraux

Concepts généraux

Concepts généraux

Concepts généraux

Bonnes pratiques

Bonnes pratiques / Convention message de commit

Zoom sur Subversion (SVN)

Fonctionnement spécifique de SVN

Outils SVN

Initalisation d'un dépôt SVN

URL d’accès au dépot

Commande de récupération et de mise à jour

Récupération

Mise à jour

Commande de commit

Commandes de manipulation des fichiers et répertoires

Détecter et visualiser les modifications

Visualisation des messages des logs et des auteurs de révisions

Résolution de conflits

Pointeurs pour une utilisation plus avancée

Bonnes pratiques (spécifiques SVN)

Quelques limitations

TP2 Commandes SVN de base

Zoom sur Git

Quand utiliser Git ?

Quelques clients Git

Différences immédiates vis à vis de SVN

Configurer git

Création d'un nouveau dépôt

Récupération d'un dépôt existant

Structure de base de Git

Les commits dans Git

Branching

Branching (suite)

Merge de branches

Branches remote

Branches remote

Tags

Cycle de vie d'un fichier dans la copie locale

Commandes git de base

Historique avec git log

Comparaison avec git diff

Merging

Rebasing

Utilitaires

Ignorer des fichiers

Bonnes pratiques Git, à faire

Bonnes pratiques Git, à éviter

TP3 Commandes Git de base

Le coding social

Les types d'organisations

Worflows avec Git, comment gérer ses branches ?

Un worflow pré-cablé très populaire : git-flow

Les forges Git

Non abordé dans ce cours

Un Dropbox-like basé sur git : Sparkleshare

TP4 Utilitaires Git

Références