J'investis mon temps pour vous faire gagner le vôtre
Bonjour,
De plus en plus de sites sont synchronisés via un git sur le cloud comme github ou bitbucket.
Cela permet de mettre facilement en place un service d’intégration continue.
Pour utiliser git, on serait tenté d’utiliser son identifiant et le sauvegarder sur le serveur.
Il y a une meilleure solution : utiliser une clé ssh.
Vu que l’étape de mise en place est bien expliquée, je met juste le lien vers la page bitbucket.
Voila pour aujourd’hui.
Bonjour,
J’utilise des contrôleurs de versions depuis quelques années déjà.
Celui que je maîtrise le plus est bien entendu SVN, vu que je l’ai utilisé plus de 10 ans, et oui j’ai sauté dans le train Git en retard.
Il serais intéressant de discuter de la façon dont j’utilise le controleur de version.
Je vais commencer par dire ce que ce n’est pas fait pour : Sauvegarder ses données.
Il faut absolument mettre Git ou Svn sous une gestion de sauvegarde (appelé communément backup). Mettre son code source sous contrôle de version ne le sécurise pas. Même si c’est sur un site comme github ou bitbucket. Il faut faire une sauvegarde régulière sur au moins un environnement que vous maîtrisez (non, l’ordinateur portable n’est pas un environnement maîtrisé). Je devrais songer à faire un billet sur les sauvegardes.
La chose la plus importante pour moi, c’est la gestion des conflits. Il est loin, mais toujours présent dans mon esprit, le temps où travailler à 2 sur un même projet impliquait écrasement des changements d’autrui par mégarde. Les corrections mineures perdues d’une mise en production à une autre parce qu’on écrase tous les fichiers.
Le contrôle de version, est la pour dire « Attention, le fichier que tu veux écraser a été modifié, prend le temps de regarder ». Plus aucun changement n’est perdu de façon involontaire. On vérifie, on gère les changements des autres avec les notres et ça roule.
Le 2ème problème que le contrôleur de version corrige, c’est les copies pour chaque tâche. On commence une tâche, on ne la finit pas qu’il y en a une autre plus urgente. On copie le répertoire original, on commence la 2ème tâche, et une 3ème urgence, etc…
On se retrouve avec une dizaine de copies, et on ne sais plus laquelle est la plus à jour. Avec le contrôleur de version, on fais une branche par tâche et on garde trace des dates, des changements déjà effectués etc.
Pour ne pas se perdre, il faut garder une structure propre, c’est à dire supprimer les branches qui ne sont plus actives (après avoir fusionné son contenu dans la branche principale).
Certains pensent que c’est la chose la plus importante, pour moi, elle vient en 3ème position. Le code source versionné c’est un historique de son évolution. Soyons francs, personne ne visite le code pour en connaître le cheminement.
Là où cette fonctionnalité devient utile, c’est lorsqu’on a l’impression qu’un bug réapparaît alors qu’on est sûr de l’avoir corrigé.
On regarde la dernière version qui ne contient pas le bug et on regarde comment la correction à été écrasée. On récupère le patch et on l’applique à la version courante.
Une utilisation intéressante du contrôleur de version est pour les bases de connaissance.
J’ai un fichier qui s’appelle symfony.txt, il contient tout ce que je sais sur symfony : Installation, cheat sheet, problèmes principaux, etc.
Pour gérer les différentes versions de symfony, je pourrais faire des paragraphes dans le même fichier. Le problème c’est qu’il ne fera que se rallonger et il y aura beaucoup de duplication.
Une autre solution, serait d’avoir un fichier par version de symfony. Le problème des fichiers à rallonge est réglé, mais je vais surpeupler mon répertoire, en plus, il faudra modifier tous les fichiers si un problème touche plusieurs versions.
La solution que j’utilise c’est avec le contrôleur de version. Je met un tag par version principale du fichier. Je remonte dans la bonne version grâce aux tags. Je n’ai qu’un fichier, et aucune redondance. Quand une nouvelle version de symfony sort, je met un tag.
La difficulté viens si j’ai une correction sur une version qui n’est pas la dernière. Je vais sur la version concernée. J’applique les changements et je les propage sur toutes les versions ultérieures. Si la solution n’est plus pertinente sur une autre version, j’y vais et corrige et repropage.
Ainsi j’ai une base de connaissances qui est simple à utiliser.
Bien sur, un outil dédié aux bases de connaissances serait plus adapté, mais j’utilise cette méthode et elle fonctionne bien. Laissez un commentaire si vous avez des suggestions.
Même quand on travaille seul, il est indispensable d’utiliser un contrôleur de version. Sur mon ordinateur, j’ai un serveur svn qui gère la plupart de mes travaux. Les plus récents sont sous git.
Si vous utilisez de façon intéressante les contrôleurs de versioin, n’hésitez pas à commenter.