Table des matières
Bitbucket est un service d'hébergement de repositorys Git et Mercurial, maintenu par la société Atlassian. On peut utiliser une version limitée de ce service gratuitement. La limite étant largement au-dessus de ce que nous présentons sur cette page, vous pouvez suivre ce tutorial jusqu'au bout sans avoir à sortir votre carte bleue.
Pour plus de détails : https://fr.atlassian.com/software/bitbucket/overview.
Ce tutorial a pour objet de configurer un environnement de développement Java sous Eclipse avec Bitbucket. Quatre points sont couverts :
-
la configuration d'un repository Git sous Eclipse ;
-
la configuration d'une connexion Bitbucket sous Eclipse ;
-
la publication d'un projet Eclipse dans Bitbucket ;
-
la récupération d'un projet de Bitbucket dans Eclipse.
Ce tutorial a été rédigé avec la version Luna d'Eclipse. Il est possible que certains écrans varient avec la version actuelle.
La configuration des différents éléments peut paraître fastidieuse. Cela est normal, car elle l'est. Il y a de nombreux éléments à configurer : les différents repository Git (ici on en compte trois : un chez Bitbucket, et deux autres sur deux machines locales différentes) et pour chacun de ces repository une opération de Push et une opération de Pull.
Cela dit, cette configuration se fait une fois seulement en début de projet. Une fois tous ces éléments posés, les mouvements de fichiers source entre les repository sont très simples.
Eclipse propose le support natif de Git depuis plusieurs versions déjà. La première tâche que nous allons accomplir consiste à créer un repository Git pour un projet Java sous Eclipse. Nous créerons ensuite quelques commits dans ce repository, afin de le peupler avec quelques données de test.
On part pour cela d'un projet Java vide, sous Eclipse. Pour créer un tel projet, on pourra se référer aux tutoriaux Premiers pas avec Eclipse et Premiers pas avec son projet dans Eclipse, sur Java le soir.
La configuration initiale de notre Eclipse est donc la suivante.
La première chose que nous devons faire est de partager notre projet Eclipse dans Git. Cela se fait dans le menu pop-up du projet, option Team, puis Share project... .
Une fenêtre s'ouvre alors, proposant les deux gestionnaires de versions supportés en standard par Eclipse : CVS et Git. On pourra verser une larme de nostalgie en constatant que CVS est toujours là... Notons que le support de SVN, Mercurial, etc... existe sous forme de plugins.
La fenêtre suivante propose de choisir à quel endroit l'on souhaite créer son repository Git. Eclipse ne recommande pas de choisir le répertoire de son workspace (Eclipse) pour créer un repository Git, cela dit, c'est ce que nous allons faire ici.
On coche donc la case Use or create repository in parent folder of project. On aurait pu choisir un autre répertoire, cela n'aurait pas changé la suite de ce tutorial.
L'aspect de notre projet change dans la vue Package Explorer. Un petit cylindre orange est ajouté sur l'icône de notre projet. Ce cylindre symbolise le fait que notre projet est géré par un gestionnaire de version. Il serait également présent si ce gestionnaire était SVN ou CVS.
On constate qu'Eclipse ajoute également un chevron devant le nom de notre projet. La présence de ce chevron signale que certains fichiers de notre projet ne sont pas sous contrôle de version, ou qu'ils ont été modifiés depuis la dernière validation (commit).
Ouvrons la vue Navigator pour examiner les fichiers de notre projet. Effectivement, la vue Package explorer masque quelques fichiers, notamment les fichiers techniques qu'Eclipse utilise pour gérer les projets. On affiche cette vue de façon classique, dans le menu Windows > Show View > Navigator.
Cette vue nous montre trois fichiers cachés.
-
.projectet.classpath: fichiers techniques gérés par Eclipse. -
.gitignore: fichier technique utilisé par Git. Ce fichier spécifie les fichiers et répertoires qui ne sont pas pris en compte par Git.
Utilisons ce fichier .gitignore pour exclure les fichiers
techniques Eclipse des fichiers sous contrôle de version.
Outre les fichiers de configuration d'Eclipse, on exclut également le répertoire
bin du contrôle de version, qui contient les classes compilées de notre
projet. Ce répertoire peut être entièrement reconstitué à partir du code source,
il n'y a donc aucun intérêt à le mettre en contrôle de version.
Notons que l'on pourrait aussi exclure le répertoire target dans le cas
d'un projet Maven, et le répertoire .settings, autre élément technique
d'Eclipse.
On peut à présent commiter les fichiers appelés à être contrôlés par Git. Cette opération commit signifie que la version que l'on a sous les yeux va être enregistrée par Git, associée à un numéro particulier (code de hachage illisible) et qu'entre autres choses, on pourra y revenir plus tard.
Tout d'abord, on remarque que les fichiers ignorés par Git n'ont plus le petit point
d'interrogation qui se trouvait devant leur icône dans la vue Navigator.
Dans notre exemple, seul le fichier .gitignore est dans ce cas.
Avant de pouvoir commiter un fichier sous Git, il faut indiquer à Git qu'il doit gérer ce fichier. Cette opération consiste à ajouter ce fichier à Git (add en anglais).
Une fois un fichier ajouté, il apparaît avec un signe "+" devant son icône.
On peut alors commiter les modifications apportées à notre projet. Cela signifie que toutes ces modifications vont être envoyées vers Git, qui va les archiver dans son repository avec soin.
Eclipse nous ouvre alors une fenêtre dans laquelle nous allons pouvoir indiquer trois choses.
-
La première est un message explicatif sur cette opération de commit. Notons qu'avec Git, ce message est obligatoire. Ceci est une bonne pratique : Git nous oblige à expliquer ce que l'on fait.
-
Le nom de l'auteur de ce commit. Avec Git, pas de commit anonyme.
-
La liste des fichiers effectivement commités. On peut, pour des raisons d'organisation, distribuer une liste de fichiers à commiter dans plusieurs commits.
Une fois notre premier commit effectué notre projet à l'aspect
de la figure suivante. Le chevron devant le nom de notre projet a disparu, signe qu'il
n'a pas été modifié depuis le dernier commit. Le fichier
.gitignore qui est sous contrôle de version est également marqué par
un petit cylindre orange.
On peut apporter des modifications à notre projet, et les commiter
au fur et à mesure. Commençons par créer une classe Marin.
Notons que dans ce cas, les deux étapes de add et de commit ont été effectué en une seule passe.
Examinons notre repository
après plusieurs modifications de notre classe Marin (ajout de champs, d'une méthode
toString(), de méthodes equals() et hashCode()).
On peut pour cela ouvrir la vue History d'Eclipse, sélectionner notre projet dans la vue Package explorer (ou une autre vue équivalente), et cliquer sur le bouton Link with editor de la vue History.
L'ensemble des commits apparaît alors. Si l'on a créé plusieurs branches (ce qui n'est pas le cas dans notre tutorial), on peut les afficher en cliquant sur le bouton Show all branches.
Cette section suppose que l'on s'est déjà créé un compte sur Bitbucket et que l'on dispose d'un login et d'un mot de passe. Ce tutorial ne couvre pas la connexion à un repository en SSH, mais en HTTPS.
Rendez-vous donc sur la page de création d'un repository sur Bitbucket. Cela se fait en ligne, sur le site de Bitbucket.
On prendra garde de bien créer un repository de type Git et non pas de type Mercurial. L'exemple montre la création d'un repository privé, on peut tout aussi bien créer un repository public, bien entendu.
Une fois notre repository crée, il va nous falloir le connecter à notre repository local, celui que nous avons créé à l'aide d'Eclipse. Il nous faut pour cela obtenir l'URL de notre repository. On peut le faire sur le panneau Overview de l'IHM de Bitbucket. Dans la rubrique I have an existing project se trouve une suite de commandes dans laquelle on peut lire l'URL dont on a besoin (ligne 2).
On peut donc copier / coller cette URL magique.
On configure Eclipse pour qu'il se connecte à notre repository Bitbucket au travers de la vue Git Repository, que l'on ouvre de façon classique. Sur cette vue se trouve déjà le repository que nous avons créé précédemment, local à notre espace de travail.
En ouvrant le nœud de notre repository, on découvre un sous-nœud Remote. Sélectionnons la rubrique Create Remote... de ce nnœud Remote.
Eclipse nous demande alors le nom que nous allons donner à ce repository. Le nom par défaut, origin, a une signification particulière dans Git, on le conserve donc. C'est sous ce nom que notre repository Bitbucket apparaîtra dans la vue Git Repository.
Eclipse nous demande alors de configurer l'opération de push vers ce repository. Cette opération consiste à pousser le contenu de notre repository local vers le repository Bitbucket. Le panneau suivant apparaît.
La première chose à faire est de fournir l'URL HTTPS de notre repository Bitbucket. Cliquons donc sur le bouton Change....
Un peu de magie va opérer ici. Il suffit effectivement de coller notre UR HTTPS dans la case URI pour que le panneau suivant se remplisse presque entièrement. Il ne reste plus en fait qu'à saisir notre mot de passe dans la bonne case.
On clique ensuite sur Finish, ce qui termine la configuration du repository proprement dit.
Reste à configurer notre opération de push. On clique pour cela sur le bouton Advanced... du panneau suivant.
Le panneau suivant apparaît. La configuration est simple. Dans un premier temps on choisit de pousser toutes les branches locales (nous n'en avons en fait qu'une dans ce tutorial). On clique pour cela sur le bouton Add All Branches Spec.
Puis on choisit de pousser tous les tags locaux. On clique donc sur le bouton Add All Tags Spec.
Une fois ces deux boutons cliqués, notre panneau a l'allure suivante.
Ce panneau se ferme lorsque l'on clique sur Finish. On se retrouve alors sur le panneau précédent. Il doit avoir cette allure-la, qui indique que notre configuration est terminée.
Sauvegardons cette configuration (bouton Save). Notre vue Git Repositories a maintenant l'allure suivante.
On constate que notre repository Bitbucket apparaît bien sous le nom origin, nom que nous lui avons donné lors de notre configuration.
On constate aussi la présence de deux nœuds : l'un avec une petite flêche verte, l'autre avec une petite flêche rouge. Ces deux éléments symbolisent :
-
flêche rouge : l'opération de push, qui pousse notre repository local vers Bitbucket ;
-
flêche verte : l'opération de pull, qui rapatrie le contenu du repository Bitbucket vers notre repository local.
Nous avons donc maintenant deux repository : l'un, local, dans lequel se trouve notre projet Java (plusieurs commits), l'autre sur les serveurs de Bitbucket, dans le cloud. Ce second repository est pour le moment vide, puisque nous n'avons rien mise dedans. Ces deux repository sont configurés pour s'échanger des données, ce que nous allons faire à présent.
Commençons par pousser notre code Java vers notre repository Bitbucket. Tout est configuré pour y arriver.
Pour cela, on peut sélectionner le nœud qui porte la flêche rouge sortante de notre repository origin dans la vue Git Repository. Le menu pop-up de ce nœud comporte une option Push, que l'on sélectionne.
Un premier panneau s'ouvre, qui indique la progression de l'opération. Il se ferme plus ou moins rapidement, en fonction de ce que l'on a à uploader.
Une fois cette opération effectuée, un second panneau s'ouvre, qui nous informe de ce qui a étécfait. Notre branche par défaut (elle s'appelle master) a été envoyée vers Bitbucket.
On peut alors aller vérifier sur l'IHM Web de Bitbucket que l'ensemble de nos fichiers a bien été envoyé. Notre repository Bitbucket est donc bien peuplé avec notre repository local.
On a donc des données sur notre repository Bitbucket, qui sont la copie de ce que l'on possède en local.
Pour cette section, on suppose qu'une modification a été faite sur notre repository Bitbucket. Cette modification ne provient pas de notre repository local, qui, lui, n'a pas bougé. On souhaite donc rapatrier cette modification en local.
D'où cette modification peut-elle provenir ? En fait de nombreuses sources. Elle peut venir d'un collaborateur, qui travaille sur le même projet que nous. Elle peut venir d'une autre machine que celle qui a servi à créer le repository.
Afin de se mettre dans ce contexte, le plus simple est d'utiliser l'IHM Web de Bitbucket, qui permet de créer des fichiers textes très simplement (bouton New File sur la page Source).
Plus précisément, nous avons créé un fichier README.md manuellement dans notre
repositry Bitbucket.
Pour récupérer ces modification (ici juste ce fichier), nous allons utiliser la fonction Fetch de la vue Git Repository. Cela passe par une étape de configuration de cette opération.
Une fenêtre s'ouvre, analogue à celle qui s'était ouverte pour la configuration du Push. Et effectivement, ces deux opérations se ressemblent.
De même que pour l'opération de Push, on clique sur le bouton Advanced, ce qui nous ouvre le panneau suivant.
La configuration est encore la même : on sélectionne toutes les branches et tous les tags, en cliquant sur les deux boutons qui correspondent. On termine l'opération en cliquant sur Finish.
On se retrouve alors sur le panneau précédent, avec quelques élément cabalistiques, qui indiquent que les choses vont bien se passer.
Bien sûr, comme pour le Push, cette configuration n'est faite qu'une seule fois.
On peut alors lancer notre opération de Fetch.
Un panneau intermédiaire nous indique ce qui va être fait : rapatrier le code qui se trouve sur Bitbucket en local. Bien sûr, seuls les éléments que l'on ne possède pas déjà sont téléchargés.
Les données ont été rapatriées, elles se trouvent à présent dans notre repository.
Une chose un peu curieuse se passe toutefois : le fichier attendu, README.md
n'apparaît pas dans notre projet. Il a pourtant été correctement téléchargé.
Examinons l'état de notre repository par la vue History, que constate-t-on ?
Il est possible que la vue History n'affiche pas les commits téléchargés par l'opération de fetch. Si c'est le cas il faut cliquer sur le bouton Show all branches and tags de la vue History. Ce bouton est le dernier de la frise de bouton de la vue History, le plus à droite.
On constate qu'un commit a été ajouté à notre repository, mais que le commit que l'on regarde est toujours le même. Notre repository a bien été mis à jour, mais pas notre espace de travail. Il nous faut donc mettre à jour cet espace de travail avec ce nouveau commit.
Pour cela, nous allons sélectionner le commit que l'on veut mettre dans notre espace de travail, et sélectionner l'option Merge du menu pop-up. Merge signifie fusionner. Nous allons donc fusionner les modifications faites dans ce commit avec ce que nous avons.
Un panneau intermédiaire nous indique ce qui a été fait.
Si l'on examine notre repository à l'issue de cette opération, on constate bien que l'on
regarde à présent le dernier commit de notre repository, celui dans lequel se trouve
le fichier README.md.
Et de fait, si l'on examine notre projet Java, on constate que le fichier README.md
est bien présent.
On se propose enfin d'importer notre projet Java stocké dans Bitbucket sur une machine qui ne connaît pas le projet original. Notre machine n'a donc pas de repository Bitbucket en local. Les choses ne sont pas beaucoup plus compliquées, notamment la configuration du repository Bitbucket ne change pas.
On part donc d'un projet vide, qui ne connaît aucun repository Git. La figure suivante nous montre l'état de notre Eclipse, avec la vue Git Repository sans rien dedans.
Cliquons sur Clone a Git repository, dans la fenêtre Git Repository.
Eclipse a bien sûr besoin des coordonnées de ce repository. Il nous ouvre donc le même panneau que dans le cas précédent, dans lequel on colle l'URL HTTPS de notre repository. Ce panneau se remplit aussi magiquement, il ne nous reste plus qu'à entrer notre mot de passe.
Suit la sélection des branches à rapatrier. Ici nous n'en avons qu'une, le choix est donc assez simple.
Cloner un repository distant (ici celui de Bitbucket) consiste aussi à créer un repository local pour accueillir le contenu de ce repository distant. Le panneau suivant nous demande à quel endroit on veut créer ce repository local. Il nous demande également le nom des branches (ici il n'y en n'a qu'une) locales dans lesquelles les branches distantes vont être copiées. Et enfin, il nous demande le nom sous lequel le repository distant (Bitbucket va apparaître).
Sur ce simple panneau, Eclipse nous demande donc toutes les informations que nous lui avions données une par une lors de la configuration précédente.
Une fois cet import réalisé, la vue Git Repository nous donne le résultat de la création et de la configuration de notre repository local.
La deuxième étape de ce processus consiste à créer un projet Java à partir du contenu de ce repository. Pour le moment, le repository est bien importé sur notre poste local, mais nous n'avons pas encore de projet Java.
Il y a plusieurs façons de faire, l'un des plus simples consiste à importer le contenu de du répertoire de travail. On sélectionne pour cela la rubrique Import Project du menu pop-up du nœud Working directory.
Comme nous avons pris soin de ne pas commiter les fichiers de configuration d'Eclipse dans Git (ce qui était une bonne idée), Eclipse n'est pas capable de reconnaître que notre projet est en fait un projet Java Eclipse. Si notre projet avait été un projet Maven, Eclipse l'aurait reconnu comme tel, et les choses auraient été beaucoup plus simples.
On importe donc notre projet comme un projet générique, nous en ferons un projet Java dans la suite.
Eclipse nous demande un nom pour ce projet, ce qu'on lui donne.
Notre projet est donc bien créé, il ne s'agit pas d'un projet Java.
Pour en faire un projet Java, il faut ouvrir le panneau des propriétés du projet, soit par le
menu pop-up du projet, soit par le raccourci-clavier Alt-Entrée.
Le panneau des (nombreuses) propriétés apparaît alors, on s'intéresse à l'option
Project Facets.
Il faut alors cliquer sur le lien Convert to facet form... pour faire de notre projet un projet Java. Le panneau prend alors l'apparence suivante.
La facette qui nous intéresse est bien sûr la facette Java, qui est d'ailleurs sélectionnée par défaut. On doit aussi sélectionner la machine Java utilisée pour ce projet dans la partie droite du panneau, onglet Runtimes.
Le panneau correctement renseigné à l'allure suivante.
On peut enfin cliquer sur le bouton Ok. Notre projet prend alors l'allure d'un projet Java sous Eclipse.
Cela dit, il semble que notre projet ait subi des petites modifications : effectivement, un chevron est apparu devant son nom, qui indique que des fichiers on été ajoutés ou modifiés dans le processus.
On peut voir ces fichiers en tentant un commit. Le panneau qui apparaît nous montre ce qui a été ajouté. Ce commit ne doit surout pas être validé, on clique donc sur le bouton Cancel pour fermer cette fenêtre.
Ce sont donc bien des fichiers techniques Eclipse qui ont été ajoutés, rangés dans le répertoire
.settings. On ne veut pas de ces fichiers dans notre repository, il faut donc ajouter
le répertoire .settings à notre fichier .gitignore pour indiquer à Git
de les ignorer.
On peut accéder à ce fichier directement du nœud Working Directory
de notre repository, et l'éditer normalement. Ici nous avons ajouter la ligne
.settings/ à la fin de ce fichier.
Notre projet est toujour en modification, mais cette fois il s'agit du fichier
.gitignore, que nous pouvons effectivement commiter.
À partir de ce moment, nous avons un projet Java sur notre poste local, qui est une copie de ce qui se trouve dans notre repository Bitbucket. On peut donc modifier ce projet, pousser nos modifications dans Bitbucket, et les récupérer sur noter autre poste de la même façon.
José Paumard © 2015, tous droits réservés