Passer à Git pour une équipe qui travaille tous les jours avec CVS. De la migration technique au choix du workflow de travail en passant par l'accompagnement nécessaire. Nous dresserons le bilan des problèmes rencontrés ainsi que des bénéfices retirés lors de cette migration.

1. REX - Passage de CVS à Git
Pierre Templier
@ptemplier

2. Ippon Technologies © 2015
Sommaire
● Contexte
● Migration technique
● Choix workflow(s) de travail
● Accompagnement et mise en oeuvre
● Bilan : problèmes et bénéfices
CVS

3. Ippon Technologies © 2015
Contexte
● Client utilisant CVS au sein d'une petite équipe : ~10 personnes.
● Volonté de changer pour quelque chose de plus récent.
● 2 solutions envisagées : SVN et Git
○ Client d'abord tenté par SVN car peu de changement dans l'utilisation par
rapport à CVS.
○ Mais un projet a été réalisé par une société externe sur un repo privé
GitHub, le choix de Git s'est donc fait sur la facilité de récupérer l'historique
de ce projet.

4. Ippon Technologies © 2015
Migration technique (1)
● Utilisation de cvs2svn qui dispose d’un module cvs2git : http://cvs2svn.tigris.
org/cvs2git.html
● Besoin d’accéder physiquement à une copie du repo CVS
● Fichier de config permettant
○ De transcoder les utilisateurs (trigramme => “Prénom Nom” + Email)
○ D’exclure des fichiers/dossiers inutiles
■ ‘target' ou ‘src/webapp/WEB-INF/lib’
● En sortie, 2 fichiers au format fast-import
○ git --bare init .
○ cat git-{blob,dump}.dat | git fast-import

5. Ippon Technologies © 2015
Migration technique (2)
● 4 repositories CVS
○ ~200 projets
○ Chaque repo CVS contient beaucoup de projets qui
n'ont rien à voir entre eux
● 1 répertoire du repo CVS deviendra un repository Git
● Création d'un script bash pour automatiser les exports
vers des repositories Git
● Avant la migration on verrouille en écriture chaque
repository CVS
○ touch writers

6. Ippon Technologies © 2015
Utilisation
● Repositories exposés via GitBlit
○ Webapp java
○ Gestion des Droits
○ Recherche
○ Navigation dans le code
○ Statistiques
○ Historique des commits

7. Ippon Technologies © 2015
Impact hors développement
● Faibles impacts sur l’usine logicielle
● Changement de l’url scm dans le pom : utilisé par le plugin maven release
● Ajout du plugin Git dans Jenkins
● Création d’un utilisateur Jenkins dans Gitblit et renseignement des
credentials dans le settings.xml maven utilisé par jenkins

8. Ippon Technologies © 2015
Workflows utilisés
Centralisé
Feature Branches
Gitflow

9. Ippon Technologies © 2015
Configuration commune
// renseignements sur l'utilisateur présents dans les commits
git config --global user.name "John Doe"
git config --global user.email johndoe@mycorp.com
// sauts de lignes Linux dans les sources
git config --global core.autocrlf true
// pull --rebase par défaut pour éviter de polluer l'historique
git config --global branch.master.rebase true
git config --global branch.autosetuprebase always
// stocke le mdp en clair pour ne pas le retaper
git config --global credential.helper store
Utilisation de rebase lors des pull

10. Ippon Technologies © 2015
Mise en oeuvre
● Volonté de l'équipe d'utiliser le client graphique Git intégré à Eclipse
● Habitude de fonctionner avec le client CVS d’Eclipse
● Habitude de rester dans l’IDE pour les interactions SCM
● Migration des projets un par un plutôt que tout d'un coup
● Formation initiale sur le poste du développeur
● Différentes zones de travail : Workspace, Index, Repository Local, Repository Distant
● Les commandes à connaître : clone, commit, push, pull, stash, reset
● Explication du paramétrage pull --rebase
● Savoir où on en est : `git status` / vue historique Eclipse
● Incitation à créer des branches dès que le besoin s’en fait sentir (feature branch)
● Puis aide au fur et à mesure des besoins/problèmes.
● Dans l'équipe 2 autres personnes avaient déjà travaillé avec git, cela a facilité la monté en compétence car plusieurs
personnes pouvaient aider.
● Pas de modification de commits déjà publiés (i.e. pas de push --force )
● Interdit au niveau de Gitblit

11. Ippon Technologies © 2015
Problèmes - Eclipse
● Impossible de comparer un fichier lors d'un merge
● Présente des fichiers comme modifiés alors qu'il ne sont pas modifiés
○ info différente de git status
● Impossible de comprendre ce que fait le "mark as merged"
● Résoudre un conflit en faisant add n'est pas intuitif sous eclipse
○ git status nous donne directement cette information
● Lorsqu'un push échoue, message d’échec que l'on prend pour un succès
● Obligation de jongler entre les vues Eclipse
○ Vue Projet
○ Vue Git Repositories
○ Vue Historique
○ Vue Staging

12. Ippon Technologies © 2015
Problèmes - Habitudes
● Volonté de récupérer uniquement les changements sur certains fichiers
● plutôt que tous ceux ramenés par un pull
● Pull implique de commiter ou stasher ses changements au préalable
● Tendance à garder 1 projet par branche dans son workspace
● 1 branche sur master
● 1 branche sur develop
● Nouveau vocabulaire, nouveaux concepts
● Commit a un sens différent en CVS et en Git
● Stash est une pile si on sauve plusieurs fois ses fichiers temporaires ils ne sont plus sur le dessus de
la pile et 'git stash pop' ne les ramène pas

13. Ippon Technologies © 2015
Leçons tirées
● Il ne faut pas sous estimer le travail d'accompagnement pour passer à Git et oublier ses habitudes
CVS. Il est important que personne ne reste bloqué à cause de l’outil, il faut donc qu’il y ait toujours
une personne capable de dépanner sur Git.
● Mieux vaut passer petit à petit les projets sous Git : cela permet de monter sereinement en
compétence sur Git et d'abord sur des petits projets
● Le client en ligne de commande donne souvent des informations plus pertinentes qu'Eclipse et est plus
prédictible
● Changement d’habitude dans le workflow de travail : commits réguliers en local puis push après revue
de ces commits, le fait d’avoir 2 étapes permet plus de vérification et de réorganiser ses commits avant
de pusher (squash ou rebase interactif).

14. Ippon Technologies © 2015
Bénéfices
Ce qu’en tirent les développeurs
○ Un certain confort à travailler en local (plus de commits régulièrement)
○ Une préparation plus fine des commits avant de les publier
○ Un facilité à travailler sur des branches dès que le besoin s’en fait sentir
○ Renommages de fichiers bien suivis
○ Commits comme un ensemble cohérent de changements sur différents fichiers
○ Historique complet notamment lors du merge de branche (pas d’info sur les branches mergées en CVS)
○ Graphe historique/branches permet de bien se repérer dans les sources
○ Rapidité générale du système
○ Facilité de report d’un hotfix via cherry-pick
Dans le futur
On pourrait envisager d’utiliser des workflow de type Pull Request, notamment à des fins de code review systématisé

15. Questions ?
Contact : @ptemplier