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

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.

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.

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.

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.

É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.

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.

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.