IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Hinault Romaric
7 commentaires

550PARTAGES

3  0 
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 %.


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.




Télécharger Visual Studio Tools for Git

Source : MSDN

Et vous ?

Utilisez-vous Git ? Que pensez-vous de son support dans Visual Studio ?
Vous avez lu gratuitement 764 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

7 commentaires
Commenter Signaler un problème
tomlev
Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 06/05/2013 à 20:14
Citation Envoyé par Hinault Romaric Voir le message
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 Voir le message
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.
1  0 
Freem
Avatar de Freem
Membre émérite https://www.developpez.com
Le 07/05/2013 à 15:19
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.
1  0 
djuju
Avatar de djuju
Membre éprouvé https://www.developpez.com
Le 06/05/2013 à 21:24
Citation Envoyé par Hinault Romaric Voir le message

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 ...
0  0 
alex_vino
Avatar de alex_vino
Membre émérite https://www.developpez.com
Le 07/05/2013 à 13:14
Microsoft sort Visual Studio Tools for Git
Sauf erreur de ma part cette extension existe depuis longtemps
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.
0  0 
Philippe Bastiani
Avatar de Philippe Bastiani
Membre éprouvé https://www.developpez.com
Le 08/05/2013 à 10:49
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
0  0 
stailer
Avatar de stailer
Membre chevronné https://www.developpez.com
Le 17/07/2013 à 16:58
@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.
0  0 
tomlev
Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 17/07/2013 à 17:15
Citation Envoyé par stailer Voir le message
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...
0  0 
Commenter Signaler un problème