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 hg
livres 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 hg
les branches nommées , c'est donc une option. git
les 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, hg
vous pouvez créer une branche appelée Jira#1234
et 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 git
workflow de style avec vos branches anonymes, vous pouvez utiliser des signets à la place.
Cela pourrait être le meilleur des deux mondes - ils apprennent un git
flux de travail, mais utilisent les hg
commandes les plus simples .
Zone d'index / cache / staging
Personnellement, je pense que les étudiants sont beaucoup plus susceptibles d'être confus par la zone git
d'index / cache / staging que par hg
les têtes anonymes. Je préfère de hg
loin rendre cette fonctionnalité avancée facultative sur la ligne de commande, en git
supposant 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.