• 2 heures
  • Moyenne
Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Introduction du cours

Bienvenue dans ce cours dans lequel je vais vous présenter EGit, un plug-in Eclipse qui ajoute le support de Git. Nous verrons pourquoi il peut être intéressant de l’utiliser, comment l’installer et comment s’en servir.

Bien sûr, étant donné qu’EGit est basé sur Git il est recommandé de connaître cet outil pour pouvoir suivre ce cours avec un minimum de confort. Mais pour ceux qui n’ont toujours aucune idée de ce que je raconte, ne vous inquiétez pas, nous allons faire un petit rappel d’introduction. Et qui sait, peut-être qu'après avoir découvert cet outil puissant dont vous ignoriez l'existence jusqu'ici, vous ne pourrez plus vous en passer ! Pour les autres, assurez-vous d’avoir Eclipse à portée de clic, nous allons rapidement nous en servir. ;)

Quelques rappels concernant Git

Avant de parler d’EGit, nous allons rappeler brièvement ce qu’est Git et à quoi ça sert. Toutefois, je ne vous apprendrais pas à l’utiliser, pour plus de détails je vous renvoie donc vers le cours de Mathieu Nebra. Encore mieux, vous pouvez aller lire le guide officiel, d’autant plus que pour une fois ils ont fait l’effort de le traduire en plusieurs langues, y compris le français !

Pour ceux qui sont toujours là, rendez-vous au prochain sous-titre pour avoir un aperçu de Git.

Git, à quoi ça sert ?

Un outil intelligent

Git est ce qu’on appelle un outil de gestion de versions (Version Control Software en anglais). D'après Wikipédia :

« Un logiciel de gestion de versions agit sur une arborescence de fichiers afin de conserver toutes les versions des fichiers, ainsi que les différences entre les fichiers. »

Si ce n'est pas assez clair je vous invite à lire l’article complet qui explique un peu plus le fonctionnement et l'utilité d'un tel outil.

Pour ceux qui connaissent SVN (également appelé Subversion), le principe est le même bien qu'il existe quelques différences fondamentales sur lesquelles je ne m'attarderais pas ici. La seule chose que je peux vous dire, c’est de ne pas vous fier aux termes communs à ces deux DVCS, puisqu’ils n’ont pas la même signification pour les deux.

Un concept familier

Toutefois, même si vous ne connaissez ni Git ni SVN ni aucun autre outil de gestion de versions, vous en avez sûrement déjà utilisé sans même le savoir ! :D Hé oui, il faut savoir que Dropbox ou encore Google Drive utilisent un système similaire. Par exemple sur Dropbox il est possible de voir les « Versions précédentes » d'un fichier et de le restaurer à un état antérieur. Git c'est à peu près ça, mais en plus complet.

D’ailleurs peut-être que vous avez déjà entendu parler de sites comme BitBucket ou le très populaire GitHub. Ce sont en fait des plateformes qui vous permettent de sauvegarder des projets qui utilisent Git dans le “cloud” comme on dit. Nous verrons comment faire un peu plus loin.

Maintenant que nous avons vu en substance à quoi servait Git, nous allons voir les différentes façons de l'utiliser.

L'invite de commande

Vous l’aurez compris, Git c’est génial. Cependant, il y a un petit détail qui risque de refroidir les moins chevronnés d’entre vous, je veux parler de ça (âmes sensibles s'abstenir) :

git init
git add README.md
git commit -m "Commit du fichier README.md"
git fetch core
...

(Au cas où, le numéro des urgences est le 112)

Et là je perçois la déception qui envahit certains d’entre vous et je vous comprends, car moi aussi j’y étais allergique quand j’ai commencé la programmation et cela a duré un bon moment. Mais avant de partir, je vous conseille de terminer la lecture de ce chapitre, juste au cas où. ;)

Bon, donc si je comprends bien Git n’a pas d’interface ?

Celle-ci en est une. :) À la base Git a vu le jour sur Linux et s’utilise donc en mode “texte”.

Les inconvénients

Toutefois, il faut avoir l'habitude d'utiliser l’invite de commande pour que ce ne soit pas une source de perte de temps, ce qui implique de se souvenir des différentes commandes. Et pour être honnête, même quand on l'utilise régulièrement, ce sont souvent les mêmes commandes qui reviennent. Il arrive donc qu'on ait à en utiliser une dont on ne connaît pas la syntaxe exacte. L'invite de commande n'est donc pas du goût de tout le monde.

Malgré tout, je ne peux que vous encourager à faire l'effort et à tenter l'expérience. Vous verrez qu'une fois qu'on a pris l'habitude, on est beaucoup plus rapide au clavier qu'à la souris.

Bon, mais ne soyez pas déçus, je ne vous ai pas encore tout dit ! :p Il existe évidemment des solutions permettant d’utiliser Git en mode graphique et c’est ce dont nous allons parler tout de suite.

Outils graphiques pour Git

Techniquement l’invite de commande est une interface graphique, je vous l’accorde. Mais en général quand on parle d’interface graphique on parle de fenêtres, avec des boutons, des listes déroulantes, etc. c'est à dire une utilisation plus axée sur la souris que le clavier.

Comme je ne connais pas par coeur le nom de tous les outils permettant d’utiliser Git en mode graphique, je vais me contenter de vous renvoyer sur cette liste non exhaustive d’outils graphiques existants. Une autre liste, beaucoup plus fournie, est également disponible ici.

Toutefois, ne pensez pas qu’une interface graphique est plus pratique à utiliser qu’une invite de commande simplement parce qu’elle est plus jolie. Certes, vous échappez au fait d’avoir à apprendre les commandes texte par coeur, mais vous vous retrouvez quand même face à quelque chose que vous ne connaissez pas.

C'est-à-dire ?

Quelle que soit l’application que vous utiliserez, vous devrez vous familiariser avec son interface ! Il vous faudra par exemple connaître l’emplacement des différentes fonctionnalités, supporter les temps de chargement, faire face à d’éventuels bugs graphiques… Il y aura donc quand même une phase d’apprentissage.

Un autre inconvénient, c’est que toutes ces solutions ne sont pas gratuites. Toutes ne sont pas non plus disponibles sur tous les systèmes d’exploitation. De plus, certaines nécessitent évidemment d’être administrateur sur son ordinateur pour être installées, ce qui n’est pas toujours le cas. Mais ce n’est pas tout.

Les inconvénients

Prenons le cas d’un développeur que nous appellerons Bob. Bob est malin et comme Bob est malin il utilise Git comme outil de gestion de versions.

Comme tout développeur le sait, développer une application (ou un site web ou ce que vous voulez) prend généralement du temps et implique donc de nombreuses modifications du code. De plus, pour tirer parti de Git au maximum, il faut commiter régulièrement pour bien séparer les modifications les unes des autres et ainsi procéder étape par étape lors du développement. Cela permet notamment d’éviter les conflits lorsque vous devez fusionner plusieurs bouts de code développés séparément.

Cependant, comme Bob est développeur, Bob est aussi un peu feignant sur les bords. Comprenez par là que s'il peut coder autant en faisant moins d’efforts, il ne va pas hésiter une seconde. Et cela passe par l’utilisation des bons outils. Et justement, Bob utilise une magnifique application graphique pour gérer ses dépôts Git. Mais ce qui dérange Bob, c’est qu’il passe son temps à faire l’aller-retour entre Eclipse et l’application, ce qui lui fait perdre énormément de temps. De plus quand il modifie son code, les changements ne sont pas pris en compte en temps réel dans l’autre application, ce qui l’oblige à lui demander de se rafraîchir.

Enfin, Bob n’aime pas l’ergonomie de l’application : il y a trop d’écrans à parcourir, trop de clics à faire pour de simples actions comme voir l’historique des commits, la liste des dépôts, les différences au niveau du code… Bob aimerait quelque chose de plus simple.

Bon venons-en au fait, qu'est-ce que tu proposes ?

Heureusement il y a une solution et celle-ci s’appelle EGit. Mais je ne vous en dis pas plus, car c’est ce dont nous allons parler dans le prochain chapitre. ;)

Lexique de base de Git

Si vous avez lu les sections précédentes vous avez dû remarquer que j’utilisais des termes un peu bizarres comme commit, dépôt etc. o_O Ce sont en fait des termes techniques spécifiques à Git. Étant donné que je ne vais pas tous les détailler à chaque fois, voici une liste non exhaustive des termes que vous allez rencontrer le plus souvent, que ce soit dans ce cours ou dans le reste de votre vie de développeur. Certains termes moins courant seront détaillés sur le tas.

Commit

Un commit est un enregistrement de l'arborescence d’un dossier et du contenu de chaque sous-dossier et fichier à un instant t. Une succession de commits constitue ce qu’on appelle l’historique des commits.

Dépôt

Un dépôt est un dossier qui porte le nom .git. C'est là que Git va stocker toutes les informations en rapport avec votre projet comme la liste des commits effectués, la liste des branches, etc.

Étant donné que c’est un dossier, rien ne vous empêche de le partager avec d’autres personnes. Même si vous ne leur fournissez que le dépôt et pas le contenu du projet (un code source par exemple), elles auront accès comme vous à l’historique des commits et Git sera capable de restaurer n’importe quel fichier depuis un point dans cet historique.

Branche

Une branche peut être vue comme une déviation de votre projet. Cela permet par exemple à plusieurs personnes travaillant sur un même projet de développer des fonctionnalités différentes sans que leurs modifications respectives ne créent de conflits. Un même commit peut ainsi faire partie de plusieurs branches s'il est le point de départ de celles-ci.

En pratique, imaginez que vous travailliez sur une application et que vous venez juste de publier la version 2.3. Le code de cette version se trouve dans une branche appelée master, la branche principale. Vous commencez alors à travailler sur la version 2.4 avec votre équipe. Chacun crée donc une branche à partir du dernier commit de la branche master pour avoir la version la plus récente du code. Lorsque vous déciderez de livrer la version 2.4, vous allez fusionner les branches de chaque membre de l’équipe dans master, puis repartir du dernier commit pour développer la version 2.5, et ainsi de suite (la fusion est appelée merge).

Push

Push (pousser) est l’opération qui consiste à envoyer le contenu de son dépôt sur un autre dépôt situé généralement sur une machine distante comme un serveur, de façon à pouvoir le récupérer plus tard depuis une autre machine. Cela permet également à plusieurs personnes de posséder une copie des fichiers sur sa machine ainsi que d’une copie en ligne à partir de laquelle chaque membre peut contribuer. Mais cela implique de pouvoir récupérer les modifications des autres pour ne pas les écraser. :D

Pull

Pull (tirer) est donc l’opération qui permet de récupérer le contenu d’un dépôt distant dans son dépôt local.

En pratique, cette opération est en fait la succession de deux autres actions : fetch puis merge (déjà vu plus haut).

Tag

Un tag est une étiquette que vous attachez à un commit de façon à l’identifier. Les tags peuvent être très utiles, ne serait-ce que pour garder trace de l’avancement de vos projets.

En pratique c’est une simple chaîne de caractères. Vous pouvez ainsi donner des noms aux commits les plus importants. Par exemple si on reprend les versions du système Android, on aura un tag Ice Cream Sandwich, un tag Jelly Bean et ainsi de suite. Vous pouvez également utiliser un numéro de version si vous le souhaitez (4.0, 4.1...), c’est d'ailleurs l’utilisation la plus courante.

Les tags sont uniques, vous ne pouvez donc pas en créer deux avec le même nom, ce qui de toute façon n’aurait pas beaucoup de sens.

Voilà, maintenant vous êtes bien équipés pour suivre le reste de ce cours ! :)

Partons à la découverte d’EGit

Tout d’abord, permettez-moi d’expliquer à ceux qui dorment au fond de la classe la différence entre Git et EGit.

Git, comme je vous l’ai expliqué dans la première partie, est un outil de gestion de version. Si vous ne voyez pas de quoi je vous parle je vous invite à la relire, car je ne reviendrais pas sur cette explication.

EGit quant à lui, est simplement un plug-in pour Eclipse, qui fournit une interface graphique pour utiliser Git directement depuis l’IDE.

Voyons plus en détails de quoi il s’agit.

Faisons les présentations

Vous l’aurez compris en lisant les chapitres précédents, l’avantage des interfaces graphiques est qu’elles sont visuellement plus attirantes, elles sont donc plus adaptées au grand public. Cependant, vous, vous êtes développeur, vous avez donc surtout besoin d’outils performants et pratiques à utiliser. De plus, si vous utilisez un Environnement de Développement Intégré (IDE en anglais) comme Eclipse ou NetBeans, vous vous attendez justement à avoir tous vos outils au même endroit et pas fragmentés entre plusieurs applications.

Et justement, l'outil que je vais vous présenter, EGit, est un simple plug-in pour Eclipse qui vous permet d'utiliser Git dans vos projets directement depuis l'IDE.

Petit rappel des avantages d’EGit par rapport aux applications graphiques tierces :

  • Pas d’aller-retour entre Eclipse et une application tierce. Votre IDE préféré contient tous les outils nécessaires. Un sous-menu ainsi que des raccourcis (à ajouter manuellement) et plusieurs vues vous permettent de l’utiliser facilement.

  • EGit est totalement gratuit et fonctionne sur toutes les plateformes (il est basé sur JGit, une implémentation Java de Git).

  • En tant que plug-in et comme Eclipse est portable, il ne nécessite pas d’installation comme pour un programme Windows par exemple, donc vous pouvez l’utiliser même si vous n'êtes pas administrateur.

  • Contrairement à certaines applications graphiques, EGit ne vous impose aucune contrainte, que ce soit quant à l’emplacement des dépôts sur votre machine, au nombre de dépôts distants, etc. Rien ne vous empêche d’avoir plusieurs espaces de travail (workspaces) avec des dépôts distincts, vous êtes libres !

Le gain de temps n'est donc pas négligeable. Vous pouvez donc, en quelques clics, voir les anciennes versions de votre code (checkout), annuler vos derniers commits (reset), consulter l'historique de vos commits (glog), et même l'historique récent d'enregistrement de chaque fichier (chaque fois que vous appuyez sur CTRL
+S
) et pleins d'autres trucs qui boostent votre productivité et vous donnent presque envie de vous lever le matin pour aller travailler. :D

Et là, vous vous rappelez pourquoi Eclipse est votre IDE préféré, ou alors vous vous demandez pourquoi il ne l'est pas encore… :-° Mais trêve de blabla, rentrons dans le vif du sujet. La première chose que nous verrons est comment installer EGit !

Installation d'EGit pas à pas

Ici nous allons voir comment installer EGit dans Eclipse. Ne vous inquiétez pas, c'est très simple et si vous avez une version récente d'Eclipse il se peut même qu'il soit déjà installé. Les manipulations qui suivent vont vous permettre de le savoir.

Premièrement, lancez Eclipse si ce n'est pas déjà fait. Dans la barre de menu, cliquez sur le menu Help, puis sélectionner Install New Software... :

Sélectionner
Sélectionner "Install New Software..."

Une nouvelle fenêtre va s’ouvrir. Tout en haut de celle-ci vous pouvez voir une liste déroulante avec un bouton Add... à sa droite. Déroulez la liste et sélectionnez l'élément dont le nom, au début de la ligne, est celui de votre version d'Eclipse. Par exemple si vous utilisez Eclipse Indigo sélectionnez la ligne Indigo – http://download.eclipse.org/releases/indigo :

Sélectionner l'URL qui correspond à votre version d'Eclipse
Sélectionner l'URL qui correspond à votre version d'Eclipse

Eclipse va ensuite charger la liste des plug-ins disponibles pour votre version et vous l'indiquer par un message Pending... dans la zone principale de la fenêtre.

Une fois que la liste s'affiche, déroulez l'élément Collaboration et vous devriez apercevoir un élément nommé Eclipse EGit. Si l'icône à sa gauche est grisée (comme sur l'image), le plug-in est déjà installé, sinon cochez la case et appuyez sur Next :

Les dernières versions d'Eclipse sont livrées avec EGit pré-installé
Les dernières versions d'Eclipse sont livrées avec EGit pré-installé

Une fois l'installation terminée, Eclipse va vous demander si vous voulez le redémarrer, faites le (bouton Restart Now).

Si vous êtes arrivés ici sans problème c'est que vous avez EGit d'installé et que vous êtes prêts à l'utiliser. À partir de là il y a plusieurs possibilités :

  • Vous voulez simplement utiliser Git en local.

  • Vous avez un projet déjà existant dans Eclipse et vous voulez pusher (envoyer) son contenu sur un dépôt distant hébergé sur GitHub.

  • Vous voulez importer un projet hébergé sur GitHub.

Nous allons voir comment procéder dans ces trois cas, sachant que le deuxième cas requiert de commencer par créer un dépôt local (cas n°1).

Créer un dépôt local

Dans cette partie nous allons voir comment créer un dépôt local pour votre projet, dans lequel Git stockera toutes les informations qui concerneront le suivi de l’état de vos fichiers.

Commencez par faire un clic droit sur votre projet et dans le menu Team, sélectionnez Share Project... Vous arrivez sur une fenêtre où il se peut qu'on vous propose plusieurs gestionnaires de versions, dans notre cas c'est évidemment Git qui nous intéresse.

Si cette liste apparaît, séléctionnez Git
Si cette liste apparaît, séléctionnez Git

Vous arrivez ensuite sur la fenêtre suivante :

Vous pouvez relier votre projet à un dépôt existant ou en créer un
Vous pouvez relier votre projet à un dépôt existant ou en créer un

La fenêtre se divise en plusieurs parties :

  • En rouge : vous permet de relier votre projet à un dépôt Git local déjà existant (liste déroulante) ou d'en créer un (bouton Create...);

  • En vert : le dossier où se situe le dépôt sélectionné juste au-dessus;

  • En bleu : vous permet de rattacher plusieurs projets à un même dépôt en les plaçant chacun dans un sous-dossier;

  • En jaune : affiche des informations concernant votre projet.

Tout ceci est utile si vous voulez que le dépôt soit situé en dehors de votre workspace (ou espace de travail) Eclipse. Par exemple si vous voulez que tous vos projets Git soit situés dans un dossier différent de celui des projets pour lesquels vous n'utilisez pas Git. Si vous choisissez cette solution, EGit va automatiquement déplacer votre projet (le dossier et son contenu) à l'emplacement du dépôt que vous aurez choisi dans la partie rouge de la fenêtre.

Ici nous allons aborder la manière simple et rapide en créant le dépôt à la racine de notre projet, ce qui signifie que le dossier .git sera situé non à côté du dossier de notre projet, mais à l'intérieur de celui-ci. Les modifications effectuées en dehors de ce dossier ne seront donc pas visibles pour Git. Cette solution est plus adaptée si vous souhaitez garder votre projet à son emplacement actuel.

Une fois que vous aurez terminé d'admirer cette magnifique fenêtre, cochez la case Use or create repository in parent folder of project. Ensuite, sélectionnez votre projet et EGit génèrera automatiquement le chemin du dépôt.

Sélectionnez votre projet et Eclipse génèrera le chemin du dépôt pour vous
Sélectionnez votre projet et Eclipse génèrera le chemin du dépôt pour vous

Appuyez ensuite sur Create Repository puis sur Finish. Attendez quelques secondes et quelque chose devrait apparaître à droite du nom de votre projet qui ressemble à ça :

Notre dépôt
Notre dépôt "Test" ne contient aucun commit (NO-HEAD)

La première partie est le nom du dépôt local auquel est « attaché » votre projet. Dans mon cas le dépôt s'appelle Test, comme mon projet. Le NO-HEAD signifie littéralement “pas de HEAD”. Il s’agit d’une référence qui pointe sur le commit (enregistrement) sur lequel vont se baser les prochaines modifications qui seront effectuées. Comme on vient de créer notre dépôt, il n’y a aucun commit et donc HEAD ne pointe sur rien.

Nous allons régler ça tout de suite en effectuant un premier commit. Pour cela faites un clic droit sur votre projet, puis dans Team (vous remarquerez que le contenu du menu a changé) sélectionnez Commit... Vous arrivez sur cette fenêtre :

Cette fenêtre vous permet d'effectuer vos commits
Cette fenêtre vous permet d'effectuer vos commits

La zone de texte vous permet d'indiquer les changements que vous avez effectués. Il faut savoir que la première ligne est en fait le titre de votre commit, c'est-à-dire ce que vous verrez quand vous parcourrez la liste de vos commits (en local ou sur GitHub). Le reste de la zone vous permet de fournir plus de détails sur les changements effectués, si besoin.

Les deux champs en dessous vous permettent d’indiquer l'auteur des modifications (Author), et la personne qui les a commitées (Committer) si ce n’est pas la même. Dans notre cas mettez simplement votre nom/pseudo avec votre e-mail si ça vous chante (ou si vous avez peur de l'oublier...).

La dernière partie de la fenêtre vous affiche la liste des fichiers ajoutés/modifiés/supprimés... Dans mon cas il y a trois fichiers “inconnus”, c’est-à-dire qui ne sont pas présents dans l’index. Comme vous ne pouvez pas effectuer de commit si aucun fichier n'est sélectionné, on les sélectionne.

Il faut savoir que si vous choisissez de ne pas committer certains fichiers (ceux du dossier bin par exemple), EGit vous les affichera quand même à chaque commit. Pour éviter ça vous pouvez faire un clic droit dessus puis TeamIgnore. Vous pouvez également éditer directement le fichier .gitignore à la racine de votre dépôt en plaçant une règle par ligne (plus d’informations sur la doc et sur l’aide de GitHub). L’équipe de GitHub a d’ailleurs créé un dépôt contenant une liste de fichiers .gitignore recommandés par langage de programmation ainsi qu’une autre par éditeur.

Une fois que vous avez choisi les fichiers que vous voulez committer, appuyez sur Commit. Une fenêtre va ensuite apparaître pendant que le commit est effectué, puis disparaître.

Félicitations, vous avez maintenant relié votre projet à un dépôt Git local et effectué un premier commit de votre projet ! :) Peut-être que vous avez trouvé ça compliqué, mais en fait ça ne l'est pas du tout (si si je vous assure ! ^^) et si vous répétez la manip 2/3 fois vous allez voir que vous allez vite piger le truc.

Vous suivez toujours ? J'espère que oui, car la prochaine étape sera d'envoyer notre projet sur GitHub, histoire de pouvoir le partager avec le reste du monde ! Bien sûr cette étape est facultative et si vous avez prévu d'utiliser Git uniquement en local vous pouvez vous arrêter là.

Envoyer son projet sur GitHub

Ajouter un dépôt distant

Premièrement, vous devez avoir un dépôt local pour votre projet. Si ce n'est pas le cas je vous conseille de suivre les instructions de la section précédente. Vous devez également avoir un compte sur GitHub et avoir créé un dépôt dans lequel nous allons pusher notre dépôt local et son contenu.

Dans la barre de menu aller dans Show ViewGit Repositories (si jamais vous ne trouvez pas choisissez Other...GitGit Repositories).

Sélectionnez l'élement
Sélectionnez l'élement "Git Repositories"

Une nouvelle vue devrait apparaître quelque part dans la fenêtre. Celle-ci contient la liste de vos dépôts. Déroulez celui dont vous voulez envoyer le contenu sur GitHub, faites un clic droit sur RemotesCreate Remote... puis dans la fenêtre qui apparaît cochez Configure fetch et choisissez origin comme nom.

"Create Remote" permet de lier un dépôt distant à notre dépôt local

Et pourquoi on ne l’appelle pas GitHub ?

La raison pour laquelle je n’ai pas choisi GitHub comme nom est que par défaut Eclipse nomme les dépôts distants origin, mais vous pouvez mettre ce que vous voulez. Si vous décidez de mettre autre chose, retenez ce nom, nous en aurons besoin un peu plus tard.

Dans la fenêtre qui s'ouvre cliquez sur Change... pour faire apparaître une autre fenêtre. Dans le champ URI collez l'adresse de votre dépôt GitHub, par exemple https://github.com/<username>/Test.git (remplacez <username> par votre pseudo GitHub). Ensuite, saisissez votre nom de compte GitHub ainsi que votre mot de passe, cochez la case Store in Secure Store et finalement cliquez sur Finish.

Félicitations ! Vous venez de donner à Git l'adresse de votre dépôt distant.

Si vous utilisez Eclipse Juno la liste des branches à récupérer devrait s'ajouter automatiquement dans le champ de texte situé un peu plus bas. Contrairement à Juno, Indigo ne le fait pas automatiquement, il faut donc faire manuellement le lien entre les branches du dépôt distant et les branches de notre dépôt local. Nous allons simplement lui indiquer que les branches de notre dépôt local seront les mêmes que sur le dépôt distant (branche locale master pour branche distante master etc.). Pour cela cliquez sur le bouton Edit (Advanced)... et une nouvelle fenêtre apparaît (oui encore une !). Cliquez sur Add All Branches Spec et cochez la case Save specifications in 'origin' Configuration. Ensuite, cliquez sur Finish.

Force Update vous autorise à réécrire l’historique de vos commits même si ceux-ci ont déjà été envoyés sur GitHub. Imaginons que vous avez effectué deux commits A et B dans votre projet et que vous les avez envoyés sur GitHub. Si vous décidez de modifier (amend) B, le commit B dans votre dépôt local ne sera plus le même que le B sur GitHub. Appelons C la modification de B dans votre dépôt local. Si vous essayez de faire un push, vous aurez une erreur vous disant que l’opération n’est pas Fast-Forward. Cela signifie simplement que C n’est pas basé sur le dernier commit envoyé sur le dépôt distant, c’est-à-dire B. Effectivement c’est le cas puisque C est censé le remplacer, pas lui faire suite. C’est une protection contre les réécritures involontaires. Dans ce cas il faut forcer l'écrasement du dépôt distant en cochant cette case.

Save specifications in 'origin' Configuration indique à EGit que vous voulez que ce dépôt soit votre dépôt « principal » pour ce projet (vous aurez moins de clics à faire pour effectuer vos push/pull).

Enfin, cliquez sur Save.

Intéragir avec le dépôt

Arrivé à ce point, nous avons :

  • Un dépôt local pour notre projet;

  • Indiqué à EGit l'adresse de notre dépôt distant pour ce projet

Toutefois, nous ne pouvons pas encore faire de push ni de pull, car nous n'avons pas encore interagi avec notre dépôt distant, du coup EGit ne connaît pas son contenu (branches, commits...). Si vous essayez de faire l'un ou l'autre vous risquez de vous retrouver avec une jolie erreur.

Toujours dans la vue Git Repositories, dans votre dépôt, déroulez l'élément Local de l'élément Branches. Vous devriez avoir quelque chose comme ça :

La liste des dépôts distants se trouve sous l'élément
La liste des dépôts distants se trouve sous l'élément "Remotes"

Encore une fois la procédure va dépendre de votre version d'Eclipse. La manipulation est plus simple sur la version Juno, plus récente.

Eclipe Juno

  • Faites un clic droit sur la branche Local/masterConfigure Branch...

  • Pour Upstream Branch choisissez refs/heads/master et pour Remote choisissez origin (ou le nom que vous avez choisi tout à l'heure), puis cliquez sur Ok.

  • Ensuite, faites un clic droit sur votre projet → TeamPull puis Push to Upstream... et c'est tout !

Eclipse Indigo

  • Clic droit sur votre projet → TeamFetch from Upstream...

  • TeamMerge puis choisissez Remote Trackingorigin/master.

  • Ensuite, faites un clic droit sur votre dépôt → Properties.

  • Cliquez sur New Entry... puis rentrez branch.master.merge pour Key et refs/heads/master pour Value.

  • Ajouter une seconde valeur avec branch.master.remote pour Key et origin pour Value.

  • Cliquez sur Apply puis sur Ok.

  • Clic droit sur votre projet → TeamPush to Upstream...

Et voilà ! Nous avons interagi pour la première fois avec notre dépôt distant et nous avons indiqué à EGit que la branche master sur le dépôt distant correspond à la branche master de notre dépôt local. À partir de maintenant, Eclipse vous indiquera le nombre de commits effectués sur cette branche qui n'ont pas été pushés sur le dépôt distant (et inversement si jamais la branche distante contient des commits que vous n’avez pas récupérés en local) :

Notre dépôt local
Notre dépôt local "Test" contient un commit sur la branche "master" qui n'a pas été envoyé sur notre dépôt distant

Vous pouvez maintenant utiliser Git dans votre projet en local et interagir avec un dépôt distant. En clair, vous êtes parés à coder !

Importer un projet hébergé sur GitHub

Dans cette partie, nous verrons comment cloner un dépôt distant puis, s’il contient des projets, comment les importer dans Eclipse. Les pré-requis sont :

  • Avoir Eclipse avec EGit d'installé;

  • Avoir un dépôt sur GitHub à cloner.

Cloner le dépôt

Dans la barre de menu d'Eclipse, cliquez sur FileImport...GitProjects from Git. Dans la fenêtre qui apparaît, choisissez URI puisque notre projet se trouve sur un dépôt distant. Vous arrivez sur la fenêtre suivante :

Les informations à renseigner concernant le dépôt distant
Les informations à renseigner concernant le dépôt distant

Dans le champ URI saisissez l'URL de votre dépôt GitHub, par exemple https://github.com/zozor/Test.git puis renseignez votre nom de compte GitHub et le mot de passe associé, cochez la case Store in Secure Store et cliquez sur Next. EGit va maintenant se connecter au dépôt distant, récupérer la liste des branches et vous les afficher dans une nouvelle fenêtre :

Si le dépôt est vide il n'y aura qu'une seule branche
Si le dépôt est vide il n'y aura qu'une seule branche "master"

Sélectionnez les branches que vous voulez voir apparaître dans votre dépôt local. Choisissez ensuite le dossier dans lequel vous voulez que EGit clone ce dépôt ainsi que la branche à cloner. Personnellement j'ai choisi de cloner la branche principale master et d'importer le projet dans mon espace de travail où sont stockés mes autres projets.

Choisir un dossier vide où le dépôt distant sera cloné ainsi que le nom que vous voulez donner à ce dernier
Choisir un dossier vide où le dépôt distant sera cloné ainsi que le nom que vous voulez donner à ce dernier

Cliquez ensuite sur Next. À ce moment Eclipse va créer le dossier à l'emplacement indiqué et y copier le contenu de la branche sélectionnée. Une fenêtre devrait ensuite s'ouvrir, qui va nous servir à importer le(s) projet(s) depuis notre dépôt fraîchement cloné.

Importer le(s) projet(s)

Un dépôt ne contient pas forcément un seul projet. Rappelez vous que pour Git, il n’y a pas d’histoire de projet, pour lui ce ne sont que des fichiers dont il doit sauvegarder le contenu quand on lui demande. Vous pouvez donc y mettre ce que vous voulez. Si vous décidez d’y mettre plusieurs projets, assurez-vous que chacun soit dans un dossier séparé, sinon Eclipse risque de ne pas être content.

Dans la fenêtre qui s'ouvre vous avez plusieurs choix :

  • Import existing projects

  • Use the New Project wizard

  • Import as a general project

Import existing projects

Ce choix demande à Eclipse de lister les projets trouvés dans le dépôt que nous venons de cloner. Pour que des projets soient détectés il faut qu'ils soient valides du point de vue d'Eclipse (fichier .project présent dans le dossier racine de chaque projet).

Use the New Project wizard

Ce choix demande à Eclipse de créer un nouveau projet à partir des fichiers sources trouvés dans le dépôt. Utile si vous avez un dossier src avec vos fichiers sources, mais pas de fichier .project présent.

Pour que l'importation soit correcte, à l'écran suivant vous devrez taper le nom exact (en respectant la casse) du dossier qui contient vos fichiers sources. Si vous tapez le nom correctement, Eclipse vous indiquera qu'il a détecté des fichiers sources, ce que nous voulons, et qu'il va les inclure dans le nouveau projet par un petit message en bas de la fenêtre :

Heureusement Eclipse est sympa et si vous ne tapez pas le nom exact il vous l'indiquera également par un message d'erreur :

Faites bien attention à respecter la casse pour que le nom du projet corresponde exactement à celui du dossier racine
Faites bien attention à respecter la casse pour que le nom du projet corresponde exactement à celui du dossier racine
Import as a general project

Eclipse vous importera le projet sans chercher à savoir si c'est un projet Java, PHP ou autre et donc sans configurer certains fichiers annexes comme le classpath, par exemple.

Et voilà c’est terminé ! Une fois l’importation effectuée, vous aurez votre projet visible dans Eclipse et relié au dépôt Git local que vous aurez cloné à partir de GitHub.

Ce cours s'arrête là, j'espère qu'il vous aura plu et surtout que vous aurez appris des choses (c'est le but). Si vous avez trouvé que le contenu en valait la peine n'hésitez pas à laisser un commentaire d'encouragement et à noter le cours étant donné que c'est mon premier ! Vous pouvez bien évidemment me faire part de vos critiques si elles sont constructives et qu'elles peuvent m'aider à m'améliorer. ;)

Bon codage !

Exemple de certificat de réussite
Exemple de certificat de réussite