Plan du site  
pixel
pixel

Articles - Étudiants SUPINFO

Utilisation de Git avec Eclipse

Par Julien PERRON Publié le 11/09/2017 à 22:12:21 Noter cet article:
(0 votes)
Avis favorable du comité de lecture

Introduction

Je vous présente ci-dessous un tutoriel concernant l'utilisation de Git avec l'ide Eclipse.

Git est un outil de versionning qui est l'un des plus utilisé dans le monde du développement. Il vous sera indispensable dans vos différentes missions et vous sauvera la vie une paire de fois !

Git est un serveur décentralisé qui vous permet de pousser vers un serveur vos données notamment le code source de votre projet en passant d'abord par le local ce qui facilite le retour arrière. Il permet également de travailler à plusieurs sur le même projet sans devoir vous emmêler les pinceaux et vous disputer pour savoir qui a causé le problème.

Je vous propose donc un tutoriel qui vous aidera à utiliser Git sur Eclipse sans passer par ligne de commande, ce qui est plutôt appreciable pour ceux qui n'aime pas tout faire par commande. Bonne lecture !

Sommaire

  1. Installation EGIT

  2. Configurer le workspace

  3. Quelques définitions

  4. Les tags

  5. Les branches

  6. Merge et Rebase

  7. Modification à ne pas intégrer dans un commit

  8. Commiter le projet

  9. Annuler un commit

  10. Envoie des modifications (Push to Upstream)

  11. Récupérer les modifications

  12. Les Patchs

  13. Liste des modifications

  14. Stash - Mise en cache (Egit à partir de la version 2.1)

  15. Conduite d'un projet

  16. Conclusion

Installation Egit

Afin de pouvoir utiliser git sur Eclipse, veuillez bien sur tout d'abord installer Eclipse puis installer le plugin eGit qui permet d’avoir l’interface graphique Eclipse pour Git :

REMARQUES

Il est possible que la version d'Egit ne soit pas compatible avec la version d'Eclipse installé. Pour cela il suffit d'effectuer les étapes suivantes :

Configurer le workspace

Configuration de la variable d'environnement HOME

Afin que le message Environment Variable HOME not set ne s’affiche plus, la variable HOME doit être configurée. Allez dans système du panneau de configuration, puis dans la fenêtre qui s’affiche choisir l’onglet avancé et cliquer sur variable d’environnement.

A cet endroit, dans la partie Utilisateur, cliquer sur nouveau :

Nom de la variable : HOME

Valeur de la variable : chemin que vous voulez. Pour ma part, j’ai choisi : %USERPROFILE%/eclipse Projects/

Activer la vue Git Repositories

Ce n'est pas obligatoire, mais elle permet d'avoir une vue d'ensemble sur tous les objets en cours et associé à ce projet.

Dans : Window > Show View > Other > Rechercher Git Repositories

Désactiver la compilation automatique

La désactivation de la compilation automatique permet d'avoir une exécution des commandes plus rapide et d'éviter certains problèmes liés à la création de nouveaux fichiers qu'il ne faudrait pas intégrer dans un commit et un push.

Pour ignorer des fichiers, une partie du document est réservé à ce thème.

Si cette fonction est primordiale, alors avant chaque commit, le clean sera obligatoire afin de ne pas enregistrer les fichiers.

Importation du projet Git

Pour importer un projet git il faut cliquer dans le menu : File > Import pour arriver à la fenêtre en dessous.

Ensuite, il faut choisir projects from Git dans le dossier Git et cliquer sur suivant.

Choisir URI et Suivant :

Remplir URI, avec la forme suivante :

Protocole://utilisateur@adresseip/chemin/Absolu/Dossier/Git

Exemple : http://jpe@8.8.8.8/appli/projet/git

Ou remplir les champs un à un pour que l'URI se remplisse automatiquement. Ensuite, cliquer sur suivant.

  • Choisir les branches concernés par le projet

  • Choisir un directory différent que le workspace du projet. On peut créer un dossier git dans ce workspace.

  • Chosir l'initial branch. C'est cette branche qui sera en local sur le poste. Les autres branches choisies précédemment permettront d'avoir une connexion en 'remote local', avec le serveur.

  • Remote name permet d'avoir la référence du serveur liée aux branches que l'on va importer. Par défaut, c'est origin. Ensuite cliquer sur suivant.

  • Il y a importation du projet. Après, choisir Import existing projects et choisir suivant.

    Chosir les dossiers à importer et cliquer sur finish.

Quelques définitions

Master : C'est la branche par défaut de Git. Elle est censée regrouper le projet de référence. Cependant, ce n'est pas obligatoire.

Fetch : Permet de récupérer la head de la branche à partir du dépot distant, er ainsi déterminer les revisions manquantes de l'historique git, et les récupérer également.

Merge : Action de fusionner le contenu d'une autre branche (pouvant provenir d'un dépôt externe) avec la branche actuelle. Si la branche provient d'un dépot différent, elle est d'abord fetch entièrement avant d'être fusionée. (A ne pas confondre avec rebase)

Rebase : Permet de créer un patch de toutes les modifications d'une branche et de les intégrer directement dans une autre branche. Le résultat de Merge et Rebase revient au même. Cependant, avec rebase, l'historique devient plus clair et permet de vérifier l'application des patchs sur des branches distantes.

Branch : On appelle branche, les modifications effectuées en parallèles des autres. Sur les schémas ci-dessous, il y a un total de deux branches : mywork et origin. En faisant un merge, ces deux branches existent toujours mais ont un nouveau commit en commun. Avec Rebase, il n'existe plus qu'une branche ce qui permet d'alléger le nombre de branche et d'avoir un historique propre.

CheckOut : Cette commande permet de se positionner sur une autre branche, référence ou tag. Il peut également nous positionner sur un ancien commit. Pour cela, c’est une commande dangereuse car après repositionnement, les commits se trouvant avant, dont généralement celui référencé par HEAD disparait de l’historique mais existe toujours. A utiliser avec prudence.

APARTE : Merge et Rebase

Mywork est la branche locale et Origin la branche distante pointant sur le même commit :

Il se peut que des conflits interviennent, alors Eclipse nous demandera de résoudre ceux-ci avant de pouvoir continuer.

Afin qu'Origin prenne en compte ces nouvelles modifications, il faudra faire un fast-forward qui permet d'avancer la référence HEAD d'Origin sur le dernier commit (crée par rebase ou merge).

DANGER

Il ne faut utiliser Rebase que sur des commits qui ne sont pas sur le serveur (non pushé). En effet, git crée de nouveau commit sur la base des anciens commits, ils n'ont donc pas la même clé et les personnes, qui, travaille sur les anciens commits devront fusionner le tout et cela deviendrait extrêmement périlleux.

Les tags

Les tags permet de baliser certains états dans l'historique qui sont importants comme une publication. Dans l'onglet historique :

Choisir le commit concerné et clique droit dessus. Une nouvelle fenêtre s'affiche :

Lorsque "Tag name" est vide, on peut voir que Existing tags liste tous les tags existants afin que le nom donné au nouveau tag soit unique."Tag message" est simplement une description du tag qui va être créé. Ensuite valider.

On peut voir qu'un nouveau tag est apparu de couleur jaune afin de différencier les références, les branches et les tags.

Pour supprimer ce tag, il suffut d'aller dans la vue Git Repositories, développer le dossier Tag et clique droit dessus et choisir push puis tag celui désiré. Si cela provoque une erreur, il faudra configurer le push manuellement. (Voir la partie Push)

Les branches

Les branches sont différentes arborescence au sein même d'un projet qui permettent à l'équipe de travailler sur le même projet mais en travaillant sur leurs propres tâches. Supposons que l’on souhaite changer de branche pour une quelconque raison : clique droit dans la vue project explorer :

Une nouvelle fenêtre s'affiche :

  • Le marqueur tick(le V) signifie sur quelle branche nous sommes positionnée actuellement.

  • dossier local correspond aux branches en local. Ici c’est la branche « initial branch » choisi lors de l’importation.

  • Références : Créer par les commandes Git, dossier qui liste toutes les références existant sur la branche actuelle : HEAD, FETCH_HEAD... En complémentaire, l'identifiant du commit où la référence est placé est inscrite à côté.

  • Remote tracking :branche du serveur sur lesquels on peut se positionner. (Correspond à toutes les branches choisies lors de l’importation).

  • Tags : liste tous les tags existants.

Tags : liste tous les tags existants.

Soit on choisit la branche sur laquelle on souhaite être, Soit on crée une nouvelle branche : Choisir le dossier concerné et cliquer sur New branch.

Création d'une nouvelle branche

En suivant le dernier point de la partie précédent (new branch), une fenêtre s’affiche à nouveau :

  • Source ref : choisir à partir de quoi l’on va crée cette branche : d’une branche déjà existante, d’une référence, d’un tag…

  • Branch name : Choisir le nom de la nouvelle branche. Le « refs/heads/ « est le chemin dans lequel sera stocké le nom.

  • Checkout new Branch : si on la tick signifie que l’on se positionnera sur cette nouvelle branche. Sinon on reste sur la branche actuelle.

Il est possible qu’Eclipse demande une stratégie : Merge, Rebase, None. Par défaut, celle-ci est à Merge.

Valider et la création ainsi que le chargement de la nouvelle branche se met en route.

Afin d’intégrer la nouvelle branche sur le serveur, il faut la pusher. Pour cela, allez dans la vue Git Repository et faire un push sur la branche en question.

Merge et Rebase

Merge et rebase après récupération des modifications sur le serveur

Pour récupérer les modifications de la branche, faire un fetch to Upstream. Cette commande ne fait que récupérer les commits sur le serveur. Si ces modifications ont été faites sur la même branche sur laquelle on travaille, alors il faut se placer sur le commit le plus récent (local ou ceux qu’on vient de récupérer) puis faire un merge ou rebase.

Merge et rebase entre plusieurs branches

Pour faire un Merge (fusion) ou un rebase (recombinaison) : se placer sur la branche qui recevra la fusion et sur le commit le plus récent puis avec : clique droit → Team → Switch to → other

Résoudre un conflit

Les conflits peuvent survenir à la suite d'un merge ou d'un rebase entre deux branches ayant modifiées les mêmes lignes sur les mêmes fichiers :

Un conflit apparaît alors.

La fenêtre ci-dessous nous montre quelle branche est en conflit. Les fichiers en conflits sont repérés avec le symbole suivant :

Ce même symbole se retrouve sur les dossiers concernés.

Afin de régler le conflit veuillez effectuer un clique droit sur le fichier en conflit puis Team → Merge Tool

Une fenêtre apparait. Choisir « Use HEAD (the last local version) of conflicting files » pour avoir une comparaison entre les deux fichiers et le conflit.

Corriger le fichier (version à gauche), sauvegarder, puis utiliser la commande add sur ce fichier.

L'icône de conflit disparait pour laisser place à l'étoile "*". En cas de conflit dû à un merge, on pourra voir "Merged Branche1". Pour terminer correctement le merge, il faut effectuer la commande commit.

En revanche, si c'est la commande rebase qui a occasionné le conflit, on pourra voir "Rebase Interactive". Pour continuer la commande rebase, choisir Team → Rebase → Continue.

Modifications à ne pas intégrer dans un commit

S'il y a modification et création de fichier à ne pas commit, alors Eclipse ouvrira une fenêtre de conflit pour un checkout, par exemple. Comme des fichiers ont eu des modifications et, n’ont pas été commité, Eclipse refuse de passer sur la nouvelle branche.

Dans ce cas, il va falloir les désindexer : choisir le dossier ou fichier à désindexer et clique droit → Team → Untrack.

La commande ignore permet de créer un fichier .gitignore qui liste toutes les exclusions. Afin que les fichiers désindexés et les exclusions soient prisent en compte, il faudra faire un commit pour spécifier au serveur que ces fichiers ne doivent plus être pris en compte.

Une fonction qui se nomme assume Unchanged permet de spécifier à Git de ne pas prendre en compte les modifications des fichiers/ dossiers choisis. Cela ne fonctionne que si les fichiers ne sont pas sur le serveur.

Commiter le projet

On inscrit en commentaire /*essai*/ ainsi qu’une classe quelconque dans le nouveau fichier java crée. Lorsque l’on commit, on peut commiter tout le projet, ou, seulement quelques fichiers. Dans ce contexte, il suffira seulement de commiter FichierTest.java.

Pour cela : clique droit sur le fichier -> Team -> commit

Une fenêtre s’affiche afin de vous demander sous quel nom et sur quel poste le commit sera associé. Pour cet exemple, userTest1 et userTest2 représentent les noms des utilisateurs.

Choisir les fichiers à commiter puis cliquer sur Commit pour accepter.

Cette icône permet de fusionner le dernier commit avec celui que l'on va faire.

L'author et le Commiter sont pré-Définis. Le premier est l'auteur des Modifications alors que le Commiter est la personne qui fait le commit.

REMARQUE

Un commit ne peut être vu que Localement.

Une bonne méthode est de commiter souvent ! Un commit est facilement annulable. S'il y a eu compilation avec Maven, ne pas oublier de faire un clean !

S’il n’y a aucun problème, les icônes des fichiers et dossier concerné disparaissent ce qui signifie que les modifications ont été prise en compte

De plus, on peut le vérifier dans l’historique en cliquant sur le dossier concerné.

On voit que le commit a bien été réalisé. De plus, des Tags on fait leur apparition devant le message du commit et entre […]. Le tag en vert pointe sur la branche actuelle. Le tag en gris, pointe sur la branche du serveur, nommé origin/branche . Origin, est le nom choisi lors de l’importation dans remote name.

Le tag HEAD est l’entête de la branche, la dernière version. Il est possible d’avoir des commit devant le tag HEAD (s’il y a checkout, les commits devant ce tag n’existeront plus)ou alors de ne pas avoir de HEAD (Ce qui causera pas mal de problème lors de commit, push et checkout).

Cependant, il vaut mieux que ce tag soit présent, sur le dernier commit.

Annuler un commit

Si le commit à annuler est le dernier de la branche, alors, je vous renvoie sur la partie Commitqui traite ce sujet.

Cependant, Si le commit a annulé n’est pas le dernier, alors il faudra commiter l’annulation. Il faut utiliser la commande Revert. Pour cela, faire : Afficher la fenêtre History et cliquer sur le commit puis sur l’onglet Revert commit.

DANGER

La commande Revert permet de revenir à l'état du commit selectionné. Cependant,, si des commits ont été effectué après, alors ils seront également annulés.

Envoie des modifications (Push to Upstream)

Un Push est une commande dangereuse car elle permet de modifier, par les commits, les fichiers du serveur se trouvant sur la branche afin que les autres utilisateurs puissent en profiter. Il faut donc être sûr que lorsque l’on push, les modifications effectuées soient correctes. Un push envoie tout le projet. Il détermine si la révision de tête (HEAD) de cette branche est un ancêtre direct.

Si c’est le cas, le push fonctionne, dans le cas contraire, un message d’erreur (non fast forward) peut être indiqué.

De plus, si une personne a push avant et que les modifications n’ont pas été prise en compte, il est fort probable que le push à envoyer ne fonctionne pas. Il faudra récupérer les modifications avant de pouvoir push. (Voir la partie d’après : récupérer les modifications).

Clique droit sur le dossier concerné :

Il est possible que le mot de passe du user soit demandé.

Donc, on a d’abord le nom de la branche puis les commits que l’on va push ainsi que les fichiers modifiés de chaque commit.

On clique sur valider et voilà les modifications peuvent être vu par les autres.

S'il y Erreur

Vérifier les informations prédéfinis et les modifier s’il y a une erreur.

Par exemple: error occurred during unpacking on the remote end: unpack-objects abnormal exit. Il faudra reconfigurer les droits sur le serveur et/ou le push manuellement : cliquez sur configure sur la fenetre d’erreur.

Un warning peut apparaitre s’il existe plusieurs branches en local sont connectées au même projet. Ce message s’affiche donc : Note that remote 'origin' is used from 1 other branches (see tooltip for a list)

Il faudra peut-être remplir à nouveau les informations de connexion au serveur via le bouton change… ou alors add… dans la partie Push URIs.

Cliquer sur add… dans la partie Ref Mapping,

Une nouvelle fenêtre s’affiche :

Remplir les champs :

  • par la branche locale qui a été modifié dans Local Branch

  • par branche du serveur à modifier dans Remote Branch

De plus, il faut cocher la case Force Update. Puis valider et cliquer sur Save and Push.

Si vous souhaitez être plus précis, alors on peut dérouler le menu Advanced et cliquez sur Edit afin d’obtenir la fenêtre suivante :

Source ref : définit ce que l’on va envoyer.

Destination ref : définit qui va recevoir les données envoyées.

Remote ref to delete : permet de supprimer une référence sur le serveur.

Add All Branches Spec : d’envoyer toutes les modifications sur toutes les branches.

Add all Tags Spec : d’envoyer toutes les modifications sur tous les tags.

Après avoir cliqué sur Add Spec, on peut remarquer que cela s’ajoute dans le tableau spécifications for push.

C’est à ce niveau que l’on pourra inclure les tags et autres.

REMARQUE

Push to uptream et Push (se trouvant dans Remote lors d’un clique droit) ont une différence. Push to upstream envoie seulement les fichiers modifiés à la branche serveur auquel la branche actuelle est associée. Tandis que Push permet de configurer ce que l’on va envoyer. Lors d’une erreur d’un push to Upstream, la configuration faite ci-dessus est en fait une commande Push. On peut donc envoyer de nouveaux tags crée, de nouvelles références…

Récupérer les modifications

Les modifications ont été faites par userTest2 et push sur le serveur. On va donc les récupérer avec userTest1.

Si le projet n’a pas encore été importé, les modifications seront directement prises en compte, dans le cas contraire, on va devoir prendre les modifications avec la commande PULL : clique droit sur le dossier concerné :

REMARQUE

La commande PULL permet de fetch (récupérer) puis merge (fusionner) les modifications qui ont été apposés sur le serveur après la version que l’on a en local.

Un mot de passe est susceptible de vous être demandé.

Après chargement des dossiers on peut voir que le commit du fichierTest a été récupérer. De plus, une mise à jour du dernier commit a été relevé par eGit.

On peut voir que dans Update Result, le résultat est Fast forward.

Ce qui signifie que l’entête de la branche a simplement changé de place : Il est passé de « conversion fin de ligne…. » au commit du fichierTest (devenu le dernier commit). Le merge Input signifie qu’il va fusionner les modifications avec le projet en local de userTest1. On clique donc sur OK.

On peut voir dans l’historique d’eclipse de userTest1 que tout a bien été récupéré.

En fait, la commande PULL réunit 2 commandes : Fetch et merge. C’est pour cela que la nouvelle référence est nommée FETCH_HEAD et non pas PULL_HEAD.

Séparation Fetch et Merge

La commande PULL est qu’il réunit 2 commandes en une, et, dans certains cas, cela peut être un inconvénient. On peut donc simplement utiliser la commande Fetch pour récupérer les nouveaux commits (qui peuvent s’entremêler avec les commits locaux). On peut donc utiliser le fetch à plusieurs reprises sans merge. Après avoir récupérer les modifications qui, théoriquement, se trouve sur la branche sur laquelle on travaille, il suffit de se positionner sur le dernier commit (le plus récent) et de merger le tout. Si tout se passe bien, sur le dernier commit se trouve les références : Head – local (surligné en vert) et serveur (surligné en gris – nommé généralement origin/XXX)

REMARQUE

La commande FETCH ne modifie en aucun cas le répertoire local.

Les patchs

On appelle patch, le stockage sur disque des différences d’un fichier/ dossier à chaque version de celui-ci. On peut l’appliquer partiellement ou totalement. Il faudra souvent faire un rebase afin de s’assurer que les patchs soient bien appliqués sur une branche distante.

Les patchs permettent pour la personne qui les applique de simplement faire un fast-forward au lieu de faire les modifications manuellement.

On peut créer un patch sur un commit, une branche, un fichier…

Dans l’exemple ci-dessous, le patch sera fait sur un commit. D’abord, on crée un nouveau commit avec un nouveau fichier, ainsi qu’une modification d’un autre fichier, d’un module différent.

On se place avec l'utiliseur userTest2 :

DANGER

ON NE CREE JAMAIS DE PATCH SUR DES MODIFICATIONS OU COMMIT DEJA SUR LE SERVEUR !

Une nouvelle fenêtre s’affiche :

Le choix dépend de comment vous désirez le stocker. Pour l’explication, on va exporter le patch dans un fichier.

On clique sur next.

Il existe 4 type de formats : None (sans format), email (envoie du patch par courriel) oneline et workspace (version Egit 2).

Afin que les modifications soient réellement prises en compte, il faudra choisir le format workspace. On laisse Lines of context à 3.

On valide. Le patch est créé.

Avec userTest1 :

Dans la fenêtre project explorer : clique droit

Ensuite on choisit le File avec le chemin de stockage du patch.

On passe à la page suivante avec Next.

On passe à la page suivante pour voir les modifications qui existe entre les fichiers.

Reverse Patch permet, au lieu d’ajouter les modifications, de les enlever.

Show matched hunks permet de voir les fichiers/dossiers appariés.

Show excluded permet de voir les fichiers locaux exclu du patch.

Dans la partie Patch Contents on peut observer ce que contient le patch.

Dans la dernière partie de la fenêtre, on peut aisément remarquer que Patched Local File est vide.Unmatched Patch Segment permet d’examiner ce que le patch inclura dans le local à l’endroit indiqué dans Patch Contents.

Plusieurs symbole figure au-dessus de la dernière partie : (dans l’ordre)

Passer à la différence suivante

Revenir à la différence précédente

Prochain changement

Revenir au changement précédent.

Dans notre exemple, on accepte toutes les modifications : on clique donc sur Finish.

Remarque

Le plugin d’Eclipse (version anterieur 2.1) fonctionne très mal pour l’application des patchs. En effet, celui-ci crée plusieurs dossiers mais ne les appliquent pas… ou très mal… Cependant, avec la version 2, le format Workspace permet une application parfaite du patch. Les nouveaux fichiers créent lors de l’application de celui-ci ne sont pas indexer, il faudra donc le faire manuellement.

Liste des modifications

Afin d’obtenir une liste claire des modifications, il faudra utiliser soit git Bash (en pointant sur le local) soit directement sur le serveur, en ligne de commande. En effet, le plugin ne permet pas d’avoir une liste concise.

Se placer dans le dossier Git du serveur et exécuter la commande suivante :

  • Git diff oldRef newRef –stat=200 > text.txt

  • oldRef = reference la plus ancienne

  • newRef = reference la plus récente

  • --stat : seulement liste de fichiers qui ont changées.

  • =200 : longueur de la largeur de chaque ligne des fichiers modifiés

  • > : import le résultat

  • Text.txt : nom du fichier qui recevra le resultat. De plus, cela peut être également un chemin

    Cela donne en plus un histogramme des modifications.

Stash - Mise en cache (> Egit 2.1)

On appelle stash la mise en cache des modifications de la branche courante. Cela permet d’enregistrer les modifications sans faire de commit, et, d’y revenir par la suite en l’appliquant.

Prenons la branche A, dite courante et, la branche B.

Des modifications ont été faites sur la branche A mais ne sont pas finis. Pour une raison quelconque, on est dans l’obligation de passer sur la branche B. Eclipse affichera une fenêtre des modifications qui pourraient se perdre et refusera de changer de branche.

Un commit pour cette situation n’est pas appropriée. Il vaut mieux faire un stash afin de mettre en cache les modifications et de passer sur la branche B.

Maintenant, on se trouve sur la branche B, on fait des modifications qui sont finis et on commit le tout. On peut donc repasser sur la branche A afin de continuer nos modifications sur celle-ci.

En repassant sur la branche A, nos modifications précédentes ne sont pas prises en compte, il faut donc restaurer la mise en cache afin de les appliquer et continuer.

Conduite d'un projet

Voici le schéma (pour une petite équipe) que les collaborateurs du projet doivent suivre afin d’optimiser leur travail.

Et les schémas suivants nous montrent une conduite d’un projet avec une équipe un peu plus grande.

Conclusion

Pour ceux qui souhaite utiliser Git en ligne de commande voici comment avoir l'exécutable git sur Windows, installer Git sur le site officiel http://git-scm.com/downloads et télécharger la version Windows. A l’installation, choisir Git bash.

Si vous souhaitez avoir plus d’informations, je vous conseille de lire le document proGit. Ce document traite de Git en ligne de commande mais permet de bien comprendre les rudiments de Git pour pouvoir utiliser le plugin. De plus, une partie de proGit traite de la conduite de projet : à partir de la partie 5.2.2 – page 121.

De plus, vous pouvez vous référer à l’adresse suivante : http://www.eclipse.org/egit/documentation/

A propos de SUPINFO | Contacts & adresses | Enseigner à SUPINFO | Presse | Conditions d'utilisation & Copyright | Respect de la vie privée | Investir
Logo de la société Cisco, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société IBM, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Sun-Oracle, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Apple, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Sybase, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Novell, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Intel, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Accenture, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société SAP, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Prometric, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Toeic, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo du IT Academy Program par Microsoft, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management

SUPINFO International University
Ecole d'Informatique - IT School
École Supérieure d'Informatique de Paris, leader en France
La Grande Ecole de l'informatique, du numérique et du management
Fondée en 1965, reconnue par l'État. Titre Bac+5 certifié au niveau I.
SUPINFO International University is globally operated by EDUCINVEST Belgium - Avenue Louise, 534 - 1050 Brussels