J'utilise les deux au travail, Mercurial pour les développements internes/clients, Git pour les projets communautaires parce que GitHub.
En faisant abstraction de son horrible UI, Git permet d'être plus souple au quotidien : quand je fork un dépôt Git pour y contribuer, je peux me permettre de retravailler l'historique de ma branche comme je le souhaite sur mon dépôt perso (y'a peu de chance que quelqu'un l'ait forké à son tour donc je me permet de tout péter à coup de git rebase et git push -f avant de faire la pull request sur le projet upstream). Simple et rapide pour moi dans le cadre des petites contributions, et historique lisible pour ceux qui vont faire la revue de code avant un éventuel merge.
Par contre j'ai déployé Mercurial dans l'entreprise (pour remplacer SVN) car :
UI vraiment bien faite, les commandes sont cohérentes et évoluent en même temps suivant les plugins activés,
je suis le seul "barbu" dans l'équipe, et souhaite que le reste de l'équipe soit le plus autonome possible,
pas de git push --force, Mercurial ne fait que de l'ajout sur les dépôts distants : quand c'est pushé, c'est pushé ! En cas de grosses erreurs (genre commit d'un mot de passe pas sensé être publié), j'interviendrais à la main dans le dépôt distant et demanderai à ceux ayant déjà pullé de détruire le commit concerné ou refaire un clone. Ce n'est jamais arrivé, et ça relève du cas exceptionnel.
Bref, que de l'ajout sur les dépôts Mercurial distants, et cela veut aussi dire qu'on ne peut pas perdre des données de l'entreprise accidentellement, et pour moi c'était un critère important.
Je suppose qu'on peut bien sûr limiter ça avec Git également, mais c'est natif dans Hg.
le système de phases :
changeset draft (donc pushable, une fois pushé il deviendra public), qu'on affiche en vert dans les logs
changeset public (présent sur le dépôt distant, et impossible à modifier/supprimer, une erreur s'afficherait alors), affiché en bleu
changeset secret (avec hg ci --secret, rend le changeset local, ne peut être pushé par accident), affiché en rouge
hg out / hg in : pour voir ce qu'on peut récupérer, ou ce qu'on peut pusher, ça me manque énormément sous Git.
Mais je reconnais que le système de branche légère de Git est appréciable, autant que le fait que des changesets non-référencés seront détruits au bout d'un moment, ça procure pas mal de flexibilité à l'usage. Seulement c'est si reposant de travailler avec Hg... l'outil se fait oublier, et mes nerfs me disent merci :)
[^] # Re: Mercurial
Posté par Seb . En réponse au journal Git a fêté ses 10 ans hier .... Évalué à 10. Dernière modification le 08 avril 2015 à 20:12.
J'utilise les deux au travail, Mercurial pour les développements internes/clients, Git pour les projets communautaires parce que GitHub.
En faisant abstraction de son horrible UI, Git permet d'être plus souple au quotidien : quand je fork un dépôt Git pour y contribuer, je peux me permettre de retravailler l'historique de ma branche comme je le souhaite sur mon dépôt perso (y'a peu de chance que quelqu'un l'ait forké à son tour donc je me permet de tout péter à coup de
git rebaseetgit push -favant de faire la pull request sur le projet upstream). Simple et rapide pour moi dans le cadre des petites contributions, et historique lisible pour ceux qui vont faire la revue de code avant un éventuel merge.Par contre j'ai déployé Mercurial dans l'entreprise (pour remplacer SVN) car :
UI vraiment bien faite, les commandes sont cohérentes et évoluent en même temps suivant les plugins activés,
je suis le seul "barbu" dans l'équipe, et souhaite que le reste de l'équipe soit le plus autonome possible,
pas de
git push --force, Mercurial ne fait que de l'ajout sur les dépôts distants : quand c'est pushé, c'est pushé ! En cas de grosses erreurs (genre commit d'un mot de passe pas sensé être publié), j'interviendrais à la main dans le dépôt distant et demanderai à ceux ayant déjà pullé de détruire le commit concerné ou refaire un clone. Ce n'est jamais arrivé, et ça relève du cas exceptionnel.Bref, que de l'ajout sur les dépôts Mercurial distants, et cela veut aussi dire qu'on ne peut pas perdre des données de l'entreprise accidentellement, et pour moi c'était un critère important.
Je suppose qu'on peut bien sûr limiter ça avec Git également, mais c'est natif dans Hg.
le système de phases :
hg ci --secret, rend le changeset local, ne peut être pushé par accident), affiché en rougehg out/hg in: pour voir ce qu'on peut récupérer, ou ce qu'on peut pusher, ça me manque énormément sous Git.Mais je reconnais que le système de branche légère de Git est appréciable, autant que le fait que des changesets non-référencés seront détruits au bout d'un moment, ça procure pas mal de flexibilité à l'usage. Seulement c'est si reposant de travailler avec Hg... l'outil se fait oublier, et mes nerfs me disent merci :)