CPU ⬜ Carré Petit Utile

  • Programmes
  • Interviewes
  • Chroniques
  • Chercher
  • Suivez-nous !
  • Extrait de l'émission CPU release Ex0087 : Gestion de versions de source.

    Bonjour à toi, Enfant du Futur Immédiat, toi qui ne sait plus pourquoi tu as raturé ce sgouigouigoui la semaine dernière sur ton devoir de dessin.

    Le principe du travail en équipe est immuable : c'est toujours la faute d'un autre. C'lui qui a cassé toute la prod, c'est surement Donald, Angela ou Emmanuel. Seulement on se retrouve vite dans une situation de délation, et un licenciement pour faute grave sans preuve peut vite conduire aux prud'hommes. La gestion de version de code source en a apporté une solution socialement acceptable.

    Mais je vais un peu trop vite ! Il faut d'abord que je t'explique ce qu'est que la gestion de version de code source... ou plutôt comment faisait-on avant.

    D'habitude, quand on enregistre un fichier texte, donc un code source, on écrase toujours l'ancienne version. Alors quand on a un gros projet, on faisait régulièrement des copies du répertoire de travail avec la date de copie. Et parfois dedans, des fichiers étaient des copies précédentes d'autres fichiers avec en extension .backup, .fonctionnel, .corrigé, .backup2… Si on voulait retrouver le moment où une fonction n'a plus marché, et donc le code source qui était encore fonctionnel, c'était la misère.

    Autre problème, quand on était plusieurs à modifier des fichiers sur un même serveur, on se marchait souvent sur les pieds, ta sauvegarde écrasant la modification du collègue à l'étage en dessous.

    Bref, c'était l'HORREUR

    Et puis sont arrivés les premiers logiciels pour gérer les versions de code source. C'était dans les années 1970s et surtout en informatique industrielle. On commença à les voir disponibles pour PC à la fin des années 1990s.

    C'était une révolution, mais elle demandait des contraintes pour la cause !
    Au lieu de sauvegarder directement sa modification d'un coup assuré de touche F2, on devait prendre le temps d'écrire la raison des modifications. Et aussi de travailler avec un serveur central, un dépôt du code source, qui arbitre les fichiers du projets et comment chacun peut travailler dessus.
    Tu tires depuis le dépôt, t'édites ta modification, tu commites la raison de ta modification, et tu pousses vers le dépôt.

    [La suite de cette chronique est une adaptation d'un billet antérieur de l'auteur]

    Auteur : DaScritch
    Illustration : GIT Branch and tag model for Master, HotFixes & Releases, CC MiguelPDL

    Pièces jointes

    2 commentaires

    Ajouter un commentaire

    Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées.

    Haut de page