Le contrôle de version est-il nécessaire pour un petit groupe de développement (1-2 programmeurs)?

J’essaie de débattre du fait que le contrôle de version est important pour un ou deux développeurs.

Plus spécifiquement, je travaille dans un département où il y a généralement deux développeurs PHP, utilisant un framework partagé. Il soutient qu’il n’ya pas de valeur ajoutée dans l’installation de Subversion sur notre système de développement, alors que j’affirme qu’il est agréable de pouvoir revenir en arrière pour voir le code précédent, en particulier lorsque des erreurs inexplicables sont difficiles à identifier. point dans certaines des classes.

Je pense que Subversion offre le moyen le plus simple de créer et de suivre les modifications, pour diverses raisons, y compris le débogage. Est-ce que Subversion économiserait du temps?

Je vais juste emstackr ici et dire OUI. Comme @ 17 sur 26 a dit

Ne pas avoir de contrôle de source est une pure folie.

C’est la vérité. J’ai fait de petits projets avec et sans contrôle de source (pas mon choix). Sans ça, ça craint. Il n’y a pas de version canonique du projet, on ne sait jamais qui a quoi et fusionner les changements est un exercice douloureux.

En réalité, quelque chose sur environ 5 lignes de code devrait être sous le contrôle de la version.

Vous voulez toujours, toujours, avoir une sorte de contrôle de source même si vous travaillez sur un projet par vous-même.

Un historique des changements est essentiel pour pouvoir voir l’état d’un code à tout moment. Il y a une variété de raisons de revenir dans un historique de projet allant de la simple possibilité de restaurer un mauvais changement à la prise en charge d’une ancienne version lorsque le client veut simplement réparer un bogue plutôt que de mettre à jour une version plus récente. les logiciels.

Ne pas avoir de contrôle de source est une pure folie.

Oui oui

Même si vous êtes un programmeur unique, vous avez besoin du contrôle de version. La simplicité avec laquelle vous pouvez comparer le code à un instantané est inestimable.

Mon conseil – vas-y!

[Une fois, je vivais sans contrôle de version. Maintenant je ne peux plus.]

Je suis programmeur ONE et je le trouve précieux, car je veux parfois revenir en arrière ou comparer quelque chose à une version antérieure.

De plus, je publie des documents d’utilisateurs et des choses comme ça.

C’est un excellent moyen de suivre votre développement.

Le contrôle de version sauvera votre cul. Un développeur professionnel qui n’utilise pas le contrôle de version est l’une des rares choses qui relèvent incontestablement de la catégorie des fautes de logiciel.

Même si vous êtes un développeur seul, il le fera

  • Laissez-vous revenir quand une fonctionnalité a fonctionné
  • Maintenir automatiquement une sauvegarde: archivez-la et sauvegardée.
  • Laissez-vous défaire vos modifications locales lorsque vous vous êtes attaché.
  • Revenons à la version en cours de production, à l’environnement de test ou à l’environnement d’un client particulier pour le débogage.
  • Si utilisé correctement, il vous permettra également de voir toutes les modifications liées à un correctif pour un problème particulier qui peut être un outil de débogage inestimable.

Si vous êtes plus d’un développeur, il empêchera un programmeur d’écraser les modifications apscopes à un autre programmeur, ce qui se produira, même si vous êtes prudent.

Ce ne sont que les bases qui devraient vous aider à gagner des arguments sur l’utilisation ou non du contrôle de version.

Subversion – absolument pas. Il est centralisé et la prise en charge de la fusion n’est pas si bonne.

Contrôle de version – absolument OUI! Même le développeur solo en a besoin!

Et les équipes mobiles petites et rapides ont besoin d’un contrôle de version dissortingbué, choisissez l’une des options suivantes:

  • git
  • mercuriel
  • darcs

Oui, il y a une courbe d’apprentissage. Aller dissortingbué, vous pouvez l’apprendre. Et oui, vous pouvez me remercier plus tard.

Et où vivent ces référentiels dissortingbués? Voici quelques idées:

  • dans votre clé USB personnelle (et ne vous limitez pas à une seule clé USB, dissortingbuez-les également à plusieurs endroits, comme un coffre-fort dans votre banque)
  • un autre en lieu sûr (hors site, autre endroit, autre côté du filet) où les incendies, les tremblements de terre ou les tornades ne peuvent pas nuire à votre source simultanément)
  • un serveur centralisé, le vôtre ou quelque chose comme github
  • copies multiples dans les machines de développement
  • repository intermédiaire quelque part près du serveur de stockage intermédiaire
  • repository de production quelque part près du site de production

Je suis un programmeur “one man band” et j’ai finalement commencé à utiliser le contrôle de version lorsque je me suis retrouvé à copier des applications entières et à les placer dans un dossier appelé “backup”, puis à les appeler “20080122-backup”. J’imagine que beaucoup de gens commencent comme ça. Donc, la question n’est pas de savoir si vous devez ou non utiliser le contrôle de version mais devriez-vous plutôt le faire de la bonne manière ou devriez-vous pirater ensemble un fac-similé à la maison?

Le contrôle de version n’est nécessaire que lorsque le nombre de programmeurs est> 0.

Utilisez le système qui fonctionne et avec lequel vous êtes à l’aise, mais si vous faites du développement, vous avez besoin du contrôle de version (idéalement configuré de telle sorte que la source soit sur au moins deux machines avant même de vous soucier des sauvegardes).

Au-delà de cela – recherchez un système qui vous permet de vous engager rapidement et de vous engager souvent.

Je suis presque, même si cela peut sembler étrange, de penser que chaque projet, même un développeur, devrait envisager une continuous integration, c’est-à-dire que ce système sera construit et testé à partir de zéro, chaque fois que des modifications seront effectuées. régulièrement. Pourquoi? Cela a) vous donne l’assurance que vous avez un système à construire dans VCS et b) vous assure que vous avez réellement des versions à tester et à déployer.

Je ne connais pas Subversion en particulier, mais je pense que chaque projet, même avec un seul développeur, devrait utiliser le contrôle de version. Je voudrais examiner quelques options (CVS, SubVersion, git, Bazaar, Visual SourceSafe) et voir lequel répond le mieux aux souhaits de votre équipe.

Le contrôle de version est l’outil le plus important dont dispose un programmeur, même plus important que les langages de programmation réels. Quel que soit le nombre d’utilisateurs, le contrôle des sources doit toujours être requirejs. Je ne sais pas combien de fois j’ai fait un changement radical et que je devais ensuite travailler sur l’ancien code ou au moins simplement voir comment fonctionnait le code d’origine. Je travaille en petites équipes et nous utilisons SVN Notifier pour nous faire savoir quand les choses sont commises. Cela nous permet de revoir le travail de chacun et vous n’obtenez pas le redoutable “Avez-vous déjà vérifié votre code?” des questions tout le temps. Utiliser le contrôle de la source dès le début élimine de nombreux maux de tête (écrasement, perte de code, bagarre pour savoir qui a changé quoi).

Absolument. Il n’y a vraiment pas d’autre moyen de faire face à des reculs dans un bon état lorsque le chemin de codage que vous vous êtes risqué à découvrir se révèle dense avec les loups.

Et vous pouvez le sauvegarder.

J’ai un projet sur lequel je travaille uniquement et le contrôle de version me facilite la vie. Par exemple, disons que je décide de mettre en œuvre une nouvelle fonctionnalité. Pour quelque raison que ce soit, je décide de le détruire – peut-être que je l’ai mal écrit, peut-être que j’ai changé d’avis sur sa mise en œuvre, peu importe. Tout ce que j’ai à faire est de revenir à une version précédente de SVN au lieu de restaurer manuellement chaque fichier concerné.

Subversion n’est pas. Mais le contrôle de source est.

Que vous soyez un développeur unique ou un groupe de développeurs, vous devez effectuer les opérations suivantes avant de commencer à coder:

  1. Configurez un système de contrôle de version . Utilisez n’importe quel système, git, SVN, Mercurial. Cela n’a pas d’importance tant que vous savez comment l’utiliser.
  2. Mettre en place un système de documentation collaboratif . Utilisez un wiki ou un trac ou tout autre système que vous savez utiliser.
  3. Configurez le système de construction . Utilisez Make, ANT, Maven ou tout autre système de construction que vous savez construire.
  4. Écrivez les premiers cas de test .

Ne codez pas une seule ligne de l’application principale tant que vous n’avez pas fait ces quatre

Quiconque ne fait pas de contrôle de version le fait tout simplement mal.

Le contrôle de version peut présenter les avantages suivants:

  1. Le retour en arrière est toujours utile comme vous l’avez mentionné
  2. Avec certains, vous pouvez épingler une version précédente et en sortir sans reculer
  3. Empêche deux personnes de travailler sur une page en même temps, ce qui peut entraîner plusieurs problèmes

Mais encore une fois, il a aussi ses inconvénients si vous ne choisissez pas un bon

Je recommande fortement le contrôle du code source, quelle que soit la taille de l’équipe. J’ai eu trop de sessions de fin de soirée où j’ai cassé mon code et je n’avais pas le contrôle du code source pour aller aux anciennes versions de travail.

OUI!

Désolé pour avoir crié 🙂

Le contrôle de version n’est pas seulement utile pour restaurer des versions. Cela donnera beaucoup de sécurité contre le déploiement d’anciennes versions de fichiers ou le remplacement accidentel de versions plus récentes par des versions plus anciennes, etc.

Une chose à laquelle je ne fais que commencer à m’habituer, c’est la possibilité de créer et de fusionner différentes versions. Si vous avez une échéance à venir, mais que vous travaillez sur une nouvelle fonctionnalité qui n’est pas prête pour les heures de grande écoute, vous pouvez simplement créer une twig avant d’append cette fonctionnalité. Créez une version livrable sans cette fonctionnalité et fusionnez-les après la date limite sans problème.

Bien sûr, le contrôle de version est nécessaire même pour un projet avec un seul homme.

La possibilité de sauvegarder des contextes et pas seulement les modifications dans le code est la grande chose que le contrôle de code source fait, vous allez de ” fichier ceci et cela a changé dans la ligne blah ” à ” j’ai ajouté une nouvelle option à faire … ” de valeur.

Ne m’écoutez pas, mais il y a un excellent article que les rands ont écrit à ce sujet

Capturer le contexte

OUI, mais uniquement pour les équipes de développeurs dont la taille est> 0

Lorsque je ferme mon éditeur de texte / IDE / quoi que ce soit et que je reviens le lendemain pour me rendre compte que je veux réparer une erreur de la dernière génération, le contrôle de la source est là pour me code. Sans contrôle de source, je ne peux pas faire ces choses aussi librement.

Pour les équipes de taille> 1, vous avez une sauvegarde centralisée, vous avez la possibilité de défaire votre équipe, il est plus facile (possible) de travailler en répartition, ce qui est quand même supérieur à 1. .

Contrôle de version OUI, vous devez toujours effectuer le contrôle de version.

SVN non .. moi, j’utilise Git.

Quand je souhaite aller dans les magasins, je prends ma voiture pour transporter le magasinage. Il n’est pas nécessaire de mettre de l’essence dans ma voiture. Je pourrais choisir de pousser la voiture à la place, mais pourquoi le ferais-je?

De même avec le choix de ne pas utiliser le contrôle de version ….

Je plaiderais pour git , pour deux raisons principales

  1. sortingvial pour mettre en place repo. cd dans le répertoire, git init , et vous avez terminé
  2. enregistrement! L’utilisation d’un vcs de n’importe quel type rend facile / évident / simple l’enregistrement de vos modifications. Avoir un DVD en particulier permet de voir très rapidement et facilement quand, quoi et pourquoi on fait des changements. Comme un dvcs dispose de longues informations localement, il est rapide et facile de regarder , contrairement à svn sur les machines distantes.

[Ceci est apparemment vrai aussi pour Mercurial. Ils sont sûrs que ce n’est pas si facile pour la subversion.]

Tout le monde qui dit que le contrôle de la source pour 1-2 développeurs est un must est complètement, complètement correct. Fais nous confiance 🙂

Au collège, j’ai eu un professeur qui nous a fait utiliser le contrôle de la source. Nous avons tous donné des coups de pied et crié, car CVS semblait trop compliqué et semblait trop exagéré pour les projets étudiants. Finalement, nous sums tous venus et même pour des projets simples, je les mettrais tous sous contrôle. J’ai continué à le faire jusqu’à ce jour et je me suis sauvé de nombreuses heures de frustration.

Réponse simple OUI.

Ne pas répéter, mais on ne peut pas en dire assez. Vous DEVRIEZ AVOIR le contrôle de la source. Subversion est ridiculement facile et presque nul lorsqu’il est configuré. Cela ne devrait littéralement pas prendre plus de 5 à 20 minutes. Vous avez aussi d’autres choix, comme GIT. Alors, choisissez-en un et mettez votre source à la fin de la réponse. 🙂

Il y aura une perte de temps lors de la configuration du système et de l’installation des autres développeurs – en particulier s’ils ne sont pas familiarisés avec versioncontrol (ou subversion en particulier).

Mais les avantages de la possibilité de revenir à une version précédente (en état de fonctionnement) et la possibilité de faire facilement un diff des fichiers archivés en valent largement la peine.

Le plus gros problème est que les récompenses, comme la plupart des choses, surviennent après le «travail acharné». 🙂

Notez qu’une solution différente, mais plus légère, est peut-être de nommer «Shadow Copy» sur Windows, si c’est votre serveur (même si je suppose que ce ne sera pas le cas). Le plus de ceci est que vous ne dérangerez pas vos co-développeurs avec l’apprentissage de la subversion, mais vous pourrez revenir à une version plus ancienne si nécessaire …

Le contrôle de version doit être la première chose à laquelle vous pensez lors du démarrage d’un projet. Deuxièmement, les builds automatiques, le troisième est le test, le quasortingème intègre vos tests avec vos builds.

VSS c’est bien mais mucho dinero.

essayez mercurial (hg) au lieu de svn

Oui, si vous êtes un développeur professionnel, vous devez absolument utiliser le contrôle de version!