Quel DVCS (git ou hg) est plus facile pour les étudiants en programmation? [fermé]


25

Un peu de contexte: je suis en 3e année de collège. les étudiants sont divisés en équipes de 4. Presque tout le monde travaillera sous Windows (sauf quelques-uns comme moi qui sont sous Linux). Dans le cadre du programme scolaire, nous allons bientôt commencer à travailler sur un projet pour un vrai client, mais moi et une autre équipe nous demandons quelle serait la meilleure façon de partager notre code les uns avec les autres.

Je travaille à temps partiel depuis 3 ans et j'ai eu beaucoup d'expérience en utilisant à la fois git et mercurial sur différents projets, donc je n'ai aucun problème à utiliser un système ou l'autre. Cependant, aucun de mes coéquipiers n'a jamais utilisé de système de contrôle de version auparavant. Il y a aussi une autre équipe qui a essayé d'utiliser SVN mais qui a eu des problèmes majeurs et qui préférerait essayer autre chose, alors ils ont demandé mon avis.

Mes pensées: J'ai entendu dire que mercurial + TortoiseHg a une meilleure intégration sous Windows, mais je me demande si le concept de têtes anonymes pourrait les confondre même si je les explique. D'un autre côté, je trouve que les branches git sont plus faciles à comprendre pour un débutant (séparation claire du travail pour chaque programmeur) mais ne fonctionnent pas aussi bien sous Windows.


2
git a beaucoup de puissance activée par défaut, mais tous ceux à qui j'ai parlé disent que mercurial est plus simple à apprendre, et je suis enclin à accepter en fonction de mes expériences en utilisant les deux. Et oui, les outils mercuriels sont plus faciles à installer dans Windows que leurs équivalents git. Cela dit, attendez-vous à guider les gens et à les orienter vers des tutoriels pour la première semaine (ou plus ...).
wkl

1
L'utilisation d'un DVCS depuis le début est probablement le moyen le plus simple de gérer les contributions de fusion de plusieurs contributeurs travaillant en parallèle. Si vous trouvez des têtes anonymes déroutantes, ne les utilisez pas (mercurial supporte les branches nommées).
Stephen C. Steel,

2
Il est temps de créer un lien vers cet article de blog? Git est un Harrier Jump Jet .
sbi

1
Je n'ai jamais compris pourquoi l'ensemble «trop difficile à apprendre» est important. D'accord, il faut donc 20 minutes pour apprendre à s'engager et à créer des succursales, par opposition à 10 ... Big deal?
alternative

1
Regardez (l'un d'eux) passer par hginit.com et prendre des mesures en fonction de leurs réactions.
chelmertz

Réponses:


49

Mercurial, sans aucun doute.

Ceci est bien sûr subjectif et varie d'une personne à une autre, mais l'opinion générale est que Mercurial est plus facile à grogner, en particulier pour quelqu'un de nouveau sur VCS ou quelqu'un venant de l'un des VCS de l'ancienne génération.

Points en main:

  1. Mercurial a été développé avec Windows à l'esprit ; Git a été porté. Peu importe ce que quelqu'un a essayé de me dire, Git est toujours un citoyen de second ordre sur Windows. Les choses se sont certes améliorées au cours des dernières années, mais vous voyez toujours beaucoup de querelles pourquoi quelque chose fonctionne / ou ne fonctionne pas sur Windows comme il l'a fait sur * nix box. TortoiseHg fonctionne très bien et les implémentations de Visual Studio sont encore plus faciles à utiliser sans interrompre votre flux de travail.

  2. Si quelqu'un commence la discussion "Git est plus puissant après toi ...", alors il dit à peu près tout. Pour 95% des utilisateurs, Mercurial semble plus intuitif. À partir d'un manque d'index, de ses options plus intuitives (les commutateurs d'options sont cohérents), de ses numéros locaux pour les validations au lieu des hachages SHA1 (qui ont déjà pensé que les hachages SHA1 étaient conviviaux ??!)

  3. Les branches de Mercurial ne sont pas moins puissantes que celles de Git. Message décrivant certaines des différences. Revenir à une révision précédente est aussi simple que «mettre à jour l'ancienne révision». À partir de là; faites juste un nouveau commit. Des branches nommées sont également disponibles si l'on souhaite les utiliser.

Maintenant, je sais que ce sont tous des détails, et ils peuvent être appris et tout, mais le truc c'est que ... ces choses s'additionnent. Et au final, l'un semble plus simple et plus intuitif qu'un autre. Et le système de contrôle de version ne devrait pas être quelque chose que l'on passe du temps à apprendre - vous êtes là pour apprendre la programmation puis pour programmer; VCS est un outil.

Juste pour noter; J'utilise Git et Mercurial quotidiennement. N'ayez aucune difficulté à utiliser l'un ou l'autre. Mais quand quelqu'un me demande une recommandation, je recommande toujours Mercurial. Rappelez-vous encore, quand il est venu entre mes mains, c'était très intuitif. D'après mon expérience, Mercurial produit juste moins de WTF / minute que Git.


4
+ pour "VCS est un outil". Je n'avais pas considéré les «petites choses» comme un facteur, mais il est vrai que lorsque vous additionnez de petits problèmes ici et là, ils peuvent devenir une véritable nuisance.
Gregory Eric Sanderson

8
"Le système de contrôle de version ne devrait pas être quelque chose que l'on passe du temps à apprendre." Ceci est une charge de merde. Vous devriez toujours passer du temps à apprendre vos outils. Vous passez du temps à apprendre votre compilateur; mais le VCS est un outil aussi critique pour votre programmation que votre compilateur.
JesperE

9
+1. En particulier, l'argument du «citoyen de deuxième classe sous Windows» est absolument important dans cette situation.
tdammers

+1 pour "WTF (s) / minute" ( osnews.com/story/19266/WTFs_m ). Ces enfants doivent apprendre les compétences :-)
Ross Patterson

1
@Mark qui est juste le résultat d'une différence de terminologie ... Une branche dans Git n'est vraiment qu'un nom.
alternative

10

J'ai trouvé que l'interface utilisateur de TortoiseHg est une excellente expérience sur Windows. Lors d'expériences avec Git dans le passé, j'ai fini par aller à la ligne de commande à la place. Pour votre utilisateur moyen, une bonne interface utilisateur est beaucoup plus accessible qu'une ligne de commande. Donc, je suggère d'utiliser Mercurial. (Il inclut également un joli graphique de branchement dans la fenêtre du plan de travail. Il devrait éliminer toutes les difficultés de branchement de base.)

Une fois qu'ils ont compris les choses du point de vue de l'interface utilisateur, ils peuvent finir par aller sur la ligne de commande pour écrire des scripts ou effectuer des opérations manuelles - mais ils n'en ont pas besoin.


Étant moi-même un "accro à la console", je n'ai jamais utilisé les applications Tortoise {Svn, Git, Hg} auparavant, donc je ne savais pas que TortoiseHg avait un graphique de branche. Je vais devoir vérifier ça
Gregory Eric Sanderson

4

Si vous êtes intéressé par une troisième option, je suggère un fossile . Je trouve que la possibilité de lancer un serveur Web temporaire pour partager du code fonctionne très bien dans les petits projets. Fossil n'est qu'un exécutable, vous pouvez donc le placer, ainsi que votre source, dans une clé USB et l'utiliser à partir de n'importe quel ordinateur universitaire.

Utilisez fossil uipour démarrer un serveur Web temporaire où que vous soyez pour que vos camarades de classe se synchronisent avec vous. Il vous offre également un système de ticket, un wiki et une interface Web facile à utiliser pour changer de branche et marquer des commits.

Assurez-vous simplement qu'ils lisent le guide de démarrage rapide et / ou le livre . Enfin, il existe un projet appelé winFossil pour leur donner une interface utilisateur plus conviviale que l'interface utilisateur Web.


J'ai entendu de bonnes choses sur les fossiles, mais malheureusement je n'ai pas beaucoup de temps pour me familiariser avec un nouveau DVCS. Je préfère utiliser quelque chose que j'ai l'habitude (si possible) car je sais déjà comment contourner les pièges les plus courants. Mais merci pour la suggestion, je vais certainement y réfléchir une fois que j'aurai le temps.
Gregory Eric Sanderson

+1; fossile est peu connu mais il est si facile à travailler et tellement autonome (dvsc + wiki + tickets + webserver) qu'il est une vraie alternative à l'ensemble de trac ou même de github.
Javier

Mais le fossile ne sera pas aussi beau sur le CV des étudiants que git ou hg, car très peu de gens ont du mal.
Ian

Mercurial a également intégré la fonctionnalité hg serve. Il manque bien sûr un bug tracker et un wiki. Mais alors il y a aussi bitbucket.com
Johannes Rudolph

3

Étant donné que les équipes sont nouvelles dans le contrôle de version et que beaucoup utilisent Windows, je recommanderais mercurial plutôt que git.

Le modèle conceptuel de contrôle de version utilisé par git et mercurial est très similaire, donc une fois que vous en maîtrisez un, il est facile de choisir l'autre (et pour des raisons similaires, il est assez facile de convertir un référentiel de l'un à l'autre) . Cela signifie que ce n'est pas grave si vous changez d'avis plus tard.

À mon avis, mercurial est plus facile à apprendre pour les nouveaux utilisateurs. Cela rend les choses simples faciles et les choses dangereuses difficiles. Git facilite les opérations dangereuses (facile à faire, pas nécessairement facile à faire correctement!).

L'interface TortoiseHg pour Winodows est également très agréable, et est un autre argument en faveur de l'utilisation de mercurial.


2

Ma préférence personnelle est pour git.

Cependant, comme certaines personnes utiliseront Windows et que le superbe tutoriel hginit existe, je recommanderais de leur enseigner le mercurial.


+1 pour avoir mentionné hginit. Bien que Pro Git soit également très bon.
Tamás Szelei

@ TamásSzelei, Merci, je n'avais jamais vu Pro Git auparavant.
dan_waterworth

0

Comme beaucoup de gens l'ont suggéré, Mercurial via TortoiseHg a une très faible barrière à l'entrée.

Pour ceux sous Windows, c'est un programme d'installation unique plutôt que deux programmes d'installation (et toute une série de choses dont ils pourraient ne pas vouloir en savoir plus) et l'interface utilisateur THg est beaucoup plus soignée que TortoiseGit + Msysgit .

Têtes anonymes

Si vous pensez qu'ils seraient confus par des têtes anonymes, alors n'encouragez pas leur utilisation. La plupart des hglivres adoptent une approche équilibrée et enseignent les branches topologiques et nommées, et laissent le lecteur déterminer celle qui convient le mieux à leur utilisation.

Branches nommées

Une chose qui me manque vraiment, cegit sont hgles branches nommées , c'est donc une option. gitles branches fonctionnent bien pendant que vous travaillez dessus, mais une fois que vous avez fusionné ce travail dans une autre branche, vous perdez une grande partie du contexte de ces changements.

Dans, hgvous pouvez créer une branche appelée Jira#1234et toujours pouvoir trouver toutes les révisions associées à ce correctif . Dans git, une fois votre branche fusionnée et la référence supprimée, vous devez déduire les révisions qui faisaient partie du correctif à partir de la topologie de l'arborescence de révision. Même si vous ne supprimez pas la référence, vous ne connaissez toujours que le dernier commit de cette branche, et pas quels ancêtres faisaient partie de cette chaîne de commits.

Signets

Alternativement, si vous ne souhaitez pas utiliser de branches nommées, mais souhaitez un gitworkflow de style avec vos branches anonymes, vous pouvez utiliser des signets à la place.

Cela pourrait être le meilleur des deux mondes - ils apprennent un gitflux de travail, mais utilisent les hgcommandes les plus simples .

Zone d'index / cache / staging

Personnellement, je pense que les étudiants sont beaucoup plus susceptibles d'être confus par la zone gitd'index / cache / staging que par hgles têtes anonymes. Je préfère de hgloin rendre cette fonctionnalité avancée facultative sur la ligne de commande, en gitsupposant que vous vouliez / ayez toujours besoin de l'utiliser.

Je pense également que la zone de transfert encourage les commits qui n'ont pas été testés ni même compilés. Étant donné que de nombreux endroits où j'ai travaillé ont eu une règle de non-validation si elle ne compile pas de règle, je préfère de loin mettre en réserve / cacher les modifications que je ne veux pas pour le moment, réexécuter les tests unitaires et valider une version qui Je sais compile.

Lorsque vous découvrirez plus tard un bogue en utilisant hg bisect ou git bisect , vous vous remercierez de pouvoir tester toutes les révisions, pas seulement celles qui se compilent.


Vous n'avez pas besoin de supprimer la branche git une fois que vous avez terminé; ce n'est qu'une coutume. Également -1 pour les erreurs d'interprétation de l'index - vous ne l'utilisez pas pour le transfert de mauvaises validations, vous l'utilisez pour le transfert d'étapes partielles d'une plus grande série de validations. Cela se produit généralement lors d'un rebasage lorsque vous effacez votre historique.
alternative

@mathepic - Si vous ne supprimez pas les noms des branches et que vous poussez toutes vos branches locales «fixes» vers la télécommande, vous allez vous retrouver avec un grand nombre de références, tout comme vous vous retrouvez avec une pléthore d'anciennes branches en svn. Dans hgces branches, les noms sont toujours topologiquement locaux, vous ne les voyez donc que si vous les recherchez.
Mark Booth,

@mathepic - Quant à votre -1, je pense que vous interprétez mal ce que je dis. Je ne peux pas imaginer pourquoi quelqu'un ferait intentionnellement un mauvais commit, mais avec git, il est facile de le faire par accident. Si vous oubliez que le fichier cimplémente une interface modifiée dans le fichier iet que vous validez accidentellement le isans calors si quelqu'un récupère vos modifications avant que vous ayez fini de valider cleur compilation échouera. Si vous utilisez le workflow stash / compile / commit à la place, cette erreur ne se produira tout simplement pas car votre propre build se cassera en premier. J'ai cependant essayé de clarifier ma réponse.
Mark Booth,
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.