De SVN à Git

De SVN à Git – Préparation de la migration

Dans Pourquoi Git ?, nous avons discuté des nombreuses manières dont Git peut accroître l'agilité de votre équipe. Une fois que vous avez décidé de faire la transition, l'étape suivante consiste à déterminer comment vous allez migrer votre workflow de développement actuel vers Git.

Cet article expose quelques changements majeurs qui accompagneront votre transition de SVN vers Git. La chose la plus importante à retenir pendant la migration est que Git n'est pas SVN. Pour exploiter le plein potentiel de Git, faites de votre mieux pour repenser le contrôle de version.

For administrators

L'adoption de Git peut aussi bien s'effectuer en quelques jours qu'en plusieurs mois, suivant la taille de votre équipe. Cette section traite des principales préoccupations des responsables en ingénierie lorsqu'il s'agit de former les employés à Git et de migrer les dépôts de SVN vers Git.

Basic Git commands

Autrefois, Git était connu pour nécessiter un apprentissage de longue haleine. Cependant, les mainteneurs Git n'ont cessé d'apporter des améliorations, comme des valeurs par défaut sensibles et des messages d'aide contextuels, pour rendre le processus d'intégration plus agréable.

Atlassian propose un ensemble complet de tutoriels Git personnalisés, ainsi que des webinaires et des sessions de formation en direct. La combinaison de toutes ces options fournira toutes les clés à votre équipe pour se lancer avec Git. Pour commencer, voici une liste de commandes Git de base pour apprendre à l'utiliser :

Tâche Git Remarques Commandes Git
Dire à Git qui vous êtes Configurez le nom et l'adresse e-mail de l'auteur qui seront utilisés avec les commits. Remarque : Git efface certains caractères (par exemple, le point final) dans user.name. git config --global user.name "Sam Smith"
git config --global user.email sam@example.com
Créer un nouveau dépôt local   git init
Faire le checkout d'un dépôt Créez une copie de travail d'un dépôt local : git clone /path/to/repository
  Pour un serveur distant, utilisez : git clone username@host:/path/to/repository
Ajouter des fichiers Ajoutez un ou plusieurs fichiers dans la zone de staging (index) : git add <nom_fichier>git add *
Commiter Commitez des changements vers head (mais pas encore vers le dépôt distant) : git commit -m "Message de commit"
  Commitez tous les fichiers que vous avez ajoutés avec git add, ainsi que tous les fichiers que vous avez modifiés depuis lors : git commit -a
Pusher Transférez les changements vers la branche master de votre dépôt local : git push origin master
Statut Répertoriez les fichiers modifiés et ceux que vous devez encore ajouter ou commiter : git status
Se connecter à un dépôt distant Si vous n'avez pas connecté votre dépôt local à un serveur distant, ajoutez le serveur pour pouvoir le pusher : git remote add origin <serveur>
  Recensez tous les dépôts distants actuellement configurés : git remote -v
Branches Créez une nouvelle branche et basculez vers celle-ci : git checkout -b <nom_branche>
  Passez d'une branche à l'autre : git checkout <nom_branche>
  Recensez toutes les branches de votre dépôt et indiquez la branche sur laquelle vous travaillez : git branch
  Supprimez la branche de fonctionnalité : git branch -d <nom_branche>
  Pushez la branche vers votre dépôt distant pour que d'autres utilisateurs puissent l'utiliser : git push origin <nom_branche>
  Pushez toutes les branches vers votre dépôt distant : git push --all origin
  Supprimez une branche de votre dépôt distant : git push origin :<nom_branche>
Effectuer des mises à jour à partir du dépôt distant Fetchez et mergez des changements sur le serveur distant dans votre répertoire de travail : git pull
  Mergez une branche différente dans votre branche active : git merge <nom_branche>
  Affichez tous les conflits de merge : comparez les conflits par rapport au fichier de base et prévisualisez les changements, avant de faire un merge : git diff
git diff --base <nom_fichier>
git diff <branche_source> <branche_cible>
  Une fois que vous aurez résolu les conflits manuellement, marquez le fichier modifié : git add <nom_fichier>
tags Vous pouvez utiliser des labels pour indiquer un ensemble de changements significatif, comme une livraison : git tag 1.0.0 <ID_commit>
  L'ID de commit constitue la partie principale de l'ID de l'ensemble de changements, mais il doit être unique. Obtenez l'ID en utilisant : git log
  Pushez tous les tags vers votre dépôt distant : git push --tags origin
Annuler des changements locaux En cas d'erreur, vous pouvez remplacer les changements apportés à votre arborescence de travail avec le dernier contenu de head. Les changements déjà apportés à l'index et les nouveaux fichiers seront conservés. git checkout -- <nom_fichier>
  Au lieu de cela, pour renoncer à vos commits et à vos changements locaux, fetcher le dernier historique du serveur et faire pointer votre branche master locale vers cet historique, procédez comme suit : git fetch origin
git reset --hard origin/master
recherche Recherchez « foo() » dans le répertoire de travail : git grep "foo()"

Git Migration Tools

Il existe un certain nombre d'outils pour vous aider à migrer vos projets existants de SVN vers GIT, mais avant de choisir vos outils, vous devez définir la manière dont vous allez migrer votre code. Vous avez le choix entre plusieurs solutions :

  • Migrer toute votre base de code dans Git et arrêter complètement d'utiliser SVN.
  • Ne pas migrer les projets existants vers Git, mais utiliser Git pour tous les nouveaux projets.
  • Migrer quelques projets dans Git et continuer à utiliser SVN pour d'autres projets.
  • Utiliser SVN et Git simultanément sur les mêmes projets.

Une transition intégrale vers Git limitera la complexité de votre workflow de développement ; c'est donc l'option à privilégier. Cependant, elle n'est pas toujours viable dans des entreprises plus grandes qui comptent des dizaines d'équipes de développement travaillant sur des centaines de projets. En pareilles situations, une approche hybride est la solution la plus sûre.

Votre choix d'outil(s) de migration dépend largement de la stratégie que vous allez adopter. Vous trouverez une présentation de quelques-uns des outils de migration SVN-Git les plus courants ci-dessous.

Les scripts de migration Atlassian

Si vous êtes intéressé par une transition abrupte vers Git, les scripts de migration d'Atlassian constituent un outil de choix. Ces scripts vous fournissent tous les outils dont vous avez besoin pour convertir vos dépôts SVN en dépôts Git en toute fiabilité. Résultat : l'historique Git natif garantit que vous ne devrez pas résoudre de problèmes d'interopérabilité SVN/Git après la conversion.

Nous avons élaboré une procédure technique détaillée sur l'utilisation de ces scripts pour convertir l'intégralité de votre base de code en une série de dépôts Git. Cette procédure vous explique chaque étape, de l'extraction des informations de l'auteur dans SVN à la réorganisation de structures de dépôt SVN non standard.

Plug-in SVN Mirror pour Stash (désormais Bitbucket Server)

SVN Mirror for Stash est un plug-in Bitbucket Server qui vous permet de maintenir facilement une base de code hybride qui fonctionne aussi bien dans SVN que dans Git. Contrairement aux scripts de migration Atlassian, SVN Mirror for Stash vous permet d'utiliser Git et SVN simultanément sur un même projet, aussi longtemps que vous le souhaitez.

Cette solution intermédiaire est particulièrement appropriée pour les entreprises de plus grande taille. Elle permet une adoption incrémentielle de Git, puisque les différentes équipes peuvent migrer leur workflow à leur rythme.

Qu'est-ce que Git-SVN ?

L'outil git svn est une interface entre le dépôt Git local et un dépôt SVN distant. Git-svn permet aux développeurs d'écrire du code et de créer des commits en local avec Git, puis de les pusher vers un dépôt SVN centralisé. Le résultat sera alors similaire à celui de la commande svn commit. Cela devrait être temporaire, mais est utile pour débattre de la migration de SVN vers Git. 

git svn est une bonne solution si vous n'êtes pas certain de migrer vers Git et que vous souhaitez que certains de vos développeurs explorent les commandes Git sans s'engager dans une migration complète. Cet outil est également idéal pour la phase de formation : plutôt que de devoir gérer une transition brutale, votre équipe peut s'y habituer en utilisant les commandes Git locales avant de se préoccuper des workflows de collaboration.

Remarque : git svn ne doit intervenir que temporairement dans votre processus de migration. Comme cette commande dépend toujours de SVN, elle ne permet pas d'exploiter les fonctionnalités plus puissantes de Git, comme le branching ou les workflows de collaboration avancés.

Les stratégies de déploiement

La migration de votre base de code ne constitue qu'un aspect de l'adoption de Git. Vous devez également déterminer la manière dont vous allez présenter Git aux personnes qui travaillent sur cette base de code. Trois grandes stratégies s'offrent à vous pour assurer la migration de votre équipe de développement vers Git : faire appel à des consultants externes, à des champions Git internes ou à des équipes pilotes.

Les consultants Git externes

Les consultants Git peuvent mettre en œuvre votre processus de migration pour une somme modique. L'avantage : vous obtenez un workflow Git parfaitement adapté à votre équipe sans devoir consacrer du temps à sa mise en place. De plus, des ressources de formation professionnelles sont à votre disposition pendant que votre équipe apprend à utiliser Git. Les Experts Atlassian sont de véritables pros de la migration de SVN vers Git. Si vous recherchez un consultant Git, vous êtes à la bonne adresse.

D'un autre côté, en concevant et en implémentant un workflow Git par elle-même, votre équipe pourra comprendra les rouages internes de son nouveau processus de développement. Elle ne sera donc pas totalement perdue dès que votre consultant aura terminé sa mission.

Les champions Git internes

Un champion Git est un développeur employé par une entreprise qui a envie d'utiliser Git. Faire appel à un champion Git est une bonne solution pour les entreprises dotées d'une culture axée sur le développement avec des programmeurs enthousiastes et suffisamment à l'aise pour se lancer dans l'aventure en premier. L'idée ? Permettre à l'un de vos ingénieurs de devenir un expert Git. Il pourra alors concevoir un workflow Git adapté à votre entreprise et travailler comme consultant interne lorsque le reste de l'équipe migrera vers Git.

Par rapport à un consultant externe, l'avantage de cette solution est que vous conservez votre savoir-faire Git en interne. Former ce champion Git requiert cependant plus de temps ; de plus, vous courrez le risque de choisir le mauvais workflow Git ou de l’implémenter d'une manière inadéquate.

Les équipes pilotes

Troisième option de migration vers Git : le test sur une équipe pilote. Cette solution est idéale pour les petites équipes qui travaillent sur un projet relativement isolé. Pour un combo gagnant, vous pouvez aussi associer des consultants externes aux champions Git internes dans l'équipe pilote.

L'avantage de cette solution, c'est qu'elle nécessite l'engagement de toute votre équipe et qu'elle limite les risques de choisir le mauvais workflow. En effet, toute l'équipe participe à la conception de ce nouveau processus de développement. En d'autres termes, cette solution permet de rassembler les pièces du puzzle plus rapidement que si un consultant ou un champion concevait le nouveau workflow tout seul.

D'un autre côté, mobiliser une équipe pilote allonge la durée de formation et de configuration initiale : plutôt que d'avoir un développeur qui détermine un nouveau workflow, une équipe entière pourrait perdre temporairement en productivité pendant qu'elle s'adapte à son nouveau workflow. Cependant, cet inconvénient de courte durée en vaut vraiment la chandelle à long terme.

Sécurité et autorisations

Le contrôle des accès est un aspect de Git qui vous amène à repenser entièrement la manière dont vous gérez votre base de code.

Dans SVN, vous écrivez généralement toute votre base de code dans un seul dépôt centralisé. Vous limitez ensuite l'accès aux différentes équipes ou personnes par dossier. Dans Git, c'est impossible : les développeurs doivent extraire tout le dépôt pour travailler dessus. Généralement, vous ne pouvez pas extraire un sous-ensemble du dépôt comme avec SVN. Les autorisations peuvent uniquement être accordées à des dépôts Git entiers.

Cela signifie que vous devez diviser votre dépôt SVN monolithique en plusieurs petits dépôts Git. Chez Atlassian, nous en avons nous-mêmes fait l'expérience lorsque notre équipe de développement Jira a migré vers Git. Jusqu'à présent, tous nos plug-ins Jira étaient stockés dans un seul dépôt SVN. Après la migration, chaque plug-in s'est retrouvé dans son propre dépôt.

Gardez à l'esprit que Git a été conçu pour intégrer de manière sécurisée les contributions de milliers de développeurs Linux indépendants : il va sans dire que vous pourrez donc configurer le type de contrôle des accès dont votre équipe a besoin. Toutefois, il vous faudra sans doute revoir votre cycle de build.

Si vous tenez à conserver des dépendances entre vos nouveaux dépôts Git, une couche de gestion des dépendances en plus de Git pourrait vous être utile. Cette couche sera bénéfique pour vos builds : en effet, au fur et à mesure qu'un projet évoluera, vous devrez effectuer des mises en cache pour accélérer vos temps de build. Vous trouverez une liste de suggestions d'outils de gestion des dépendances pour toutes les piles technologiques dans cet article très utile : « Git et dépendances de projet ».

For developers

Un dépôt pour chaque développeur

En tant que développeurs, le principal changement auquel vous devrez vous adapter est la nature décentralisée de Git. Au lieu d'un seul dépôt centralisé, chaque développeur dispose de sa propre copie de tout le dépôt. Cela change considérablement la façon dont vous collaborez avec vos collègues programmeurs.

Plutôt que de faire un checkout d'un dépôt SVN à l'aide de svn checkout et d'obtenir une copie de travail, vous clonez tout le dépôt Git sur votre ordinateur local à l'aide de git clone.

La collaboration s'effectue en déplaçant des branches d'un dépôt à l'autre à l'aide des commandes git push, git fetch ou git pull. En règle générale, le partage a lieu au niveau des branches dans Git, mais il peut également s'effectuer au niveau des commits comme dans SVN. Cependant, dans Git, un commit représente l'état général du projet dans son ensemble, plutôt que des modifications de fichier. Comme vous pouvez utiliser des branches dans Git et dans SVN, la plus grande distinction à faire est qu'avec Git, vous pouvez commiter en local sans partager votre travail. Cela vous permet d'expérimenter plus librement, de travailler plus efficacement hors ligne et d'accélérer presque toutes les commandes liées au contrôle de version.

Cependant, il est important de comprendre qu'un dépôt distant n'est pas un lien direct vers le dépôt d'un autre utilisateur. Ce n'est rien de plus qu'un signet qui vous évite de saisir de nouveau toute l'URL à chaque interaction avec un dépôt distant. Jusqu'à ce que vous fassiez un pull ou un push d'une branche vers un dépôt distant, vous travaillez dans un environnement isolé.

L'autre grand changement pour les utilisateurs de SVN est la notion de dépôts « locaux » et « distants ». Les dépôts locaux se trouvent sur votre ordinateur local, et tous les autres dépôts sont appelés des dépôts distants. Le principal objectif d'un dépôt distant est de rendre votre code accessible au reste de l'équipe ; dès lors, aucun développement actif n'est effectué dans ces dépôts. Les dépôts locaux sont stockés sur votre ordinateur local ; vous y effectuez toutes vos tâches de développement.

N'ayez pas peur de créer des branches ou d'effectuer des merges

Dans SVN, vous commitez du code en modifiant des fichiers dans votre copie de travail, puis en exécutant svn commit pour transférer le code vers le dépôt centralisé. Vos collègues peuvent ensuite importer ces changements dans leur propre copie de travail avec svn update. Les branches SVN sont généralement réservées à des aspects importants et de longue durée, car les opérations de merge sont des procédures dangereuses qui pourraient scinder le projet.

Le workflow de développement de base de Git est très différent. Plutôt que d'être lié à une seule ligne de développement (p. ex., un trunk), tout tourne autour du branching et du merging.

Lorsque vous voulez travailler dans Git, vous créez une nouvelle branche et en effectuez un checkout avec git checkout -b <nom-branche>. Vous disposez ainsi d'une ligne de développement dédiée où vous pouvez écrire du code sans influer sur le travail de vos collègues. Si vous commettez une erreur irréparable, il vous suffit de supprimer la branche en exécutant git branch -d <nom-branche>. Si vous avez développé une fonctionnalité utile, vous remplissez une pull request afin de merger votre travail dans la branche master.

Les workflows Git potentiels

Au moment de choisir votre workflow Git, vous devez impérativement penser aux besoins de votre équipe. Un workflow simple peut maximiser votre vitesse de développement et votre flexibilité, tandis qu'un workflow plus complexe peut assurer une meilleure cohérence et un contrôle accru du travail en cours. Vous pouvez adapter et combiner les approches générales recensées ci-dessous en fonction de vos besoins et des différents rôles au sein de votre équipe. Par exemple, un développeur interne pourrait utiliser les branches de fonctionnalité, alors qu'un sous-traitant travaillerait à partir d'un fork.

  • Un workflow centralisé est la solution qui se rapproche le plus des processus SVN courants ; elle est donc idéale pour commencer.
  • Partant de ce principe, l'utilisation d'un workflow de branche de fonctionnalité permet aux développeurs d'isoler leurs tâches en cours et de protéger des branches partagées importantes. Les branches de fonctionnalité servent en outre de base à la gestion des changements via les pull requests.
  • Un workflow Gitflow est une version plus formelle et structurée de la création de branches de fonctionnalité. Ainsi, c'est la solution idéale pour les équipes de plus grande taille avec des cycles de livraison bien définis.
  • Enfin, pensez à mettre en place un workflow de duplication (fork) si vous avez besoin d'un maximum d'isolement et de contrôle des changements, ou si beaucoup de vos développeurs travaillent dans un même dépôt.

Mais si vous voulez vraiment tirer le meilleur parti de Git en tant qu'équipe professionnelle, nous ne pouvons que vous conseiller le workflow de branche par fonctionnalité. Il s'agit d'un workflow véritablement distribué et hautement sécurisé, incroyablement évolutif et agile par excellence.

Conclusion

Migrer votre équipe vers Git peut sembler fastidieux, mais il peut en être autrement. Dans cet article, nous vous avons présenté quelques options courantes pour migrer votre base de code existante, déployer Git au sein de vos équipes de développement, assurer la sécurité et gérer les autorisations. Nous vous avons également exposé les plus grands défis qui attendent vos développeurs pendant le processus de migration.

Nous espérons vous avoir fourni des bases solides pour présenter le développement distribué à votre entreprise, quelles que soient sa taille ou ses pratiques de développement actuelles.

Prêt à découvrir Git ?

Essayez ce tutoriel interactif.

Démarrez maintenant