Mon Voyage de SVN à Git

Présentation réalisée lors du LUGE 2020.2 le 22/10/2020 :

Après avoir utilisé SVN (avec succès) sur des développements LabVIEW en équipe pendant plus de 10 ans, j’ai voulu migrer vers Git en 2018.

Cette présentation relate ce périple. Vous y trouverez mon retour d’expérience et mes conseils si vous aussi vous voulez vous lancer dans l’aventure.

Vidéo


Slides

Ouvrir les slides de la présentation en plein écran

3 réactions sur “ Mon Voyage de SVN à Git ”

  1. Nicolas Réponse

    Bonjour Olivier, je viens de regarder ta présentation et à un moment tu dis : “On ne merge jamais le contenu d’un fichier (même les fichiers XML)”

    Est-ce que tu as déjà eu des problèmes avec cela ? Tu y voies là un risque de dupliquer une ligne (ex : référence vers un VI) et de corrompre le fichier projet ? C’est quelque chose que je fais personnellement (ex : pour les numéro de version des EXE qui sont ainsi intégrés à mon outil de SCC) mais je jette un coup d’œil avant de merger quand même.

  2. Nicolas Réponse

    Une autre question : est-ce que tu utilises Git Flow en bonne et due forme sur tous tes projets ? J’ai essayé sur un de mes projets où j’ai une dizaine de logiciels (et donc de repositories différents) et je trouve ça un peu lourd … notamment à cause des plusieurs repositories Git.

    J’ai donc fini par faire un GitFlow mais “à ma sauce” un peu plus léger sur certains points.

  3. Olivier Jourdan Auteur ArticleRéponse

    Bonjour Nicolas,
    Pour ta première question, c’est exactement ça. Même si la plupart du temps cela ne va pas jusqu’à la corruption du lvproj… Une bonne pratique est d’avoir une architecture basée sur des classes ou des lib et de confier l’intégration de ces dernières dans le projet à une seule personne. Une fois qu’elles sont dans le projet, tu ne devrais avoir, la plupart du temps, qu’une seule personne qui modifie une lvlib/lvclass à la fois et cela n’impacte pas le lvproj.
    Pour ce qui est de Git Flow, je l’utilise dans quasiment tous mes projets, mais ça ne doit pas être un dogme. Git est très “souple”, il peut s’adapter à quasiment tous les contextes. À toi de définir ce qui est le plus approprié.

    PS jette un oeil au billet de blog du créateur de Git Flow lui-même pour te voir que Git Flow ne doit pas être considéré comme dogme ou une panacée (lire la note du 5/3/2020 en intro) –> https://nvie.com/posts/a-successful-git-branching-model/

Répondre à Nicolas Annuler la réponse

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *