Pourquoi devrais-je utiliser le contrôle de version? [fermé]

Je lisais un blog où l'écrivain a dit ceci

«Le code n'existe pas à moins qu'il ne soit archivé dans un système de contrôle de version. Utilisez le contrôle de version pour tout ce que vous faites. Tout contrôle de version, SVN, Git, même CVS, maîtrisez-le et utilisez-le.

Je n'ai jamais utilisé de contrôle de version et je ne le trouve pas génial. Je l'ai cherché sur Google et je l'ai déjà regardé, mais j'ai juste besoin de le mettre en termes d'enfants si vous voulez bien.

Si je comprends bien, des choses comme SVN servent à stocker votre code en ligne pour qu'un groupe d'utilisateurs ou d'autres développeurs aient accès au même code. Une fois que vous avez mis à jour du code, vous pouvez soumettre la nouvelle version et le SVN conservera des copies de l'ancien code ainsi que des nouveaux que vous mettez à jour.

Est-ce là l'idée de base ou est-ce que je me trompe complètement?

Si j'ai raison, cela ne sera peut-être pas très utile si je:

• Ne faites pas travailler le code par d’autres personnes.
• Ne prévoyez pas de laisser les autres avoir le code.

As-tu déjà:

• Vous avez modifié le code, réalisé que c'était une erreur et que vous vouliez revenir en arrière?
• Code perdu ou sauvegarde trop ancienne?
• Devait maintenir plusieurs versions d'un produit?
• Vous vouliez voir la différence entre deux (ou plus) versions de votre code?
• Vous vouliez prouver qu'un changement particulier a cassé ou corrigé un morceau de code?
• Vous voulez revoir l'historique de certains codes?
• Souhaitez-vous soumettre une modification au code de quelqu'un d'autre?
• Vous souhaitez partager votre code ou laisser d'autres personnes travailler sur votre code?
• Vous vouliez voir combien de travail est effectué, où, quand et par qui?
• Vous souhaitez expérimenter une nouvelle fonctionnalité sans interférer avec le code de travail?

Dans ces cas, et sans doute dans d'autres, un système de contrôle de version devrait vous faciliter la vie.

Pour mal citer un ami: Un outil civilisé pour une époque civilisée.

Même si vous travaillez seul, vous pouvez bénéficier du contrôle de source. Entre autres, pour ces raisons:

• Vous ne perdez rien. Je n'ai plus jamais commenté le code. Je le supprime simplement. Cela n'encombre pas mon écran et il n'est pas perdu. Je peux le récupérer en vérifiant un ancien commit.

• Vous pouvez expérimenter à volonté. Si cela ne résout pas le problème, rétablissez-le.

• Vous pouvez consulter les versions précédentes du code pour savoir quand et où les bogues ont été introduits. git bisectest formidable à cet égard.

• Des fonctionnalités plus "avancées" comme le branchement et la fusion vous permettent d'avoir plusieurs lignes de développement parallèles. Vous pouvez travailler dans deux fonctions simultanées sans interférence et basculer sans tracas.

• Vous pouvez voir "ce qui a changé". Cela peut sembler basique, mais c'est quelque chose que je vérifie beaucoup. Je commence très souvent mon workflow individuel par: qu'ai-je fait hier?

Allez-y et essayez-le. Commencez lentement avec les fonctionnalités de base et apprenez les autres au fur et à mesure. Vous constaterez bientôt que vous ne voudrez plus jamais revenir à «l'âge sombre» de l'absence de VCS.

Si vous voulez un VCS local, vous pouvez configurer votre propre serveur de subversion (ce que j'ai fait dans le passé), mais aujourd'hui, je recommanderais d'utiliser git. Beaucoup plus simple. Simplement cddans votre répertoire de code et exécutez:

git init

Bienvenue au club.

Le contrôle de version est un outil rare que je dirais absolument nécessaire, même si vous ne l'utilisez qu'en tant que développeur solo. Certaines personnes disent que c'est un outil par lequel on vit et on meurt, je suis d'accord avec cette affirmation.

Vous utilisez probablement le contrôle de version en ce moment même si vous ne le savez pas. Avez-vous des dossiers qui disent "XXX Php Code (décembre)" ou "XXX.php.bak.2"? Ce sont déjà des formes de contrôle de version. Un bon système de contrôle de version s'en chargera automatiquement pour vous. Vous serez en mesure de revenir à n'importe quel moment (où vous avez des données archivées) et de voir une copie exacte de ces données.

De plus, si vous adoptez un système comme subversion, et utilisez un référentiel distant (tel qu'un sur un serveur que vous possédez), vous aurez un endroit pour conserver tout votre code. Besoin d'une copie de votre code ailleurs? Pas de problème, vérifiez-le. Crash du disque dur à la maison? Pas de problème (au moins avec votre code source).

Même si vous n'utilisez pas le contrôle de version maintenant, vous l'utiliserez probablement à un moment donné plus tard dans votre carrière et vous pourriez bénéficier de devenir plus à l'aise avec les principes maintenant.

Même en travaillant seul, cela est-il déjà arrivé? Vous exécutez votre application, et quelque chose ne fonctionne pas et vous dites "cela a fonctionné hier, et je jure que je n'ai pas touché à cette classe / méthode." Si vous enregistrez régulièrement du code, une comparaison rapide de la version montre exactement ce qui a changé au cours du dernier jour.

Voici un scénario qui peut illustrer l'utilité du contrôle de code source même si vous travaillez seul.

Votre client vous demande de mettre en œuvre une modification ambitieuse du site. Cela vous prendra quelques semaines et impliquera des modifications sur de nombreuses pages. Vous vous mettez au travail.

Vous avez terminé à 50% cette tâche lorsque le client vous appelle et vous dit de laisser tomber ce que vous faites pour apporter une modification urgente mais plus mineure au site. Vous n'avez pas terminé la tâche plus importante, elle n'est donc pas prête à être mise en ligne et le client ne peut pas attendre le plus petit changement. Mais il souhaite également que le changement mineur soit fusionné dans votre travail pour le changement plus important.

Peut-être que vous travaillez sur la grande tâche dans un dossier séparé contenant une copie du site Web. Vous devez maintenant déterminer comment effectuer le changement mineur d'une manière qui puisse être déployée rapidement. Vous travaillez furieusement et faites-le. Le client rappelle avec d'autres demandes de raffinement. Vous faites cela aussi et déployez-le. Tout est bien.

Maintenant, vous devez le fusionner dans le travail en cours pour le changement majeur. Qu'avez-vous changé pour le travail urgent? Vous travailliez trop vite pour prendre des notes. Et vous ne pouvez pas simplement comparer facilement les deux répertoires maintenant que les deux ont des changements par rapport à la ligne de base à partir de laquelle vous avez commencé.

Le scénario ci-dessus montre que le contrôle de code source peut être un excellent outil, même si vous travaillez en solo.

• Vous pouvez utiliser des branches pour travailler sur des tâches à plus long terme, puis fusionner la branche dans la ligne principale une fois l'opération terminée.
• Vous pouvez comparer des ensembles entiers de fichiers à d'autres branches ou à des révisions antérieures pour voir ce qui est différent.
• Vous pouvez suivre le travail au fil du temps (ce qui est idéal pour les rapports et la facturation d'ailleurs).
• Vous pouvez récupérer n'importe quelle révision de n'importe quel fichier en fonction de la date ou d'un jalon que vous avez défini.

Pour le travail en solo, Subversion ou Git est recommandé. Tout le monde est libre de préférer l'un ou l'autre, mais l'un ou l'autre est clairement préférable à ne pas utiliser de contrôle de version. Les bons livres sont " Pragmatic Version Control using Subversion, 2nd Edition " de Mike Mason ou " Pragmatic Version Control Using Git " de Travis Swicegood.

Auteur original: Bill Karwin

Même en tant que contrôle de source unique de développeur, il offre un grand avantage. Il vous permet de stocker l'historique de votre code et de revenir à tout moment aux versions précédentes de votre logiciel. Cela vous permet une flexibilité sans peur pour expérimenter, car vous pouvez toujours restaurer une autre version de votre code source qui fonctionnait.

C'est comme avoir un bouton géant "Annuler" jusqu'à votre première ligne de code.

Le contrôle de version est presque impossible à vivre sans après avoir commencé à l'utiliser. C'est indispensable si plus d'un développeur travaille sur la même base de code ... mais c'est aussi assez utile pour un seul développeur.

Il suit les modifications de votre code et vous permet de revenir aux versions précédentes. Cela vous permet d'expérimenter en sachant que si quelque chose se brise, vous pouvez annuler vos modifications.

Vous gagnez en sécurité (dans le sens d'une sauvegarde de votre code) et en versioning de votre code (en supposant que vous preniez l'habitude de valider vos modifications souvent). Les deux sont de très bonnes choses même si personne d'autre ne finit par travailler sur le code avec vous ...

Le contrôle de version est idéal pour vérifier les versions précédentes, même si vous travaillez seul. Par exemple, si vous supprimez accidentellement du code ou un fichier, vous pouvez le récupérer; ou vous pouvez comparer les versions précédentes pour voir pourquoi un nouveau bogue est apparu. C'est également bien si vous êtes une seule personne travaillant à plusieurs endroits.

Mon préféré est git.

Il existe un certain nombre de raisons d'utiliser le contrôle de version, même si vous êtes la seule personne à toucher le code.

• Sauvegarde - et si votre disque dur tombe en panne? Avez-vous une copie n'importe où?
• Historique des révisions - Conservez-vous actuellement des copies de code dans différents dossiers? Le contrôle de version vous permet de suivre vos modifications au fil du temps et de comparer facilement différentes révisions, de fusionner, d'annuler les modifications, etc. à l'aide d'outils.
• Branches - la possibilité de tester certaines modifications, de toujours suivre ce que vous faites, puis de décider si vous voulez ou non les conserver et les fusionner dans le projet principal ou simplement les jeter.

Si vous conservez votre code sous contrôle de version, il est alors très facile de voir quels fichiers vous avez modifiés (ou avez oublié d'ajouter à la ligne de base).

Quelque chose que personne d'autre ne semble avoir explicitement mentionné est le marquage ou l'étiquetage des versions. Si vous avez un client utilisant la version 1 de votre logiciel et que vous êtes occupé à travailler sur la version 2, que faites-vous lorsque le client signale un bogue et que vous devez construire la version 1.1?

Un système de contrôle de source vous permettra d'étiqueter chaque version que vous faites afin que vous puissiez y revenir plus tard, faire le correctif (et fusionner ce correctif dans le nouveau code de la version 2) et créer une nouvelle version sans craindre que vous ne livriez accidentellement quelque chose qui n'est pas prêt.

Le contrôle de code source est un élément central du développement logiciel moderne. Si vous ne l'utilisez pas (même pour des projets personnels, car plus vous avez d'expérience, mieux c'est), vous faites quelque chose de mal.

Habituellement, l'une des premières questions que je pose lorsque je suis interviewé pour un emploi est "Qu'est-ce que vous utilisez pour le contrôle de source?" Jusqu'à présent, un seul endroit a dit "Rien", mais ils prévoyaient de corriger le problème "Vraiment bientôt maintenant ..."

Le fait que d'autres développeurs participent ou non est totalement orthogonal au besoin d'un système de contrôle de version.

Vous pouvez être le seul développeur mais bénéficierez toujours de:

• un historique de tous vos changements
• capacité à revenir en arrière sur cette histoire
• possibilité d'expérimenter avec la source et tout en ayant une version fonctionnelle (branchement)
• une copie de sauvegarde (surtout si vous utilisez une machine différente comme serveur de contrôle de source, et encore plus si cette machine est régulièrement sauvegardée)

Maintenant, si vous avez un groupe qui développe sur la même base de code, le contrôle de version est encore plus nécessaire alors

• les gens peuvent éditer le même fichier en même temps (selon le système particulier, mais la plupart des personnes sensées vous permettent de le faire)
• vous pouvez dire qui a fait quoi au code quand

Lorsqu'il y a plus de personnes impliquées, l'outil de contrôle de version que vous choisissez est plus pertinent, en fonction du style de développement.

Il s'agit également de sauvegarder un ancien fichier, raison pour laquelle il s'appelle "Subversion". Vous pouvez ainsi gérer plusieurs versions de votre travail dans lesquelles vous pouvez revenir (revenir en arrière) et gérer les différentes implémentations de celui-ci (branchement).

Vous constaterez peut-être que vous disposiez d'une version fonctionnelle de votre programme.

Vous décidez d'ajouter quelques nouvelles fonctionnalités sur une période de temps et vous la publiez.

Vous commencez à recevoir des rapports de bogues affectant du code que vous pensiez ne pas avoir touché.

En utilisant SVN, par exemple, vous pouvez revenir à une version plus ancienne et vérifier si le nouveau bogue existe. Une fois que vous avez trouvé une version qui a introduit le bogue, il sera plus facile de le corriger car vous pouvez comparer la version qui a fonctionné à ce qui n'a pas fonctionné et voir ce qui a changé, puis cela affinera la recherche.

Le contrôle de code source a de nombreuses utilisations, même si vous êtes le seul développeur.

On dirait que vous cherchez quelque chose d'un peu plus léger. Découvrez Mercurial ( livre de référence génial ). Je l'utilise pour tout, du code source à la correspondance personnelle.

Quelques avantages:

• Bouton d'annulation géant, afin que vous puissiez retourner les jours de halcyon de la semaine dernière lorsque le code a réellement été exécuté
• Code à jeter. Vous ne savez pas si c'est la meilleure façon de faire quelque chose? Faites une branche et expérimentez. Personne d'autre que vous ne doit le savoir si vous utilisez un DVCS comme Mercurial.
• Développement synchronisé. Je développe sur 4 ordinateurs différents. Je pousse et tire entre eux pour garder le courant, donc peu importe celui où je suis, j'ai les dernières versions.

Même si vous n'avez pas encore été dans une situation où vous aviez besoin d'une ancienne version de votre programme, avoir un contrôle de code source vous donne une plus grande confiance pour apporter des changements majeurs.

Je me suis retrouvé à faire un refactoring plus agressif après avoir utilisé le contrôle de code source parce que j'ai toujours su qu'une version fonctionnelle pouvait être facilement restaurée.

Je n'ai également commencé que récemment à m'intéresser au contrôle de version. Dans les systèmes de contrôle de version, vous avez le concept d'un référentiel pour votre code. Une multitude de nouvelles commandes shell sont apprises très rapidement afin que vous puissiez interagir avec ce référentiel.

Une fois que vous avez enregistré votre code dans un fichier, vous pouvez le valider dans le référentiel de votre projet. Au fur et à mesure que vous développez votre code et que vous validez vos modifications, le référentiel développe une série de révisions . Vous pouvez accéder à n'importe lequel de ceux-ci en extrayant une révision. Si vous travaillez seul, il est peu probable que vous fassiez beaucoup de vérification à moins que vous ne perdiez vos fichiers de code ou que vous souhaitiez travailler sur une autre machine. Dans ces cas, vous vérifierez généralement la dernière révision de tous les fichiers.

Pour ma part, je ne garde plus les fichiers ou dossiers nommés «project_old» lorsque je décide de refactoriser quelque chose. Toutes les modifications que j'apporte sont stockées de manière incrémentielle et je pourrai toujours revenir en arrière vers un projet qui a fonctionné dans son ensemble. J'utilise rarement FTP pour déployer maintenant parce que je viens de vérifier mon code via ssh. Seuls les fichiers que j'ai modifiés sont téléchargés et si j'ai besoin de recharger sur le serveur le terminal est déjà là.

J'ai trouvé ce discours sur GIT vraiment instructif; http://www.youtube.com/watch?v=4XpnKHJAok8

C'est une discussion Google où Linus Torvalds fait valoir l'utilisation d'un système de contrôle de version plutôt qu'un autre. Ce faisant, il explique comment ils fonctionnent à l'aide de concepts et compare ensuite différentes manières de les mettre en œuvre.

Vous voudrez probablement quelque chose comme la subversion même si vous travaillez seul pour avoir un historique de tous vos changements. Vous voudrez peut-être voir à quoi ressemblait un morceau de code une fois pour vous rappeler pourquoi vous avez effectué une modification.

Le contrôle de la source est également utile lorsque vous vous enregistrez souvent. Si vous vous enregistrez souvent, vous serez toujours en mesure de revenir souvent en arrière. Plusieurs fois, vous pouvez commencer à emprunter une voie pour résoudre un problème et ensuite réaliser que ce n'était pas la bonne voie à suivre. Plusieurs fois, vous pourriez simplement continuer à aboyer sur le mauvais chemin et finir par construire une solution terrible - uniquement parce que vous ne vouliez pas perdre tout votre travail. En vous enregistrant souvent, le dernier point de "bonheur" n'est pas loin, donc même si vous vous trompez de chemin, vous pouvez toujours revenir en arrière et essayer à nouveau et faire une solution plus élégante et simple. Ce qui est toujours une bonne chose pour que vous puissiez comprendre et conserver ce que vous avez écrit à l'avenir.

Cela dépend de la taille du projet et de la fréquence à laquelle vous changez d'avis sur certaines parties de celui-ci. Pour les petits projets où vous faites juste quelque chose de manière linéaire, le contrôle de version ne sera probablement pas d'une grande aide (bien que si vous supprimez ou corrompez accidentellement un fichier sans contrôle de version, vous pleurerez).

Mais il y a quelques semaines, j'ai rencontré un ami qui écrivait seul un énorme projet de passe-temps. Il avait dix ou vingt copies de son code, avec des suffixes comme "X1", "X2", "test", "plus rapide" et ainsi de suite.

Si vous avez fait plus de deux copies de votre code, vous avez besoin d'un contrôle de version . Un bon système de contrôle de version vous permet d'annuler une modification que vous avez faite il y a quelque temps sans annuler ce que vous avez fait après cette modification. Il vous permet de voir quand certaines modifications ont été apportées. Il vous permet de diviser votre code en deux «chemins» (par exemple, l'un pour tester une nouvelle idée, l'autre pour garder votre code «éprouvé et fiable» en sécurité jusqu'à ce que vous ayez terminé le test) et les fusionner ensuite.

Nous sommes en 2019. Je rencontre des objections, à cette date relativement tardive, à l'utilisation de Git; objections que j'en vois soulever ici. Cette discussion a grandement clarifié l'impératif d'utiliser le contrôle de source plutôt que de simplement faire des copies de sauvegarde nommées. Un point clé est l'utilisation du contrôle de code source même lorsque nous avons des projets de développeur unique. Personne n'est parfait. Vous faites des erreurs. Si vous êtes exceptionnellement bon et intelligent, vous allez développer des applications plus complexes; mais vous allez toujours faire des erreurs et cela règle le problème. Décidément oh Pete! Je n'utilise jamais Linux mais je pense que nous respectons tous la grande intelligence technique de Linus Torvalds. Il a reconnu l'importance du contrôle des sources et il a apporté des contributions clés à la création de Git. C'est un résumé pour toutes les raisons données ici. Torvalds comprend: le contrôle des sources est très important: utiliser le contrôle de source. Merci à tous ceux qui ont commenté ce sujet de longue date.