Author Archives: ameddeb

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 “CommitTuto 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.]]>

Openldap tutorial – Administration par interface graphique

Pré-requis: L’article Ajouter des données à l’annuaire ainsi que ses pré-requis sont lus. Le serveur OpenLDAP est installé et alimenté avec les données de l’article.

1. Installation de JXplorer.

JXplorer est un utilitaire d’administration de serveurs LDAP multiplateformes (écrit en Java, donc ne nécessite que la présence d’un JRE sur tout type de système). Vérifier la disponibilité de cet utilitaire sur le système:
apt-cache search jxplorer ↵
jxplorer - Navigateur LDAP en Java
Installation de jxplorer:
sudo apt-get install jxplorer
JXplorer étant un utilitaire avec interface graphique, il faudra le lancer à partir du menu du bureau installé. Par exemple sous KDE : Menu K / Applications / Développement / LDAP Browser (JXplorer)

Openldap tutorial jxplorer2. Connexion au serveur

Pour se connecter au serveur OpenLDAP il convient d’utiliser le menu: Fichier / Se connecter. L’utilisation de ce menu affiche la fenêtre de connexion: Hote: localhost (ou 127.0.0.1), Si le serveur est sur une machine différente utiliser l’adresse IP de cette machine. Port: Par défaut le port ldap est 389, donc utiliser cette valeur sauf exception. Protocole: Utiliser LDAP v3, car c’est la version actuelle du protocile LDAP (sauf exception de système ancien) Base DN: Le noeud de l’arbre qui constituera la racine des données accédées, utiliser le DIT du serveur pour tout avoir. Sécurité / Niveau: Utilisateur + Mot de passe. Les autres niveaux de sécurités ne seront pas abordés ici. Utilisateur DN: Le DN de l’utilisateur de connexion, utiliser le DN de l’administrateur du serveur. Mot de passe: Utiliser le mot de passe configuré pour l’utilisateur choisi. Un click sur le bouton “OK” lance la connexion. En cas d’erreur, un message s’affiche pour indiquer le type d’erreur. Si les paramètres saisi sont corrects la connexion s’établit.

3. Navigation dans le contenu des données.

Deux volets principaux permettent d’explorer les données gérées par le serveur. Openldap tutorial jxplorerLe volet de gauche permet de naviguer dans l’arborescence des données. Le volet de droite affiche les données relatives à l’objet selectionné dans le volet de gauche. Il permet également (sous reserve de droits) de modifier les données de cet objet.

4. Ajouter une personne à l’annuaire OpenLDAP

Pour ajouter une personne, il convient de se placer (volet gauche) sur le noeud “People”. Utiliser, après cela le menu Editer / Nouveau Openldap tutorial jxplorerSaisir dans le champ RDN: uid=petit et cliquer sur le bouton “Ajouter” Openldap tutorial jxplorerCompléter la saisie des données: sn : Petit, givenName: Michel, cn: Michel Petit et userPassword. La saisie du mot de passe (userPassword) se fait dans une fenêtre séparée. Openldap tutorial jxplorerSaisir deux fois, dans les deux champs de siaise: petit. La combobox permet de sélectionner le niveau de cryptage souhaité: SHA ou SSHA constituent un bon choix. Cliquer sur “OK” pour valider le mot de passe, ensuite sur “Soumettre” pour valider la nouvelle entrée.

5. Ajouter un noeud conteneur

Si on souhaite ajouter des structures à l’annuaire (direction, service informatique..), il convient d’ajouter un noeud conteneur au même niveau que “People”. Il faut d’abord se placer sur le DIT “ldaptuto” et utiliser ensuite le menu Editer / Nouveau. Openldap tutorial jxplorerSupprimer les classes “simpleSecurityObject” et “organizationalRole” car elles ne correspondent pas à un noeud conteneur. Pour cela utiliser le bouton “Supprimer”. Openldap tutorial jxplorerAjouter la classe “organizationalUnit”. Utiliser le bouton “Ajouter” après la selection de la classe dans la liste. Saisir, ensuite, dans le champ RDN celui du noeud à créer: ou=Structures. Cliquer enfin sur le bouton “Ajouter”. Openldap tutorial jxplorerLe bouton “Soumettre” permet d’enregistrer cette modification et valider la création du noeud conteneur.]]>

Tuto Git – Gestion avancée des branches

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

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.]]>

Tuto Git – Suivi de l'évolution de fichiers et projets

Objectif: Suivre de manière efficace l’évolution des fichiers d’un projet logiciel contrôlé par Git. Utiliser les tags git pour marquer les versions de cette évolution. Pré-requis: Git est installé et confiiguré sur un système GNU/Linx (article 1 de la serie « Tuto Git ». Les commandes de base sont connues et les manipulations de l’article qui traite des fusions exécutées.

1. Visualiser les traces de l’évolution d’un fichier

On considère la situation atteinte à la fin du précédent article de la serie « Tuto Git ». DEV1 (cd /pcdev1) souhaite visualiser l’avolution du fichier README. Il exécute:
git log README
Le résultat obtenu est le suivant, marqué en couleur jaune l’indication de la fusion effectuée:

Tuto GitTrace de l’évolution du fichier README

Cette visualisation peut être améliorée en utilisant le paramètre graph:

git log --graph README
Le résultat obtenu est le suivant, marqué en couleur jaune l’indication de la fusion effectuée. Remarquer l’indication du conflit par la segmentation du « parcours » du fichier dans le temps:

Tuto GitTrace de l’évolution du fichier README avec représentation graphique

2. Créer un tag pour un projet

A tout moment au cours de l’évolution du projet on peut poser un tag sur l’ensemble du dépôt de fichiers source. Ceci permet de revenir ultérieurement vers cette image du projet. Dans la pratique un tag est posé à chaque fois que le projet atteint un certain niveau de maturité, notamment à l’occasion de la diffusion d’une version. DEV2 (cd /pcdev2) ajoute d’abord la ligne suivante à la fin du fichier README:
Evolution de la version 1.0
Ensuite il pose un tag pour marquer la version 1.0
git tag -a v1.0 -m "Version 1.0"
git commit -am "Evolution vers une version stable"
git push
git tag
Remarquer la réponse à la dernière commande qui permet d’afficher la liste des tags disponibles. DEV1 (cd /pcdev1) récupère cette évolution et regarde s’il y a des tags:
git pull
git tag
Curieusement aucun tag n’apparaît. L’explication à ceci est que le tag posé par DEV2 est resté local au dépôt de DEV2, un push simple ne permet pas d’envoyer les tags sur le serveur. Pour remedier à cela DEV2 (cd /pcdev2), exécute de son côté:
git push --tags
Maintenant DEV1 récupèrera le tag posé après un git pull.

3. Revenir à une version (tag) précédente du projet

Après avoir récupéré les dernières modifications avec le tag, DEV2 exécute, pour récupérer la version 1.0:
git checkout v1.0
cat README
La commande checkout permet ivc de se positionner sur un tag existant. Encore une fois curieusement, le contenu de README affiché avec la commande cat ne montre pas la dernière mise à jour (ajout de la ligne « Evolution de la version 1.0 »). Ce “mystère” peut être illucidé grâce à la commande:
git log --decorate README
La réponse à cette commande est: Tuto GitOn est bien positionné sur le tag v1.0 (premier commit dans la liste) mais ce commit n’est pas le dernier en date. La cause est que le tag a été posé avant le dernier commit (paragraphe 2). Le tag est créée est positionné sur le dernier commit existant au moment de la création. Pour s’assurer de cette explication, DEV2 exécute successivement les commandes:
git checkout master
git log --decorate --graph README
La commande git checkout master permet de revenir à tout moment au dernier commit en date. La réponse à ces commandes est: Tuto GitLa commande cat README permet de s’assurer également que le contenu de ce fichier est bien celui de la dernière mise à jour.]]>

Tuto Git – Fusion de modifications de fichiers avec conflits multiples

Objectif: Comprendre la démarche pour effectuer une fusion (merge) de plusieurs fichiers avec des conflits de modification multiples. Pré-requis: Git est installé et confiiguré sur un système GNU/Linx (article 1 de la serie « Tuto Git ». Les commandes de base sont connues et un outil de fusion (mergetool) est configuré.

1. Ajouter un troisième développeur à la simulation

Exécuter dans l’ordre:
sudo mkdir /pcdev3
sudo chown login:login /pcdev3
cd /pcdev3
git clone /serveurgit/hello.git
cd hello
git config --local user.email "DEV3@server.com"
git config --local user.name "DEV3"

2. Ajouter un fichier qui va subir les conflits multiples de modification.

DEV3 crée un nouveau fichier README (avec l’éditeur vi par exemple) et l’ajoute au dépôt. Le contenu de ce fichier est:
Pour utiliser ce logiciel d'affichage de messages:
./hello.sh
La réponse sera:
Affichage
Bonjour tout le monde en 4 langues.
Ensuite, DEV3 exécute:
git add README
git commit -m "Création de README"
git push
Suite à cela DEV1 et DEV2 exécutent: git pull, chacun de son côté, pour récupérer le nouveau fichier.

3. Effectuer les modifications des fichiers pour se mettre en situation.

3.1. DEV3 (cd /pcdev3) modifie le fichier README pour que son contenu devienne:

Pour utiliser ce logiciel exécuter:
./hello.sh
La réponse est alors:
Affichage
"Hello world" d'abord, ensuite 3 autres langues.
Ensuite il exécute:
git commit -am "Modification de README"
git push

3.2. DEV2 (cd /pcdev2) modifie le fichier hello.txt pour que le contenu de la 1ere ligne devienne:

Affichage de "bonjour tout le monde" dans les langues suivantes:
Ensuite il exécute:
git commit -am "Modification de la 1ere ligne de hello.txt"
git push

3.3. DEV1 (cd /pcdev1) modifie le fichier README pour que son contenu devienne:

Utilisation:
./hello.sh
Réponse:
Affichage
"Bienvenue" en 4 langues.

3.4. DEV1 modifie le fichier hello.txt pour que le contenu de la 1ere ligne devienne:

"Bienvenue" en:

4. Fusion des deux fichiers en conflit.

Quand DEV1 tentera d’envoyer ses modifications sur le serveur, il y aura 4 conflits: 3 dans README et 1 dans hello.txt. DEV1 exécute donc:
git commit -am "Simplification de README et hello.txt"
git push
La deuxième commande échoue à cause du conflit, DEV1 doit alors effectuer une fusion (merge).
git pull
git mergetool
l’outil paramétré (ici vimdiff) est lancé et DEV1 peut arbitrer les conflits un à un:

tuto gitMerge du fichier hello.txt – affichage initial

tuto gitDéplacer le curseur dans la zone du conflit et lancer la commande: diffget LOCAL, pour récupérer la copie locale

tuto gitAprès la validation de la commande diffget le conflit est résolu et la modification doit être enregistrée (:wqa)

tuto gitAussitôt l’enregistrement effectué, l’outil passe au fichier suivant en confli: README

tuto gitAprès la résolution, de la même manière des trois zones de conflit dans ce fichier, l’enregistrement entraine la fin du traitement (:wqa)

Pour valider l’arbitrage effectué:
git commit -m "Fusion"
git push
Bien entendu, à ce stade seul DEV1 dispose en local de la version finale issur de la fusion. DEV2 et DEV3 doivent exécuter git pull pour synchroniser leurs copies locales respactives.]]>

Tuto Git – Modifications simultanées de fichiers avec conflit

Objectif: Ce « Tuto Git » traite de la gestion des conflits de modifications effectuées par deux ou plusieurs développeurs. Git considère qu’il y a conflit quand le contenu d’une même ligne est différent entre deux versions du même fichier (version locale et version distante sur le serveur qui heberge le dépôt de données). Une ligne dans un fichier est identifiée par son numéro comptabilisé du haut vers le bas du fichier. Pré-requis: Git est installé et configuré, les notions de base d’utilisation de git sont assimilées.

1. Configuration permanente de « pull –no-edit »

Dans l’article précédent on a utilisé la commande git pull –no-edit pour récupérer le contenu du/des fichier(s) modifié(s) sur le serveur. Le paramètre –no-edit permet d’éviter l’ouverture systématique (en cas de modifications en local et sur le serveur sans conflit) d’un éditeur de texte pour la saisie d’un commentaire. Si on souhaite garder ce mode de fonctionnement sans devoir à chaque fois utiliser ce paramètre, on doit le configurer. Pour cela il faudra executer la commande:
git config --global core.mergeoptions --no-edit

 2. Configuration de la gestion de la fusion (merge)

La gestion des conflits de modifications implique une configuration préalable, notamment celle d’un outil de gestion de fusion. Pour cela il faudra executer les commandes:
git config --global merge.tool vimdiff
git config --global merge.conflictstyle diff3
git config --global mergetool.prompt false
Ceci configure l’utilisation de l’outil en ligne de commande vimdiff pour la fusion du contenu des fichiers. Il existe plusieurs outils de gestion de fusion utilisables avec Git, dont certains avec interface graphique tel que kdiff3. Pour l’utiliser, il suffit de remplacer vimdiff par kdiff3 dans la commande de configuration. Il est utile de rappeler que cette configuration peut être affinée localement pour chaque projet en utilisant –local à la place de –global. Il est également utile de savoir qu’on peut consulter à tout moment les paramètres configurés par:
git config --global -l

 3. Conflit simple à la modification d’un seul fichier

DEV1 modifie la quatrième ligne de hello.sh (en italien), de façon qu’elle comporte 2 points d’exclamation à la fin au lieu d’un seul. DEV2 modifie la même ligne dans le même fichier mais en effaçant tout sauf le mot Ciao auquel il ajoute 4 points d’exclamation. DEV1 puis DEV2 executent les commandes:
git commit -am "Modification du message italien"
git push
La dernière commande de DEV2 échoue évidemment. Il execute alors:
git pull
Sans le paramètre –no-edit cette fois. Un message en réponse à cette commande indique qu’il y a un conflit de modification qu’il convient de résoudre. Pour le résoudre DEV2 execute:
git mergetool
Cette commande ouvre l’outil de merge configuré (vimdiff dans notre cas): Tuto Git - MergeQuatre versions du fichier hello.sh sont ouvertes dans quatre quadrants. En réalité il s’agit de 3 + 1 versions, la dernière étant le fichier résultat à obtenir et non pas une version réellement actuelle. C’est pour cela que ce procédé est dit Three-Way merging. Dans le volet d’en haut, les trois versions existantes. De gauche à droite (remarquer le nom du fichier indiquée dans la barre d’en bas): la version LOCALe (modification de DEV2), la version de BASE (version avant les modifications) et enfin la version REMOTE (dernière version sur le serveur, modification de DEV1). Dans le volet d’en bas le fichier cible, fusionné mais avec des marques (tags) pour indiquer les différentes modifications en conflit à arbitrer. Il s’agit d’un point de départ créée automatiquement par Git, à modifier impérativement pour nettoyer les tags rajoutés. Pour obtenir le résultat souhaité dans le fichier fusionné (cadrant d’en bas), on peut récupérer l’un des trois contenus, modifier le contenu manuellement ou les deux. On suppose ici qu’on voudrait obtenir le contenu suivant de la ligne modifiée et qui ne correspond à aucune des versions existantes:
Ciao tutti !!!!
Le plus proche de ce contenu est celui de la version locale, donc on va récupérer la version locale, la modifier et l’enregistrer. En premier on positionne le curseur dans la zone taggée en conflit. Cette zone commence par la ligne “<<<<<<< HEAD“. Pour ceux qui ne sont pas habitué à l’éditeur VI (ou VIM):  Pour naviguer entre les cadrants: commande Control-w, c’est à dire touche controle du clavier + w en même temps. Pour exécuter une commande: touche : du clavier, le curseur se positionne alors dans la dernière ligne du cadrant actif, on saisi alors la commande puis la touche entrée du clavier. Ensuite, on execute la commande de récupération du contenu du fichier local. on tape la touche : (lancer une commande dans vi) et ensuite dans la barre d’en bas on saisi:
diffget LOCAL
Tuto Git - MergeAprès la validation de cette commande (touche Entrée), le contenu change et les tags du conflit disparaissent. On modifie la ligne pour obtenir le résultat souhaité (Ciao tutti !!!!) puis on enregistre et on quitte. Pour enregistrer [:w], pour quitter [:qa]. On peut également utiliser les deux commandes en même temps [:wqa]. Enfin il convient, bien entendu, de valider et envoyer les modifications.
git commit -am "Modification arbitrée du message italien"
git push
De son côté, DEV1 peut alors récupérer le résultat en lançant la commande git pull.

4. Conflits multiples sur plusieurs fichiers

En suivant le même mode opératoire pour chacun des conflits, on les résout un à un et on enregistre et quitte. Tant qu’il reste un fichier encore en conflit dans la liste, git relance l’outil de gestion de fusion sur le fichier suivant qu’il convient de résoudre de la même manière. Dans un prochain article on traitera un exemple concret de ce cas de figure.]]>

Tuto Git – Modifications simultanées de fichiers sans conflit

Objectif: Ce 3eme article dans la série « Tuto Git » a pour objectif de montrer une séquence de travail simultané sur les fichiers du même projet par deux développeurs différents. Il traite les cas de modifications sans conflit. Pré-requis: Les deux articles précédents sur l’installation et l’utilisation de Git sont lus et les manipulations exécutées.

1. Modification de fichiers différents:

Bien entendu ce cas de figure ne génère jamais de conflit. La modification inclu l’ajout et la suppression de fichiers. On part de la situation de l’article précédent. DEV1 modifie le fichier hello.sh en ajoutant des lignes:
echo "Hello world !" >> hello.sh
echo "Hola todo el mundo !" >> hello.sh
echo "Ciao mondo !" >> hello.sh
Ensuite il crée un nouveau fichier hello.txt avec l’éditeur vi:
vi hello.txt
Ajouter les lignes puis enregistrer:
Ce projet permet d'afficher bonjour dans les langues suivantes:
Français
Anglais
Espagnole
Italien
Il valide ensuite ses modifcations et les envoi sur le serveur Git:
git add hello.txt
git commit -am "Ajout de 3 langues"
git push
Le paramètre -am de la commande git commit permet d’indexer en une seule fois les modifications en ajoutant le commentaire. DEV2 de son côté, supprime le fichier hello.doc, pour cela il execute:
git rm hello.doc
git commit -am "Suppression de hello.doc"
git push
La dernière commande (envoi vers le serveur) échoue, le message de retour est claire: la copie locale n’est pas synchronisée avec le serveur. Il faudra executer:
git pull --no-edit
Les modifications de DEV1 sont alors récupérées.
git push
Cette fois l’envoi réussit. A ce niveau DEV1 ne pourra plus rien envoyer (push) avant de synchroniser sa copie de travail (pull). En tentant de le faire il obtiendra le même message d’erreur. Il a toujours le fichier hello.doc en local:
ls -l
git pull --no-edit
ls -l
Après la synchronisation (pull), le fichier hello.doc disparaît.

2. Modifications simultanées d’un même fichier:

Dans la situation actuelle DEV1 et DEV2 ont des copies locales identiques et synchronisées avec le serveur. DEV1 modifie le fichier hello.sh en modifiant uniquement la première ligne (ancien contenu: « Boujour tout le monde ! ») qui devient: « Boujour monde ! »
git commit -am "Modification message Français"
git push
En même temps DEV2 modifie le même fichier hello.sh en modifiant la troisième ligne (ancien contenu:« Hola todo el mundo ! ») qui devient: « Hola mundo ! »
git commit -am "Modification message Espagnol"
git push
La commande d’envoi au serveur push échoue car la copie locale n’est plus synchronisée.
git pull --no-edit
cat hello.sh
Les deux modifications sont fusionnées car il n’y a pas de conflit entre les deux.
git push
Permet alors d’envoyer la modification vers le serveur. DEV1 devra exécuter la commande git pull pour récupérer la dernière version fusionnée.]]>

Tuto Git – Commandes de base de partage des sources

Objectif: Revue complète, à l’aide un exemple concret, des commandes Git de base de de partage des sources d’un projet par deux ou plusieurs développeurs d’application. Pré-requis: Git est installé et confiiguré sur un système GNU/Linx, cf. article 1 de la serie Tuto Git.

1. Mise en place d’un environnement de simulation.

Dans cette serie de tutoriels on utilisera la simulation suivante sur une même machine: – Côté serveur: le dossier /serveurgit – Côté clients: les dossiers /pcdev1  /pcdev2 .. Pour un suivi plus simple de ce tutoriel vous pouvez ouvrir une console pour chaque PC développeur simulé. Créer les trois dossiers nécessaires:
sudo mkdir /serveurgit
sudo chown login:login /serveurgit
 login: doit être votre login sur la machine utilisée. Faites la même chose pour les deux autres dossiers /pcdev1 et /pcdev2

2. Mise en place d’un dépôt de source sur le serveur.

Ce n’est pas dans l’objectif de ce tutoriel mais c’est une étape nécessaire pour la suite. Il s’agit d’une mise en place basique qui ne doit pas être utilisée dans la pratique. Sur le serveur (aller dans le dossier /serveurgit donc) créer un dépôt de source pour le projet “hello”.
cd /serveurgit
git init --bare hello.git
“hello” est le nom choisi pour le projet (généralement le nom de l’application développée), l’extension “.git” n’est pas obligatoire mais c’est une bonne convention qui permet de reconnaitre le type du dépôt. Cette commande crée un dossier hello.git/. C’est la première chose à faire si on veut commencer à gérer un projet avec Git.

3. Récupération d’une copie de travail locale.

Sur le poste de travail, donc dans le dossier /pcdev1 (cd /pcdev1):
git clone /serveurgit/hello.git
Cette commande “git clone” crée un dossier “hello/” dont le contenu est une copie locale du dépôt crée sur le serveur. Le paramètre de cette commande qui est un chemin sur le disque local, devrait être dans la réalité une URL tel que http://serveur/.. puisqu’il s’agit usuellement d’un serveur ditant.

4. Personnalisation de la configuration du projet.

A n’utiliser que si on souhaite avoir d’autres paramètres pour le projet que ceux configurés globalement dans l’article 1 de la serie.
cd /pcdev1/hello
git config --local user.name "DEV1"
git config --local user.email "DEV1@server.com"
Ces deux commandes modifient le nom d’utilisateur et son adresse email seulement pour ce projet.

5. Ajout d’un fichier au projet

echo '#!/bin/bash' > /pcdev1/hello/hello.sh
echo 'echo "Boujour tout le monde !"' >> /pcdev1/hello/hello.sh
C’est un script shell qui affiche un message de bonjour.
git status
On obtient un retour qui indique que le fichier nouvellement créée n’est pas suivi et nous suggère une commande qu’on va exécuter:
git add hello.sh
Maintenant ce fichier est suivi (ou indexé) mais ce n’est pas suffisant: il faudra le valider (commit) et ensuite l’envoyer au serveur. Avant cela ajoutons un fichier de documentation du projet:
echo 'Ce projet permet d'affichier bonjour dans plusieurs langues' > hello.doc
git add hello.doc
git status
Ce qui crée ce fichier et le rend suivi par git, la dernière commande le confirme. Maintenant on va publier ces ajouts en les envoyant au serveur:
git commit -m "Création du projet Hello"
git push
git status
Ceci valide les deux fichiers en même temps et envoi le tout au serveur, la dernière commande le confirme.

6. Partage du projet

Le projet étant désormais dans le dépôt du serveur, le dévelopeur 2 peut y avoir accès:
cd /pcdev2
git clone /serveurgit/hello.git
cd hello
ls -l
Ce qui permet de récupérer une copie de travail du projet sur le PC du 2eme développeur. Les deux dernières commandes permettent de s’assurer que le contenu est bien récupéré. Un peu plus d’information utile peut être obtenue par:
git log
Et à présent on comprend mieux l’importance de la configuration effectuée et du message ajouté lors de la validation des fichiers.]]>

Outils developpement (web)

Objectif: Ce tutoriel présente les outils developpement (web) disponibles gratuitement et à utilisation totalement libre par chacun. Il s’agit d’une présentation d’un ordinateur (de bureau) type qui pourrait servir efficacement à créer des logiciels à l’aide de ces outils.

1. Le materiel.

Un PC très récent (et donc coûteux) n’est pas forcément nécessaire pour programmer et créer des logiciels. Même un PC moyen de 2012 suffirait. En cas de besoin de puissance (IDE récent gourmand en ressources, développement nécessitant de faire tourner plusieurs processus en même temps ..), priviligier un processeur récent et la quantité de mémoire RAM (8 Go suffirait à la configuration la plus exigeante). Le reste des composants n’a pas d’importance dans la majorité des cas: ecran, carte graphique, disque dur.

2. Le système d’exploitation.

GNU/Linux Ubuntu fait parfaitement l’affaire. Il est gratuit et libre. Actuellement cet OS est simple à installer (article à venir) et configure toute sorte de materiel automatiquement. En même temps sur cet OS il y a tout ce qu’il faut comme outils gratuits et libres pour développer des applications sur toute sorte de technologies (cf. les différents articles de ce blog à titre d’exemple).

outils-developpement-webDémarrage de l’IDE Eclipse «neon» sur un système KUbuntu 16.04

3. Les outils developpement (web).

 ]]>