Extensions TortoiseGit vs Git
Quels sont les avantages et les inconvénients de l'utilisation des extensions Git ou de TortoiseGit sur un système d'exploitation Windows?
Je ne connais pas GitExtensions, mais je peux partager mon expérience avec TortoiseGit (mentionné par le commentaire de marc_s):
Avantages:
- Excellente intégration avec Windows (c'est une extension Shell)
- Presque la même interface utilisateur que TortoiseSVN (si vous avez déjà utilisé TortoiseSVN, vous savez à quoi vous attendre).
Les inconvénients:
- Vous aurez difficile le temps de comprendre comment utiliser git.
Le problème avec TortoiseGit est que les gens qui ont travaillé avec TortoiseSVN pensez tout fonctionnera (ou devrait) fonctionner exactement comme dans SVN ... et finira par ne jamais vraiment comprendre comment travailler avec git. En tant qu'expérience personnelle, la société dans laquelle je travaille a migré de SVN vers git après 2 ans, et chaque développeur qui a utilisé TortoiseGit a fini par ne pas vraiment savoir ce qu'il faisait et a parfois foiré ses référentiels locaux. Au final, ils ont abandonné TortoiseGit et passent du temps à apprendre git "à la dure" (Shell, msysGit sous Windows) et tout le monde est content depuis.
Conclusion: utilisez simplement msysGit directement et apprenez correctement git. Vous éviterez de nombreux maux de tête à l'avenir.
Mon entreprise a essayé les deux et a rapidement abandonné Tortoise Git. Il s'est écrasé beaucoup plus souvent. Les codeurs affirment que Tortoise Git n'est pas assez capable mais je ne l'ai pas vérifié moi-même. Mais j'ai vu beaucoup de crashs moi-même.
Les codeurs préfèrent git bash, les autres utilisent mais détestent les extensions git. Bien que certains d'entre eux ouvrent également git bash. Git bash est inévitable pour voir les compteurs de progression.
Git Extensions n'a pas d'option pour afficher les compteurs de progression lors d'un pull. Donc, avec Git Extensions uniquement, vous êtes assis devant une barre de non-progression énigmatique, sans savoir ce qui se passe et si quelque chose a échoué. Le pire est un mot de passe manquant ou incorrect: Git Extensions vous permet simplement d'attendre indéfiniment, affichant la même barre lumineuse que s'il faisait quelque chose de long. Une autre horreur des extensions Git est l'abandon fréquent avec "out of memory", lors de la version de nombreux gros fichiers et du tirage avec rebase. Après un tel abandon, les utilisateurs non codants sont toujours submergés de problèmes. De nombreux fichiers qu'ils n'ont pas modifiés apparaissent comme modifiés et le fichier de verrouillage les empêche de traiter le problème, etc.
À mon avis, les deux outils GUI sont immatures.
Vous voulez des extensions Git pour une raison importante - il vous montre la vue graphique du journal de validation (voir ci-dessous). Sans cette vue graphique, je ne pense pas que la plupart des gens qui découvrent git n'auront jamais ce qui se passe avec les branches, les commits, les rebasages, la sélection de cerises, etc. (je sais que je ne l'ai pas fait).
Vous allez aussi vouloir faire une partie de votre travail sur la ligne de commande, c'est votre meilleur pari d'utiliser pratiquement git puisque toute l'aide que vous obtiendrez sera basée sur la ligne de commande.
Cela dit, vous pouvez également utiliser Tortoise Git (en supposant que cela fonctionne) car ils appellent tous les mêmes exécutables de ligne de commande et agissent sur le même référentiel git.
La plupart des IDE prennent également en charge git, JetBrains IDEA fait un excellent travail en ajoutant des listes de modifications et d'autres fonctionnalités par-dessus.
Je n'ai pas beaucoup d'expérience avec TortoiseGit, mais j'ai installé et j'utilise actuellement GitExtensions v2.21.
Les plus grands avantages de l'utilisation de GitExtensions:
- affichage graphique visuel de type gitk des lignes de code et des branches, avec toutes les informations essentielles disponibles dans des onglets, éliminant ainsi le besoin de travailler avec les SHA hostiles.
- la possibilité d'installer en tant qu'administrateur et tous les autres utilisateurs sur le même PC peut l'utiliser comme n'importe quel utilisateur ordinaire.
- intégration intégrée de Shell avec l'Explorateur Windows
- intégration prête à l'emploi avec Visual Studio (les utilisateurs de Windows Eclipse n'ont besoin que de msysgit, car ils ont leur propre interface graphique pour remplacer le besoin de GitExtensions)
- programme d'installation facile à utiliser qui est pré-emballé avec toutes les fonctionnalités nécessaires et pré-requises pour démarrer hors de la boîte (SSH Client, KDiff, msysgit).
- intégration avec GitHub (Fork, clone, pull sont tous rationalisés)
Désavantages:
- la documentation ne suit pas les nouvelles fonctionnalités constamment ajoutées. Par exemple, je ne sais toujours pas comment utiliser les fonctionnalités de script.
De peur d'oublier qu'il s'agit d'un programme entièrement gratuit, et qui nous est proposé en option sans aucune condition, je ne vois pas la raison pour laquelle de telles attentes sont placées dessus, comme si nous étions des clients payés? J'ai vu certains des abandons et du gel mentionnés par l'utilisateur précédent, mais je pense que la majorité de ceux-ci ont été corrigés dans la version 2.24. Beaucoup des abandons et des actions ayant échoué ne sont vraiment pas la faute de GitExtensions, mais plutôt un symptôme d'un problème systémique en dehors de GitExtensions (par exemple, configuration SSH mal configurée, problèmes d'autorisations de fichiers sur le serveur hébergeant le repo distant, etc.). Par exemple, il y a eu une fois où j'ai fait un simple Push qui a provoqué un échec et un abandon. Il s'avère que la télécommande sur laquelle j'essayais de pousser était sur un très long chemin d'accès, ce qui posait des problèmes pour le serveur Mac qui hébergeait le dépôt.
Quoi qu'il en soit, cela dit cependant, mon expérience avec GitExtensions a été assez positive. Je trouve que les avantages décrits ci-dessus ont valu la peine de supporter les abandons et les blocages occasionnels jusqu'à ce que les bogues soient corrigés.
Je ne peux pas parler à Git Extensions car je ne l'ai jamais utilisé. J'ai eu quelques problèmes avec GIT pur. Impossible d'intégrer GVIM, par exemple. Tortoise Git a un éditeur intégré et un outil de diff (ce qui est incroyable), c'est donc une commodité très agréable. J'ai adoré les diagrammes de branches dans le livre de Scott Chacon et j'espérais que TGit aurait un diagramme similaire. Ils ont un outil pour montrer les branches mais ce n'est pas aussi agréable que celui du livre.
Une chose à garder à l'esprit est que, comme TGit n'est qu'un Shell au-dessus de GIT, il n'y a aucun mal à mélanger les deux méthodes. J'utilise TGit pour presque tout, mais je plonge dans GIT pour les commandes qui sont maladroites ou que je ne comprends tout simplement pas bien dans TGit. Mais même si vous prévoyez d'utiliser TGit, il est toujours important, comme mentionné ci-dessus, de comprendre d'abord les bases de GIT. J'avais lu le premier, disons, trois chapitres du livre Chacon (disponible gratuitement en ligne sur http://progit.org/book/ ou par achat sur Amazon). Si vous êtes comme moi, vous voudrez peut-être les lire plusieurs fois pour laisser le paradigme pénétrer. Ce n'est pas si compliqué, mais c'est très différent des VCS précédents.
TGit ne m'a jamais écrasé, comme cela a été le cas pour certains des autres critiques, mais mes repo ont été petits. Il a mangé mes commentaires de validation à plusieurs reprises, ce qui aurait pu être une erreur de l'utilisateur. Comme vous pouvez revenir en arrière et rééditer les commentaires, ce n'était qu'une gêne et valait la peine d'avoir une interface graphique, avec des fenêtres qui affichent beaucoup d'informations en un coup d'œil.
Juste pour contrer certaines des remarques ci-dessus:
Avec l'attente correcte, TortoiseGit fournit une excellente interface graphique pour travailler avec git sous Windows. Ce n'est pas un remplacement pour TortoiseSvn, mais un gui amélioré par rapport à ce que l'on peut réaliser en utilisant gitk + git-gui (qui peut être considéré comme faisant partie de la fonctionnalité de base de git et accessible dans msysgit). La seule mauvaise chose que je vois est la façon dont vous n'auriez pas besoin de vous souvenir de toutes les commandes exactes pour l'extraction/le rebase/la fusion, etc., car il est possible de faire tout cela très facilement via l'interface graphique (ce qui est le point principal). Les problèmes PuTTY/ssh ont plus à voir avec la prise en charge inférieure de ssh sous Windows et ne sont pas propres à TortoiseGit.
J'utilise GitExtensions. Je n'ai pas utilisé TortoiseGit mais l'un de nos autres développeurs l'adore et refuse d'utiliser GitExtensions. Son raisonnement est 1) C'est familier; 2) Il a une grande intégration de l'Explorateur Windows.
En utilisant GitExtensions, j'ai tendance à utiliser l'intégration de l'Explorateur Windows pour trois choses seulement:
1) Pour créer un nouveau référentiel local (élément de menu contextuel Git Init Here, qui est en fait une commande Git pour Windows; GitExtensions se trouve au-dessus de Git pour Windows);
2) Pour ouvrir l'interface graphique des extensions Git (la fenêtre de navigation);
3) Pour cloner un référentiel distant vers un référentiel local (élément de menu contextuel Git Extensions> Cloner).
Pour à peu près tout le reste, j'ai juste l'interface graphique GitExtensions et je travaille à partir de là.
Les développeurs de GitExtensions prétendent que presque toutes les commandes peuvent être exécutées à partir de l'interface graphique. Ce n'est pas tout à fait vrai, mais je trouve que je n'ai besoin de passer dans l'interface de ligne de commande qu'une ou deux fois par mois pour les tâches complexes.
Dans certains cas, l'interface graphique simplifie les tâches complexes en masquant la complexité des commandes Git sous-jacentes. Cela implique parfois de combiner plusieurs commandes Git en une seule action. Par exemple, créer des sous-modules où l'interface graphique combine l'ajout d'un sous-module, son initialisation et sa mise à jour en une seule action. Dans un autre cas, l'interface graphique simplifie une tâche en fournissant une commande qui manque à Git - supprimer un sous-module (dans Git, vous devez modifier manuellement les différents fichiers tels que .gitmodules et .git/config pour supprimer un sous-module). Je serais intéressé de savoir si TortoiseGit simplifie les tâches complexes de manière similaire.
GitExtensions a également une intégration de Visual Studio assez basique. Je ne sais pas si TortoiseGit le fait. Il existe un fournisseur de contrôle de source Git distinct pour Visual Studio 2008 et 2010 qui fournit une intégration de Visual Studio beaucoup plus étendue. Cependant, après avoir installé le fournisseur de contrôle de source Git, je trouve que je ne l'utilise jamais. La seule intégration GitExtensions que j'utilise dans Visual Studio se trouve dans la barre d'outils, pour ouvrir l'interface graphique GitExtensions avec le référentiel approprié. Je vais travailler avec Visual Studio sur un moniteur et GitExtensions ouvrir dans l'autre.
Depuis au moins la version 2.32, GitExtensions affiche le nombre de fichiers non validés dans sa barre d'outils. J'utilisais auparavant la 2.24 qui n'avait pas cette fonctionnalité et c'est très pratique. Donne une rétroaction instantanée sur la présence ou non de modifications non validées.
Pour une compilation, une personnalisation et une construction rapides et faciles des extensions, GitExtensions est meilleur (C #) que TortoiseGit (Visual C++ MFC)
Pour la portabilité, GitExtensions est meilleur (.NET sur Windows/mono sur Linux/Mac) que TortoiseGit (Win32/64 uniquement)
Pour utiliser la superposition d'icônes dans l'Explorateur, utilisez TortoiseGit
Pour les performances de certaines fonctionnalités, TortoiseGit est meilleur car il appelle une bibliothèque statique/dynamique pour récupérer le résultat à partir du référentiel, tandis que GitExtensions n'appelle que la ligne de commande git.exe qui a une surcharge plus importante.
Pour migrer depuis TortoiseSVN, TortoiseGit sera plus familier avec GitExtensions
DATE: 2011-08-27.
À ce stade, Tortoise Git NE FONCTIONNE PAS du tout, et le problème sur le site de code Google n'a pas reçu d'attention depuis un mois: http://groups.google.com/group/tortoisegit-users/browse_thread/ fil/9090337b7936e1e1 .
La case "Charger la clé PuTTY" de la fenêtre contextuelle sur la première utilisation de Tortoise Git pour cloner un site (et commencer à développer) est grisée. Donc, aucune clé privée n'est trouvée, et le message d'erreur est "connexion interrompue" RÉUSSIE !!!!
Git Bash fonctionne parfaitement, bien que basé sur une console. Et si tout le monde ci-dessus parle de ne pas comprendre le concept de Git lors de l'utilisation de Tortoise Git, je m'en tiendrai à l'écart en fonction de cela, même sans tenir compte des 3 dernières heures que j'ai passées à essayer de faire fonctionner Tortoise Git pour un développeur. Il va devoir apprendre la console Git, ou aller sur la route.
Je l'ai fait fonctionner en 15 minutes, et je suis juste un pirate essayant d'embaucher des programmeurs ;-)
PS, Eclipse dispose des trois principaux "connecteurs" du référentiel de contrôle de version et est un très bon éditeur.