Microsoft sort Visual Studio Tools for Git

Version imprimable

06/05/2013, 18h25
Hinault Romaric

Microsoft sort Visual Studio Tools for Git

Microsoft sort Visual Studio Tools for Git
une extension pour intégrer les fonctions de gestion de versions de Git dans Visual Studio et TFS

Microsoft accentue le support de Git, l’outil open source de gestion de versions décentralisé, dans Visual Studio et Team Foundation Server (TFS).

La firme a publié récemment une nouvelle version de l’extension Visual Studio Tools for Git, qui apporte à l’environnement de développement un ensemble d’outils et fonctionnalités pour le contrôle de versions des applications.

L’extension Visual Studio Tools for Git permet l’intégration et la gestion de n’importe quel dépôt Git dans Visual Studio. Elle fournit des outils qui permettent de travailler avec des services comme GitHub. L’outil offre un suivi automatique des changements dans une solution Visual Studio, affiche l’état des fichiers dans l’explorateur, dispose des fonctions de gestion des commits et des branches, etc.

Le changement phare dans cette mouture réside dans des améliorations significatives de la vitesse. Cette version promet des outils plus rapides pour les commits, les « push » et de meilleures performances lors des travaux sur des repository de grandes tailles.

Selon les tests effectués par Microsoft, l’envoi de 10 fichiers d’un kilotects a permis de constater un gain de performances pouvant atteindre 4 765 %.

http://www.developpez.com/public/ima...toolsfrgit.png

On notera également des correctifs de bogues, une meilleure gestion de CRLF (saut de ligne), le support des sous-modules du projet libgit2, une meilleure prise en charge de l’authentification pour Windows et bien plus.

Visual Studio Tools for Git est compatible avec Visual Studio 2012 Update 2 et Team Foundation Server 2012 Update 2.

http://rdonfack.developpez.com/images/vs2012.png

:fleche: Télécharger Visual Studio Tools for Git

Source : MSDN

Et vous ?

:fleche: Utilisez-vous Git ? Que pensez-vous de son support dans Visual Studio ?
06/05/2013, 20h14
tomlev

Citation:

Envoyé par Hinault Romaric

Selon les tests effectués par Microsoft, l’envoi de 10 fichiers d’un kilotects a permis de constater un gain de performances pouvant atteindre 4 765 %.

Je crois que tu t'es un peu mélangé les pinceaux dans la lecture du tableau... Le push de 10 fichiers d'1ko, c'est justement le seul truc où les performances ont diminué. Les 4765%, c'est sur le clonage d'un repo ;)

Citation:

Envoyé par Hinault Romaric

:fleche: Utilisez-vous Git ? Que pensez-vous de son support dans Visual Studio ?

J'ai un peu testé, j'ai créé quelques repos sur Github pour voir comment ça marchait. J'aime bien le principe, mais ça me semble un peu plus compliqué que Subversion quand même, il faudra un peu de pratique pour s'habituer...

Sinon j'ai aussi testé Mercurial, qui ressemble beaucoup à Git dans ses principes, avec à peu près les mêmes fonctionnalités, mais qui me semble un peu plus simple (ou alors c'est peut-être juste la terminologie employée qui est plus claire). Pour ceux qui sont curieux de savoir ce que c'est qu'un système de contrôle de version distribué et ce que ça apporte, je conseille vivement ce tutoriel Mercurial, très clair et très facile à suivre.
06/05/2013, 21h24
djuju

Citation:

Envoyé par Hinault Romaric

:fleche: Utilisez-vous Git ? Que pensez-vous de son support dans Visual Studio ?

On ne peut toujours pas utiliser ce client Git avec tunnel ssh. C'est une limitation due à libgit2 qui est utilisé comme couche de communication par MS.
Je ne pourrais malheureusement pas utiliser ce produit tant qu'ils n'ajouteront pas le support ssh :cry: ...
07/05/2013, 13h14
alex_vino

Citation:

Microsoft sort Visual Studio Tools for Git

Sauf erreur de ma part cette extension existe depuis longtemps :ccool:
Pour effectuer les dernieres mises a jour il faut Visual Studio 2012.2 (Update 2).

J'ai testé et je n'ai pas rencontré de probleme. Par contre maintenant j'utilise le client Windows de Git, je le trouve lus simple et me suffit amplement.
07/05/2013, 15h19
Freem

Les DVCS (Git, mercurial...) ne sont pas plus compliqués à appréhender que les VCS (SVN, CVS), si l'on a jamais touché à un VCS auparavant.

La principale différence, c'est qu'au lieu de devoir faire des requêtes sur un serveur distant au moindre pet (sauf la remise au dernier état connu), on a tout en local, et c'est donc infiniment plus rapide (enfin, sauf les synchronisations quand une quantité importante de code à été modifiée sur le dépôt de référence, ce qui inclue les clonages de gros projets).

En fait, un DVCS, c'est un peu comme si tu avais le serveur SVN sur la même machine que le client, sauf que le serveur en question aurait la capacité de se synchroniser avec un autre serveur SVN.

Au niveau des avantages, ça facile par exemple le fait de faire un commit après chaque modification: un renommage quelconque, une correction de bogue, un ajout de fonctionnalité...
Les DVCS rendent les commits atomiques plus simples à gérer parce qu'il n'y a pas besoin de se réserver l'usage des fichiers sur lesquels on bosse (puisque le serveur est chez nous et que personne n'y a accès en écriture normallement).

Le principe c'est en gros:
_ je code
_ je considère qu'un jeu des modifications que j'ai faite est atomique, je le commit (commit)
_ je code
_ je considère qu'un jeu des modifications que j'ai faite est atomique, je le commit (commit)
_ je veux envoyer mes modifs sur un serveur tiers (sur lequel j'ai le droit d'écrire) donc je commence par tirer son état (pull) lors d'un commit précis
_ je résouts les conflits potentiels (pour git, il écrit directement dans le fichier les passages anciens et nouveaux séparés par des "<<<<<<<<<<<<<<<<<<<", "=================" et ">>>>>>>>>>>>>>>>" si je me rappelle bien)
_ je commit quand les conflits sont résolus (commit)
_ je pousse mes modifications sur le serveur en question (push)

Bon, en fait, on peut tirer le code d'un serveur sur lequel on a pas le droit d'écrire, c'est uniquement le push qui nécessite ce droit, mais j'ai voulu faire au plus simple.

Le reste des subtilités viens surtout du fait que les DVCS ont intégré d'autres mécaniques non-spécifiques au fait d'être décentralisés: cherry-picking, branches, tags,... directement dans le logiciels, plutôt qu'avoir des dossiers pénibles à synchroniser (dans le cas des branches, je ne maîtrise pas le reste, je connais juste de nom) comme c'est le cas habituellement avec SVN.

Les tags sont gérés... comme de simples tags associés à un commit. Moi je m'en sers pour les versions, mais j'imagine qu'une branche serait plus appropriée si on a une politique de correction des bogues des versions publiées.

Ensuite, le trunk est souvent simplement la branche "master", voire "experimental", tandis que les branches (les sous-dossiers du dossier "branch") implémentant, par exemple, l'ajout d'une fonctionnalité qui pourrait tout péter ont leur branche propre.

SVN pourrait très bien avoir intégré ce mode de fonctionnement, ça aurait été assez agréable, car c'est beaucoup plus simple de synchroniser les branches lorsqu'elles sont gérées par le VCS plutôt que de devoir les gérer à coup de diff, meld, ou autres winmerge... mais j'insiste: ça n'a rien à voir avec le fonctionnement décentralisé, c'est juste que les auteurs de DVCS ont estimé cette fonctionnalité intéressante. Un VCS pourrait le faire aussi (et à mon sens, ils devraient... quoique, je les considère obsolète donc je m'en moque un peu ;) )

La seule chose qui pourrait me faire utiliser à nouveau un VCS centralisé, c'est mon patron. Maîtriser GIT est complexe, mais heureusement, il n'y a pas besoin de le maîtriser pour être capable de faire des choses qui sont difficiles et/ou lentes avec SVN. La maîtrise viens à l'usage, et permets juste de régler des cas particuliers.
08/05/2013, 10h49
Philippe Bastiani

N'utilisant pas VS je ne pourrais m'exprimer sur cete extension... Sachez, que pour SSH, il existe GitExtensions qui fonctionne en Standalone ou plugin VS ! La solution est moins PRO mais fonctionne en SSH et aussi avec GitHub pour la gestion des Repos...

a+
Philippe
17/07/2013, 16h58
stailer

@Freem : merci pour les explications et le process, ça a répondu à une question que je me posais : pourquoi on commit pas direct sur le serveur. Donc "c'est le but" si je comprends bien.

Sinon j'ai testé l'extension en installant Bonobo Git Server sur un serveur distant et j'en suis très satisfait.

L'un des avantages que je vois au niveau du système de fichier, c'est le fait de ne pas avoir tout un tas de répertoire ".svn" (si on utilise SVN) qui polluent le projet.
Certes on peut faire un "Export" avec svn mais il faut reconnaitre que GIT est bien plus pratique de ce côté là.

Pour en revenir au push sur le serveur, là aussi, j'y vois l'avantage de pouvoir "commit" sans pour autant publier ce que j'ai fait. Très pratique.
17/07/2013, 17h15
tomlev

Citation:

Envoyé par stailer

L'un des avantages que je vois au niveau du système de fichier, c'est le fait de ne pas avoir tout un tas de répertoire ".svn" (si on utilise SVN) qui polluent le projet.

Depuis Subversion 1.7 (je crois) il n'y a plus qu'un seul répertoire .svn, à la racine de la working copy. Mais bon, ça ne suffit pas à rattraper le retard de SVN sur les DVCS...