Premiers pas avec le contrôle de version
https://stackoverflow.com/questions/2658
-
08-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Je dois implémenter un contrôle de version, même pour le développement que je fais à la maison.J'ai lu à quel point Subversion était génial ces dernières années et j'étais sur le point de me consacrer à l'apprentissage de cela en parallèle jusqu'à ce que j'entende parler de Git comme étant le système de contrôle de version en devenir.
Compte tenu de la situation, dois-je attendre et voir lequel arrive en tête ?Quels sont leurs avantages relatifs ?
Un problème que j'ai remarqué avec Git est qu'il n'y a pas beaucoup d'interfaces graphiques complètes, ce qui est important pour de nombreux utilisateurs de mon équipe.
De plus, cela ne me dérangerait pas de suggestions sur la façon de démarrer avec l'un ou l'autre.(tutoriels, etc.)
La solution
La chose la plus importante concernant le contrôle de version est :
COMMENCEZ JUSTE À L'UTILISER
Ne pas utiliser le contrôle de version est une horrible idée.Si vous n'utilisez pas le contrôle de version, arrêtez de lire maintenant et commencez à l'utiliser.
Il est très facile de convertir à partir de
cvs<->svn<->git<->hg
Peu importe celui que vous choisissez.Choisissez simplement le plus simple à utiliser et commencez à enregistrer l’historique de votre code.Vous pouvez toujours migrer vers un autre (D)VCS ultérieurement.
Si vous recherchez une interface graphique facile à utiliser, consultez TortueSVN (Windows) et Versions (Mac) (Suggéré par codage sans commentaires)
Modifier:
Git possède quelques fonctionnalités intéressantes, mais vous ne pourrez les apprécier que si vous avez déjà utilisé quelque chose de plus standard comme CVS ou Subversion.
Ce.Utiliser git est inutile si vous ne savez pas ce que le contrôle de version peut faire pour vous.
Modifier 2 :
Je viens de voir ce lien sur Reddit : Aide-mémoire Subversion.Bonne référence rapide pour la ligne de commande svn.
Autres conseils
Utilisez Subversion, il est facile à configurer, facile à utiliser et dispose de nombreux outils.Tout système de révision futur aura une fonctionnalité d'importation à partir de SVN, ce n'est donc pas comme si vous ne pouviez pas modifier ultérieurement si vos besoins augmentent.
Le Livre de subversion est votre meilleur pari pour apprendre l’outil.Il existe peut-être d'autres didacticiels de démarrage rapide, mais le livre est la meilleure référence que vous puissiez trouver.
Git possède quelques fonctionnalités intéressantes, mais vous ne pourrez les apprécier que si vous avez déjà utilisé quelque chose de plus standard comme CVS ou Subversion.Je serais certainement d'accord avec les affiches précédentes et commencerais par Subversion.
Si vous êtes nouveau dans le contrôle de version, lisez ceci :
HOWTO sur le contrôle de source
Optez pour SVN.Si vous n'avez jamais utilisé le contrôle de source auparavant, cela n'aura pas d'importance pour vous dans un sens ou dans l'autre.
De plus, l’utilisation d’un système de contrôle de code source ne nécessite pas beaucoup d’apprentissage.Si vous en apprenez un, vous pourrez facilement passer à un autre plus tard.
SVN est un excellent outil et il devrait répondre à la plupart de vos besoins.Et depuis qu'il existe, il dispose d'un bon nombre d'outils GUI (TortoiseSVN, par exemple).
Optez pour SVN.
Pour une explication conviviale de la plupart des concepts de base, voir Un guide visuel du contrôle de version.L'article est très convivial pour SVN.
J'ai utilisé RCS, CVS, SCCS, SourceSafe, Vault, Perforce, Subversion et git.
J'ai évalué BitKeeper, Dimensions, arch, bazaar, svk, ClearCase, PVCS et Synergy.
Si je devais créer un nouveau référentiel aujourd'hui, je choisirais git.Les doigts dans le nez.
C'est gratuit, rapide et en développement actif.
Et vous pouvez l'utiliser comme client de n'importe quel référentiel Subversion en utilisant git-svn.
Ça déchire.
@superjoe30
Qu'en est-il de l'utilisation du contrôle de code source sur votre propre ordinateur, si vous êtes le seul programmeur ?Est-ce une bonne pratique ?Existe-t-il des trucs ou astuces connexes ?
Je trouve que git est en fait plus facile pour cela car vous n'avez pas besoin d'un serveur ni de vous soucier de la saisie des URL, etc.Vos éléments de contrôle de version résident simplement dans le .git répertoire à l’intérieur de votre projet et vous n’avez qu’à l’utiliser.
Introduction de 5 secondes (en supposant que vous l'ayez installé)
cd myproject
git init
git add * # add all the files
git commit
La prochaine fois tu feras des changements
git add newfile1 newfile2 # if you've made any new files since last time
git commit -a
Tant que vous faites cela, Git vous soutient.Si vous vous trompez, votre code est en sécurité dans le joli référentiel git.C'est génial
- Note:Vous trouverez peut-être un peu plus difficile de sortir des choses de git que de les faire entrer, mais il est de loin préférable d'avoir ce problème que de ne pas avoir les fichiers du tout !
D'après ma propre expérience, je ne recommanderais pas git comme introduction au contrôle de version.Je l'utilise depuis quelques mois maintenant et j'ai l'impression qu'il est très puissant et - maintenant que j'y ai partiellement compris - raisonnablement intuitif.Cependant, la courbe d'apprentissage est très abrupte, même si j'utilise le contrôle de version depuis des années.Il souffre également d'être trop expressif : il prend en charge de nombreux flux de travail et modèles de développement différents, mais le seul guide sur la "meilleure" façon de l'utiliser se trouve dans quelques pages approfondies d'une recherche Google, ce qui rend également difficile la sélection pour un nouveau venu. en haut.
Cela dit, il est possible que repartir d'une page vierge avec git soit en fait plus facile - mon expérience VCS repose entièrement sur le contrôle de version centralisé (CVS, SVN, Perforce...) et une partie de mes difficultés (continues !) avec git a été comprendre les implications du modèle distribué.J'ai jeté un bref coup d'œil à d'autres DVCS comme Bazaar et Mercurial et ils semblaient être un peu plus conviviaux pour les débutants.
Quoi qu'il en soit, comme d'autres l'ont dit, Subversion est probablement le moyen le plus simple de s'habituer à l'état d'esprit du contrôle de version et d'acquérir une expérience pratique des avantages de VCS (restauration, branches, développement collaboratif, révision de code plus facile, etc.).
Oh, et ne commencez pas par CVS.Il est toujours utilisé dans la pratique et présente des avantages, mais à mon humble avis, il présente trop de bizarreries historiques et de problèmes de mise en œuvre (engagements non atomiques !) Pour être un bon moyen d'apprendre.
Mon vote va à Subversion.Il est très puissant, mais facile à utiliser, et dispose d'excellents outils comme TortueSVN.
Mais comme d’autres l’ont dit avant moi, COMMENCEZ JUSTE À L’UTILISER.Le contrôle de code source est une partie très importante du processus de développement logiciel.Aucun projet logiciel « sérieux » ne devrait s’en passer.
Dans mon emploi actuel, mon prédécesseur n’utilisait aucun type de contrôle de version.Il y a juste des montagnes de dossiers dans au moins 3 endroits différents où il a conservé tous ses projets.Tout dossier de projet aléatoire peut trouver au moins un nom de dossier « projet (ANCIEN) » et un autre nommé « projet »
Avec le contrôle de version, vous n'avez jamais besoin de faire des copies de versions « sûres ».Vous n'avez pas vraiment à vous soucier de la corruption du fichier sur lequel vous travaillez par votre IDE (je vous regarde, REALBasic 5.5) car il est si facile à valider (Lire :Enregistrez) votre travail chaque jour.
Inutile de dire que j’ai installé le contrôle de version le lendemain de la découverte de son existence.
De plus, TortoiseSVN rend la validation dans la base de données aussi simple qu'un clic droit sur un dossier.
Essayez également visuel svn pour votre serveur si vous souhaitez éviter tout travail en ligne de commande.
Si vous êtes sous Mac OSX, j'ai trouvé que http://www.versionsapp.com/">Versions était une incroyable interface graphique (gratuite) pour SVN.
Git est supérieur à Subversion, mais il est un peu à la pointe de la technologie.
Je dirais que si vous débutez, sautez sur le bord ;créer un compte gratuit @ http://github.com
Ils ont du matériel pédagogique sur place pour configurer et utiliser git.
N'attendez pas.Choisissez-en un et allez-y.Tous les systèmes auront leurs avantages et leurs inconvénients.Votre alimentation pourrait être coupée, votre ordinateur se fait voler ou vous oubliez d'annuler une modification majeure et tout votre code sera grillé pendant que vous attendez de voir qui sortira victorieux.
Il n'est pas si difficile de basculer entre les systèmes de contrôle de version.Comme d'autres l'ont mentionné, l'important est de commencer à utiliser quoi que ce soit le plus tôt possible.Les avantages de l’utilisation du contrôle de source par rapport à la non-utilisation du contrôle de source dépassent largement les avantages différentiels entre les différents types de contrôle de source.
N'oubliez pas que quelle que soit la version du contrôle de code source que vous utilisez, vous pourrez toujours effectuer une conversion par force brute vers un autre système en déposant les fichiers de votre ancien système sur le disque, puis en important ces fichiers bruts dans le nouveau système.
De plus, être familiarisé avec les principes fondamentaux du contrôle de code source est une compétence très, très importante en tant que développeur de logiciels.
Utilisez TortoiseSVN (version.app si sur mac).Installez-le et c'est parti.Si vous avez besoin d'un endroit pour héberger votre code, consultez http://beanstalkapp.com/
SubVersion est le meilleur choix pour vous, comme l'a souligné Karl Seguin, passer à un autre système de gestion de versions ne serait pas un problème.SVN a également des interfaces graphiques très simples à utiliser côté client (TortoiseSVN).
http://www.snee.com/bobdc.blog/2007/08/getting_started_with_subversio.html http://dojo.jot.com/WikiHome/Getting%20Started%20With%20Subversion
Si vous choisissez d'utiliser Subversion et que vous souhaitez héberger votre propre serveur SVN, il existe un serveur Windows très agréable et simple appelé serveur VisualSVN.Cela cache la complexité de la configuration d'un serveur Apache, vous passez simplement au suivant.La configuration utilisateur est gérée avec une interface Web, au lieu d'une configuration
http://www.visualsvn.com/server/
utiliser un service public comme Beanstalk est probablement plus facile, mais certaines personnes aiment avoir leurs propres référentiels, que ce soit pour des raisons de rapidité ou de sécurité.
Lorsque j'ai décidé que je devais utiliser un système de gestion des versions de code, j'ai cherché de bons tutoriels sur la façon de démarrer, mais je n'en ai trouvé aucun qui puisse m'aider.
J'ai donc simplement installé le serveur SVN et Tortoise SVN pour le client et plongé dans les profondeurs et je n'ai pas appris à l'utiliser en cours de route.
Commencez à utiliser SVN pour votre travail réel, mais essayez de prendre le temps de jouer avec Git et/ou Mercurial.SVN est raisonnablement stable pour la production, mais vous finirez par être confronté à un scénario dans lequel vous devrez besoin un SCM distribué, auquel moment vous serez correctement armé et les nouveaux systèmes seront suffisamment matures.
Ouais, SVN de préférence, sauf si vous avez vraiment besoin des fonctionnalités particulières de git.SVN est déjà assez difficile ;On dirait que git est plus compliqué à vivre.Vous pouvez obtenir du SVN hébergé auprès de personnes comme haricot magique - à moins que vous n'ayez des collaborateurs Linux en interne, je le recommanderais vraiment.Les choses peuvent mal tourner très facilement et c'est bien d'avoir quelqu'un d'autre dont le travail consiste à les réparer.
Il y a un excellent Didacticiel sur le contrôle des révisions d'Eric Sink qui vaut la peine d'être lu quel que soit le système que vous utilisez.
Question connexe (les réponses peuvent peut-être être modifiées pour répondre également à cette question) :
Qu'en est-il de l'utilisation du contrôle de code source sur votre propre ordinateur, si vous êtes le seul programmeur ?Est-ce une bonne pratique ?Existe-t-il des trucs ou astuces connexes ?
J'utilise SVN pour tous mes projets personnels.J'ai commencé par exécuter svn sur mon ordinateur personnel, mais j'ai finalement migré vers Dreamhost.Leurs forfaits d'hébergement qui incluent Subversion sont assez raisonnables.
Si sur une boîte Windows, une solution rapide et sale est CVSNT.Facile à utiliser, il suffit de l'installer et fonctionne très bien.
Je préfère moi-même SVN mais c'est un bon choix pour une utilisation rapide.
Je choisirais certainement SVN plutôt que CVS, ne serait-ce que parce que les personnes qui ont appris le contrôle de code source à l'aide de CVS ont tendance à utiliser "svn delete" alors "svn add" au lieu de "svn move".Ce qui rend plus difficile la recherche de toutes les révisions précédentes d’un fichier spécifique.Et vous pouvez toujours passer à l'utilisation de git-svn.Personnellement, je pense que c'est plus facile à apprendre que l'hg, mais en réalité, le principal La raison d'utiliser SVN est qu'il est en grande partie devenu le système de contrôle de version de facto des logiciels Open Source.
Si jamais vous envisagez d'apprendre / d'utiliser D il est presque obligatoire d'accéder aux référentiels tiers, comme DSource.
@superjoe30 Oui, absolument.Une fois que vous commencez à utiliser le contrôle de version, vous ne revenez plus jamais en arrière.Je l'utilise pour tout, même mon dossier "home".
@Orion Edwards Subversion ne nécessite pas de serveur.Vous pouvez accéder directement à un référentiel local (via un client, bien sûr), et aucun processus serveur n'est impliqué.
Utilisez simplement TortoiseSVN, et vous pouvez vivre même sans connaître les commandes Subversion réelles...Mais c'est mauvais.Heureusement, il y aura toujours une « excellente opportunité » de les apprendre par cœur – lorsque votre référentiel inestimable sera corrompu pour la première fois.
Oui, ça arrive.
Comme mentionné à plusieurs reprises ailleurs, Just Do It.J'ai pu repartir de zéro avec Subversion sous Windows en un rien de temps en lisant le guide de démarrage rapide dans le Livre Rouge.Une fois que j'ai pointé TortoiseSVN vers le référentiel, j'étais en affaires.Il m'a fallu un certain temps pour comprendre les subtilités, mais il s'agissait de petites difficultés à surmonter.
Je suggérerais d'installer le service Subversion au lieu d'utiliser les URL file://, mais c'est surtout une préférence personnelle.Pour un référentiel stocké sur votre machine de développement, file:// fonctionne correctement.
D'après mon expérience personnelle, svn serait ma recommandation.Vous pouvez même utiliser un service comme haricot magique qui propose des comptes gratuits (avec des limites évidemment, mais suffisants pour tout petit projet) pour tester le terrain.Mais comme d'autres l'ont dit, git est supérieur et mérite probablement d'être étudié.
Un conseil majeur pour faciliter la configuration d’un serveur SVN dès maintenant est d’utiliser une appliance virtuelle.C'est-à-dire une machine virtuelle sur laquelle Subversion est préinstallée et (principalement) préconfigurée - à peu près une chose plug & play.Tu peux essayer ici, ici et ici, ou essayez simplement de rechercher sur Google "appliance virtuelle Subversion".
