Git est très probablement la solution de SCM (Source Control Management) la plus répandue de nos jours. C’est assez simple à comprendre : il y a tous les outils, dont de nombreux en open-source, pour à peu près tout faire, et ce gratuitement (pour peu qu’on dispose des machines et des compétences nécessaires pour la mise en place).
La plupart des projets sur lesquels j’ai travaillé, et travaille encore, se basaient et se basent sur Git.
Et j’aime beaucoup Git. D’ailleurs je suis un de ces barbus qui utilisent essentiellement le terminal ou le Git bash pour travailler avec !
Mais, mais mais mais… pour avoir utilisé Perforce par le passé, il y a quelque chose qui me manquera encore et toujours avec Git.
Git est dit « décentralisé » : on travaille en local, et une fois satisfait.e des modifications, on les pousse vers le dépôt distant. Un dépôt local complet peut d’ailleurs permettre de reconstruire le dépôt distant si le serveur a été détruit. Et tant qu’on travaille avec des fichiers de texte, comme du code source ou des fichiers de configuration, ça fonctionne très bien. Et je glisse ça là : fetch + rebase > pull.
Perforce est dit « centralisé » : on travaille avec une architecture client-serveur plus classique, auprès du dépôt (bien sûr, il est possible de gérer des proxys pour se prémunir en cas de problème avec ce dernier). Ce qui change la vie avec un SCM centralisé, c’est qu’aussitôt des modifications faites en local, elles sont envoyées au serveur. Elles ne sont pas encore déployées en production, mais sont répliquées, ce qui veut dire que la machine local peut brûler : rien ne sera perdu. Et, même si les modifications ne sont pas en production, il est possible pour un.e collègue de les récupérer, en quelques instants, via le numéro de la « changelist » (qui est un peu l’équivalent du commit de Git chez Perforce).
Et voilà, c’est tout, c’est tout bête, mais c’est tellement sécurisant.
Et très pratique pour se partager des modifications au sein d’une équipe.
Sur Git, on peut bien sûr assurer nos arrières et partager des modifications en poussant nos modifications sur une branche de travail. Mais voilà, il faut les pousser. Et parfois, un accident peut arriver avant qu’on ne le fasse (on teste généralement un minimum son code avant de pousser, même sur une branche de travail temporaire).
En bonus, si l’on travaille avec des fichiers binaires, Perforce dispose d’un ensemble d’outil pour se faciliter la vie, notamment un système de verrou permettant d’empêcher d’autres personnes de venir modifier le fichier.