Les développeurs habitués de Visual Studio ont généralement pour habitude d’utiliser le gestionnaire de sources fournis avec TFS (VSO, VSTS ou que sais-je). Pour la plupart nous avons vu émerger un nouvel outil, GIT, dont la popularité n’est plus à démontrer. Qu’on l’apprécie ou non, nous sommes bien obligés de faire avec et c’est tout l’objet de cet article : vous aider si besoin à prendre en main ce nouvel outil et vous permettre de réaliser les opérations basiques.

VSTS permet de versionner soit avec le gestionnaire de source habituel, soit avec GIT.

Philosophie (Hakunamatata)

Tout d’abord, voyons les différences de philosophie entre TFS et GIT : le premier a un fonctionnement connecté, alors que le second non. Cela signifie que TFS a constamment besoin d’une connexion au serveur TFS pour réaliser une opération sur les sources, alors que GIT fonctionne entièrement en local dans un premier temps. En effet, les sources d’un projet sont représentées par un repository, que l’on va cloner en local sur sa machine. Ce repository est donc présent sur une machine distante (le serveur généralement) et sur votre machine de développement.

Un repository est pour l’essentiel composé de commits. Un commit est une unité de travail (généralement considérée comme atomique) contenant une liste de modification apportée au repository. A chaque fois qu’il sera nécessaire de sauvegarder quelque chose dans le contrôle de code source, on aura recours à la création d’un commit, qui viendra s’ajouter à la liste des commits présents dans le repository de la machine courante. On pourra ensuite rapatrier (ou tirer) des commits d’un même repository d’une machine distante et y pousser ses propres commits. Lorsque l’on rapatrie des commits distants, GIT se charge de rejouer les modifications enregistrées dans ceux-ci sur le système de fichier. S’il détecte des conflits, si par exemple vous avez édité les mêmes lignes de code qu’un collègue, vous aurez la possibilité de résoudre ce conflit en produisant la version finale du fichier, que vous ajouterez dans un nouveau commit qui viendra s’ajouter aux précédents.

D’une manière générale, on peut considérer que toutes les actions visant à mettre à jour le code se font en se basant sur un repository local. On va y créer des commits et y tirer les modifications distantes. Ce n’est qu’une fois le repository local à jour par rapport au repository serveur que l’on pourra y pousser des commits supplémentaire à partager.

Nous allons voir ensuite comment se comporte ce système dans les faits.

Manipulations de bases

Toutes les manipulations à venir seront décrites de sorte à vous permettre de les réaliser en ligne de commande, et avec Team Explorer (Visual Studio). Nous partirons du principe que l’environnement est prêt pour commencer à utiliser GIT. Cela suppose donc d’avoir installé la CLI git (https://git-scm.com/) et Visual Studio (nous utiliserons Team Explorer).

Créer un repository GIT

Avant de manipuler un repository GIT, il faut commencer par s’en procurer un.

Visual Studio

L’interface Team Explorer de Visual Studio permet de lister les repositories GIT de la machine ainsi que ceux des projets d’équipes auquel vous vous êtes connecté. Elle permet aussi de créer un repository local via le bouton New :

 Celui-ci apparait ensuite dans la liste des repositories locaux, il suffit alors d’y double cliquer pour commencer à travailler dessus via Team Explorer.

Command Line

L’action init permet de créer un repository local en ligne de commande :

git init

Astuces

Pour un utilisateur non averti, il est préférable de passer par Team Explorer pour créer son repository. En effet, contrairement à la commande équivalente, Team Explorer ajoute deux fichiers très utiles aux développeurs : gitignore et gitattributes. Le premier permet d’ignorer du contrôle de code source certains fichiers, le second permet de configurer le moteur de git pour mieux gérer certains types de fichier comme les images et les fichiers de solution de sorte à ne pas perturber Visual Studio après un merge.

Si votre repository n’apparait pas dans la liste des repository locaux sous Team Explorer, vous pouvez l’ajouter avec le bouton add en renseignant son chemin sur le disque.

Cloner un projet existant

Pour rapatrier les sources d’un projet, il faut donc en cloner le repository. Une fois fait, vous pourrez de suite en éditer les fichiers, toutes les modifications apportées seront traquées et pourront être restituées au serveur par la suite.

Visual Studio

Dans Team Explorer, il faut commencer par se connecter à un projet d’équipe si l’on travaille avec VSTS, sous lequel seront lister les différents repositories. L’interface permet ensuite de le cloner directement dans un dossier local :

Comme on peut s’en apercevoir, la notion de Workspace est totalement absente (et c’est tant mieux si vous voulez mon avis).

Command Line

Pour cloner un repository avec la ligne de commande, l’action à utiliser est clone :

git clone <repository url>

Nous verrons la semaine prochaine comment créer un commit.