Archives par étiquette : Tuto Git

Tuto Git – Utiliser Git avec eclipse: publier, tagger, visualiser

Objectif: Publier un projet sur un serveur distant avec Git sous eclipse. Pouvoir poser des tags et consulter l’historique et les paramètres du projet avec cet outil.

Pré-requis: Fonctionnement de Git et l’article précédent à propos de l’utilisation de Git avec eclipse.

1. Créer le dépôt du projet calcul sur le serveur.

Conformément à l’environnement de simulation mis en place dans cette serie d’articles sur Git, on crée le dépôt du projet « calcul » du côté serveur. Cette étape ne concerne pas l’utilisateur de Git mais plutôt un administrateur système. D’un autre côté, dans un environnement réel elle s’effectue sur une machine serveur distante, le plus souvent accessible via HTTP par les utilisateurs.

cd /serveurgit
git init --bare calcul.git

Ceci créee le dépôt Git du projet dans le dossier /serveurgit/calcul.git/. Cette mise en place nous permettra de nous servir de ce dépôt pour simuler la publication du projet sur un serveur distant.

2. Publier le projet dans le dépôt du serveur.

Jusqu’à présent les « commit » effectués (cf. article « Git avec eclipse« ), l’ont été dans le dépôt local sur la machine du développeur. Pour partger ce projet avec d’autres développeurs, il convient de le publier dans le dépôt distant (remote) du serveur. Pour le faire avec Git sous eclipse il faut sélectionner le projet dans l’explorateur (volet par défaut situé à gauche) et ensuite utiliser le menu contextuel (Click avec le bouton droit de la souris).
Tuto GitUtiliser le menu: Team / Push branch master. Ceci conduit à l’assistant de publication:

Tuto GitLe dossier qui simule le dépôt du serveur étant local en réalité, nous utilisons le bouton « Local File..« . Il nous permettra de sélectionner facilement l’emplacement du dépôt à utiliser, c’est à dire « /serveurgit/calcul.git« .
Ceci alimentera les champs « URI » et « Repository path » sans saisie. Le champ « Remote name » doit être gardé à sa valeur par défaut: « origin« , c’est une convention de Git de nommer le dépôt distant ainsi et il vaut mieux la garder.

A ce sujet, il convient de noter qu’en réalité le serveur distant est accessible généralement par le protocole HTTP (tel que https://github.com/ameddeb/japptools.git) ou le protocole propre à git (tel que git://github.com/ameddeb/japptools.git). Le paramétrage utilisé est dicté par la situation de simulation uniquement.

Après la saisie, le bouton « Next » permet de passer à l’étape suivante.

Tuto GitLes valeurs par défaut sont convenables, on les garde et on utilise le bouton « Next » pour passer à l’étape suivante.

Tuto GitOn utilise le bouton « Finish » pour finaliser la publication. A ce stade le dernier commit du projet est publié sur le serveur.

3. Poser un Tag dans le projet.

Avant de poser un Tag, qui constitue généralement un marquage pour une version du projet, nous allons faire évoluer le fonctionnement. Pour cela on effectue la modification suivante dans le fichier App.java:

public static void main( String[] args )
{
      System.out.println( "125 x 3 = " + 125*3 );
}

On remplace simplement l’affichage de « Hello world! » par le calcul de la multiplication.
Ensuite, après avoir exécuté avec succès le nouveau code et surtout pas avant, comme c’est malheureusement la cas souvent dans la réalité de tous les jours, on valide (commit) la modification dans le dépôt local.

Tuto GitOn utilise le bouton « Commit » après avoir indexé le projet et saisie le message.
Suite à cela on va ajouter un calcul d’addition au projet:

   System.out.println( "450 + 343 = " + (450 +343) );

De la même manière que pour la multiplication, on valide (commit) également cette nouvelle modification en adaptant le message.

Maintenant que le projet est suffisamment évolué, on se propose de poser un Tag de version « v1.0« . Pour cela on utilise le menu contextuel du projet calcul:

Tuto GitTeam / Advanced / Tag.., Ce menu donne accès à l’écran de création de Tag:

Tuto GitDans cet écran, on saisie le Tag (Tag name), le message qui l’accompagne (Tag message) et ensuite on utilise le bouton « Create Tag » pour le créer effectivement. Remarquer toutefois la présence du bouton « Create Tag and Start Push » qui permet de créer le Tag et de publier sur le serveur distant en même temps.

4. Visualiser les données du dépôt.

On peut visualiser le paramétrage du dépôt en utilisant le menu destiné à cet effet:

Tuto GitTeam / Show in Repositories View, Ce menu permet d’accéder aux informations qui s’affichent dans le volet bas de l’espace de travail d’eclipse:

Tuto GitOn remarquera notamment la possibilité de visualiser les branches, les Tags et le paramétrage des dépôts distants (perce qu’on peut en avoir plusieurs mais cela est autre sujet).

Par ailleurs, on peut visualiser également l’historique du projet, équivalent de « commit log« , en utilisant le menu au dessus du précédent: Team / Show In History. Cela donne l’affichage de l’historique:

Tuto Git

Tuto Git – Utiliser Git avec eclipse

Objectif: Comprendre les procédures d’utilisation de Git pour gérer un projet développé avec eclipse. Le principal intérêt est un meilleur confort avec l’interface graphique mais aussi une utilisation integrée à cet IDE.

Pré-requis: Etre familier avec Git et son utilité (cf. articles précédents à ce sujet).

1. Créer un projet Java Maven autonome.

Le menu à utiliser est : File / New / Maven Project

Tuto gitSi le sous-menu « Maven project » n’apparaît pas dans votre version d’eclipse, utiliser le sous-menu « Other.. » qui donne accès à cette fonctionnalité. Ce menu affiche la fenêtre:

mTuto gitIl suffit de clicker sur « Next », car on souhaite utiliser un archetype de création de projet.

Tuto gitUn archetype Maven est un assitant qui facilite la création d’un gabarit de projet. Sélectionner « quickstart » qui permet la création d’un projet autonome simple.

Tuto gitSaisir le « Groupe Id » (généralement le domaine de l’oganisme pour l’unicité universelle) et l' »Artifact Id » (généralement le nom de l’application). Après cliquer sur  « Finish » pour créer le projet.

Tuto gitLe nouveau projet est prêt à l’emploi, il est exécutable immédiatement et sans aucune modification (mais bien entendu ne fait rien d’autre que d’afficher « Hello world »).

2. Gérer le projet avec Git

Dans l’explorateur de projets, sélectionner le projet « calcul » et utiliser le menu contextuel d’eclipse (click sur le bouton droit de la souris).

Tuto gitDans le menu « Team« , sélectionner le sous-menu « Share project« , ceci lance la procédure d’integration du projet à Git.

Tuto gitSélectionner la case à cocher « Use or create repository in parent folder of project« , l’affichage devient:

Tuto gitEnsuite utiliser le bouton « Create repository« ..

Tuto gitA l’étape suivante, il faut cocher l’unique projet à prendre en compte et ensuite utiliser le bouton « Finish« .
Cette procédure permet de mettre le projet calcul sous le contrôle de Git.

3.Commiter le projet.

Le projet calcul étant sous le contrôle de Git, si on active le menu contextuel « Team » (cf. paragraphe 2,; étape 1) on constate que les commandes de Git sont maintenant disponibles.

git-firstcommitOn reconnait notamment les commandes:

  • « Commit » : permet de valider des modifications de fichiers (équivalent de « git commit« ).
  • « Add to index » : permet d’ajouter des fichiers à l’index (équivalent de « git add« ).

On va utiliser le menu « Commit »

Tuto gitTout d’abord il faut ajouter les fichiers à l’index. On sélectionne les fichiers puis on utilise le menu contextuel (click droit) « Add to index« . Bien entendu on aurait pu utiliser le menu de cette fonctionnalité dès le départ, mais on procédant ainsi, on fait tout dans la même fenêtre (équivalent de « git commit -a« )

Tuto gitEnfin, on saisit le message du commit et on actionne le bouton « Commit« . Ceci valide les fichiers sélectionnés dans le dépôt local de Git.

Tuto Git – Gestion avancée des branches

Cet article de la série « tuto git » traite d’aspects plus avancés de l’utilisation des branches avec Git. Il traite notamment le maintient dans un état exploitable de lhistorique d’évolution d’un projet.

Pré-requis: Les commandes de base, ainsi que la gestion des conflits et l’utilisation des branches avec Git sont assimilés. L’environnement de simulation multi-développeur est mis en place. Il fait suite à l’article « Utiliser les branches ».

1. Forcer l’historisation d’une branche.

Dans l’article précédent, nous avons traité du cas de figure où une branche est utilisée pour isoler les travaux en lien avec une évolution fonctionnelle importante. Cette évolution fonctionnelle faisant partie d’un découpage ifonctionnel identifié du projet, la trace de cette branche a été volontairement gardée dans l’historique.
Dans le cas actuel il s’agit de traiter du cas où les travaux a effectuer sont de moindre importance et en tout cas ne faisant pas partie d’un découpage fonctionnel identifié. Ce cas peut être par exemple celui de la correction d’un bug ou celui d’une évolution mineure. Ces évolutions ne sont pas à garder, en tant que branche séparée, dans l’historique du projet. La raison est d’éviter d’avoir trop de dérivations dans l’évolution qui rendrait l’historique illisible, voire inexploitable.
Pour l’illustration, on suppose que DEV2 doit corriger deux bugs de présentation identifiés dans le traitement de la conjugaison au passé composé. Pour cela il crée une branche pour isoler ses modifications:

git checkout -b bugfix

Cette commande est une contration (raccourci) des deux commandes de création et bascule vers une nouvelle branche.
Suite à cela,; DEV2 édite le fichier parler_passe et corrige la ligne 4 comme suit (espace manquant entre « as » et « parlé »):

tu as parlé
au lieu de >>
tu asparlé

Ensuite DEV2 valide sa correction:

git commit -am "Correction de bug: espace entre 'as' et 'parlé'"

En même temps DEV1 (cd /pcdev1/conjparler), chargé de développer la conjugaison au future, effectue les modifications:

git checkout -b future
vi parler_future
vi conjugue_parler.sh

Le contenu de parler_future:

echo ""
echo -e "\t\tFUTURE"
echo -e "\t\t------"
echo -e "Je parlerai\t\tNous parlerons"
echo -e "Tu parleras\t\tVous parlerez"
echo -e "Il parlera\t\tIls parleront"

Le nouveau contenu de conjugue_parler.sh:

#!/bin/bash
source parler_present
echo ""
source parler_passe
echo ""
source parler_future

Suite à cela, DEV2 valide ses modifications et les publie:

git add parler_future
git commit -am "Ajouter la conjugaison au future simple"
git checkout master
git merge future --no-ff
git push

Remarquer le paramètre –no-ff de la commande merge. Ce paramètre permet de forcer l’historisation de la branche future. L’utilisation de ce paramètre est justifiée par le fait que master n’a pas changé depuis le moment de la création de la branche. Dans ces conditions un merge simple aurait été considéré comme une simple avancée de la branche master.

2. Eviter l’historisation d’une branche.

En même temps, DEV1 de son côté (cd /pcdev1/conjparler), corrige un deuxième bug en supprimant deux tirets en trop dans le soulignement du titre « PASSE ». Ensuite il valide, puis bascule sur la branche master:

vi parler_passe
git commit -am "Correction du soulignement du titre PASSE"
git checkout master

A ce niveau, les corrections de bug ayant pris du temps, DEV2 doit mettre à jour sa copie locale:

git pull

Il se rend compte alors que la branche master a évolué. Cela a pour conséquence que s’il effectue un merge simple la branche bugfix va être inscrite dans l’historique des évolutions. Ceci « pollue » cet historique inutilement. Pour éviter cela DEV2 doit utiliser la commande rebase avant le merge:

git rebase master bugfix
git checkout master
git merge bugfix
git push

La commande rebase a pour résultat de repositionner l’origine de la branche bugfix sur la dernière mise à jour récupéré du dépôt distant. Ce repositionnement évite l’inscription de cette branche dans l’historique et rend l’évolution parfaitement linéaire comme indiqué dans le graphe (git log –graph):

tuto gitSans l’utilisation de la commande rebase, on aurait eu une troisième branche parallèle à « future ».

3. Suppression des branches inutiles

Une fois fusionnées les branches ne sont plus utiles. Il convient donc de les supprimer. DEV1 doit supprimer la branche bugfix qui est locale à sa copie:

git branch -D bugfix

DEV2 supprime de son côté la branche locale future:

git branch -D future

Le cas de la branche passecompose est différent car elle a été publiée sur le dépôt distant. DEV2 pourra la supprimer en local et sur le serveur avec les commandes:

git branch -d passecompose
git push --set-upstream origin passecompose

La première commande permet de supprimer la branche dans la copie locale (cf. l’article utiliser les branches). La deuxième permet de porter cette suppression sur le dépôt distant.

Tuto Git – Utiliser les branches

Cet article de la série « tuto git » permet de comprendre l’utilité et la gestion des branches avec Git.

Pré-requis: Les commandes de base, ainsi que la gestion des conflits avec Git sont assimilés. L’environnement de simulation multi-développeur est mis en place (cf. articles précédents).

1. Création d’un nouveau projet de démonstration.

Le projet conjparler permet de conjuguer le verbe « Parler ». On se propose de le gérer avec Git. On va initialiser son dépôt sur le serveur, ensuite le développeur DEV1 se chargera de sa création.

cd /serveurgit
git init --bare conjparler.git

Ceci initialise le dépôt du projet côté serveur.

cd /pcdev1
git clone /serveurgit/conjparler.git
cd conjparler
git config --local user.name DEV1
git config --local user.email DEV1@server.com

Ceci permet à DEV1 de récupérer une copie de travail locale du projet, cette copie est bien entendu encore vide.
DEV1 crée les deux fichiers conjugue_parler.sh et parler_present dans cette copie de travail:

vi conjugue_parler.sh
vi parler_present

Le contenu du fichier conjugue_parler.sh est:

#!/bin/bash
source parler_present

Le contenu du fichier parler_present est:

echo "Je parle"
echo "Tu parles"
echo "Il parle

Rendre le fichier conjugue_parler.sh exécutable et ajouter le tout au dépôt de Git local, puis envoyer sur le serveur.

chmod +x conjugue_parler.sh
git add .
git commit -m "Creation du projet conjparler"
git push

2. Création d’une branche de travail.

De son côté DEV2 récupère une copie locale de conjparler:

cd /pcdev2
git clone /serveurgit/conjparler.git
cd conjparler
git config --local user.name DEV2
git config --local user.email DEV2@server.com

DEV2 est chargé d’ajouter une fonctionnalité importante au projet: la conjugaison au passé composé du verbe parler. Afin d’isoler ses travaux de l’éxistant de manière qu’il n’introduit aucun risque de dysfonctionnement, il décide de créer une branche dans laquelle il effectuera ses travaux.

git branch passecompose

Pour vérifier la création de la nouvelle branche et basculer sur celle-ci:

git branch
git checkout passecompose
git branch

La commande git branch, permet de lister les branches existantes. La branche dont le nom est précédé d’une étoile dans cette liste est la branche active. Une seule branche est active à la fois. Toute modification effectuée dans les fichiers est localisée dans la branche active uniquement. C’est tout l’intérêt des branches.
DEV2 effectue alors ses modifications: création d’un fichier parler_passe dont le contenu est:

echo "J'ai parlé"
echo "Tu asparlé"
echo "Il a parlé"

Il modifie également le fichier conjugue_parler.sh de manière que son contenu devienne (ajout des deux dernières lignes):

#!/bin/bash
source parler_present
echo ""
source parler_passe

Ensuite DEV2 valide ses modifcations:

git add .
git commit -m "Ajout de la conjugaison au passé composé"

Pour vérifier l’isolation entre les deux branches, on peut basculer sur master et verifier le contenu du fichier conjugue_parler.sh

git checkout master
cat conjugue_parler.sh
ls -l

Rien, donc, n’a été modifié dans la branche master. Vous pouvez également re-basculer sur la branche passecompose et re-vérifier les contenus.
A ce stade, DEV2 peut même publier la branche passecompose pour partager ses travaux avec les autres développeurs:

git checkout passecompose
git push --set-upstream origin passecompose

3. Travail simultané sur les deux branches.

Simultanément aux travaux effectués sur la branche passecompose, DEV1 peut continuer ses travaux sur la branche principale master. Il va compléter la conjugaison au présent. Le contenu du fichier parler_present devient:

echo -e "Je parle\t\tNous parlons"
echo -e "Tu parles\t\tVous parlez"
echo -e "Il parle\t\tIls parlent"

A l’exécution cela donne (commande : ./conjugue_parler.sh):

Je parle                Nous parlons
Tu parles               Vous parlez
Il parle                Ils parlent

Content du résultat DEV1 valide son travail:

git commit -am "Ajout du présent au pluriel"

Ensuite il avance encore dans ses travaux et améliore la présentation. Le contenu du fichier parler_present devient:

echo ""
echo -e "\t\tPRESENT"
echo -e "\t\t-------"
echo -e "Je parle\t\tNous parlons"
echo -e "Tu parles\t\tVous parlez"
echo -e "Il parle\t\tIls parlent"

Puis valide les nouvelles modifications:

git commit -am "Bien présenter le résultat"

Et pose même un tag pour marquer une version d’évolution et publie ces évolutions:

git tag -a v0.1 -m "Version 0.1"
git push
git push --tags

De son côté DEV2 (cd /devpc2) poursuit les évolutions et modifie le fichier parler_passe de manière que son contenu devient:

echo ""
echo -e "\t\tPASSE"
echo -e "\t\t-------"
echo -e "J'ai parlé\t\tNous avons parlé"
echo -e "Tu asparlé\t\tVous avez parlé"
echo -e "Il a parlé\t\tIls ont parlé"

Ensuite valide et pose un tag:

git commit -am "Améliorer la présentation"
git tag -a v0.2 -m "Version 0.2"
git push
git push --tags

4. Fusion des branches

DEV2 décide également de fusionner les deux branches pour obtenir un fonctionnement global de l’application. La fusion doit se faire dans la branche principale master:

git checkout master
git pull
git merge passecompose

La première commande permet de basculer sur la branche master. Le seconde met à jour cette branche depuis le dépôt distant (serveur). Enfin la troisième permet de fusionner le contenu de ‘passecompose’ dans la branche master. On peut le constater par la commande:

git log --decorate --graph

tuto gitL’exécution du script (./conjugue_parler.sh) donne le résultat:

                PRESENT
                -------
Je parle                Nous parlons
Tu parles               Vous parlez
Il parle                Ils parlent

                PASSE
                -------
J'ai parlé              Nous avons parlé
Tu asparlé              Vous avez parlé
Il a parlé              Ils ont parlé

Il s’agit bien du résultat final et fusionné des travaux de DEV1 et DEV2 qui ont été effectués de manière séparée dans deux branches différentes. C’est une illustration de l’utilisation principale des branches et de la manière de la mener. L’utilisation de cette technique est intimement liée au découpage fonctionnel du projet. Sans un découpage fonctionnel bien fait, il est difficle d’utiliser les branches avec efficacité. Mais bien utilisée, cette technique permet également d’obtenir une documentation de l’historique des évolutions ainsi que la possibilité de retrouver ces situations historiques de manière très simple.

5. Suppression des branches

La branche passecompose n’est plus utile, maintenant que son contenu a été fusionné avec la branche master. Pour garder un état propre du projet,; il faut la supprimer. Pour cela DEV2 utilise les commandes:

git checkout master
git branch -d passecompose

On bascule d’abord sur la branche master (pour ne pas scier la branche sur laquelle on est assi), ensuite on demande la suppression (git branch -d). Le résultat dans le cas de DEV2 est toutefois decevant:

tuto gitC’est une erreur courante qui se produit lorsqu’on on essaie de supprimer une branche qui n’est pas synchronisée avec le dépôt distant (suite au merge). Il convient donc de synchronier la branche passecompose avant de la supprimer:

git checkout passecompose
git push
git checkout master
git branch -d passecompose

La suppression est alors effectuée sans problème. Bien entendu cette suppression n’entraine pas la disparition de la branche de l’historique. Un test simple de visualisation des log permet de s’en rendre compte.