Relire le premier billet ne serait d’ailleurs pas idiot puisqu’il y a eu quelques ajouts dans le tutoriel précédents (stashs, hooks, alias).

Système de version décentralisé vs centralisé ?

La puissance d’un modèle décentralisé à la git c’est justement qu’il n’est pas figé. En effet il peut aussi bien être utilisé avec un dépôt local unique, avec une multitude de dépôts locaux, ainsi qu’avec un dépôt central… ou la combinaison de tous ces modes, tandis qu’avec un dépôt central unique on ne peut changer de modèle. Si on rajoute la facilité d’utilisation et la rapidité des opérations, il n’y a plus de raisons d’aller voir ailleurs ! Bien sûr on pourra toujours critiquer les aspects de configurations à mettre en place pour un mode centralisé, mais quand on achète une Ferrari il faut aussi apprendre à la conduire.

Commandes de base

L’utilisation en mode centralisé est aussi simple, côté client, que l’utilisation générale de Git. Pour ainsi dire il n’y a que 4 commandes importantes :

• clone
• remote
• pull
• push

clone

git clone dépôt_distant [dossier]

Permet de récupérer un dépôt distant dans dossier. Les protocoles supportés sont : rsync, http, https, git, ssh, file. Les fichiers étant compressés et empaquetés un checkout est donc très rapide comparé à un svn qui va tout télécharger unitairement !
Par défaut la référence au projet distant sera « origin » (voir remote).

Remote

Cette commande permet de gérer les dépôts distants :

Lister les références aux dépôts distants :

git remote [-v]

Ajouter la référence nom à un dépôt distant. Dans le cas de clone, origin référencera le dépôt distant :

git remote add nom dépôt_distant

Supprimer une référence

git remote rm reference

Renommer une référence :

git remote rename ancienne_ref nouvelle_ref

Modifier une référence

git remote set-url reference nouvelle_adresse

Afficher les informations d’une référence

git show reference

pull

git pull [--rebase] reference branche

Cette commande est équivalent à un checkout de svn. On va récupérer l’état actuel de la branche distante. Le paramètre ‘reference’ est la référence que nous avons manipulé avec la commande remote. Par défaut on utilise origin. Après le pull il y a un merge automatique, sauf avec l’option –rebase qui permet de revenir à la version exacte du serveur (équivalent à un reset –hard de la version sur le serveur).

push

git push reference branch

git push –tags dépôt

Cette Commande est l’inverse de pull, elle permet d’envoyer ses modifications sur le serveur. C’est l’équivalent d’un checkin de svn.
L’option –tags permet d’envoyer la liste de tous tags locaux. Pour n’envoyer qu’un seul tag on procède comme suit :

git push reference tag NomDuTag

Cycle de vie des commandes

Un petit exemple vaut mieux qu’un long discours :

Initialisation

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux

ou

git init linux
cd linux
git remote add origin git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
git pull origin master

Ensuite on fait des modifications comme vu dans le tutoriel précédent avec la puissance d’un gestionnaire de version décentralisé.

Pour se resynchroniser avec le serveur :

git commit -a
git pull origin master

Puis on pousse nos modifications sur le serveur :

git push origin master

Simple non ?

On est mal barrés !

Les dépôts distants sont généralement crées avec l’option –bare et se terminent par .git

git init –bare dossier.git

Un dépôt de type « bare » est en fait un dépôt sans espace de travail (working directory), ainsi il n’y a pas directement les fichiers sources mais uniquement le contenu du dossier .git. Cela empêche l’utilisation de certaines commandes (git add, git rm, git commit …).

Supprimer une référence distante

Il peut être utile de supprimer à distance une branche ou un tag. Pour se faire il suffit d’ajouter « : » avant la référence à supprimer. En théorie lors de la spécification d’une référence on devrait la noter +ref_locale:ref_distante, donc si on omet la référence locale il y aura suppression. La syntaxe de git permet de se passer du « + » et du « : » comme dans l’exemple.

Supprimer un tag distant :

git push –tags origin :TagASupprimer

Supprimer une branche distante :

git push origin :MaBranche

Pour lister les références distantes, on utilise la commande :

git ls-remote [--heads] [--tags] reference

Exporter un dépôt sur le réseau

Le site http://www.jedi.be/blog/2009/05/06/8-ways-to-share-your-git-repository (in English, sorry) liste les différentes façons d’exporter les dépôts git.
La version maison est un démon intégré à git qui écoute sur le port 9418 par défaut, il va scanner les dossiers de sa liste blanche et s’il détecte le fichier « git-daemon-export-ok » dans le .git du dépôt, alors celui-ci sera exporté.

git daemon [--export-all] [--base-path=path][--user-path] [--reuseaddr] [directory…]

–export-all exporte tous les dépôts que le fichier « git-daemon-export-ok » soit présent ou non

–base-path permet d’indiquer le répertoire de base des dépôts

–user_path permet d’utiliser la notation ~user dans l’adresse de git clone

–reuseaddr permet de pouvoir se lier au port même s’il est déjà utilisé (après un crash en général)

On peut spécifier ensuite les répertoires de la liste blanche (en plus de –base-path). On peut utiliser un démarrage manuel ou un service comme inetd.

Contrôle d’accès au dépôt

Et bien c’est simple, git n’intègre pas de mécanisme de contrôle d’accès aux dépôts ! C’est un gestionnaire de version, il laisse donc ce travail à d’autres couches systèmes spécialisées. Mais ceci vient aussi du fait que le mode décentralisé est celui par défaut, donc si quelqu’un a fait une modification dans le code de Linux, il va demander à Linus de faire un pull de ses modifications. Dans ce schéma il n’y a pas besoin d’intégrer des mécanismes de sécurité divers et variés.
Néanmoins il existe des solutions.

• Pour http(s), on peut utiliser l’authentification intégrée (voir liée à un LDAP)
• Pour un système de fichier on a toute la gestion des droits intégrée au système (un peu lourd à mettre en place)
• Idem pour ssh, mais cela nécessite en plus de créer des comptes ssh sur le serveur

Néanmoins la solution la plus pratique est Gitosis. Avec Gitosis il n’est nécessaire de créer qu’un seul compte sur la machine « git », chaque utilisateur est authentifié par sa clé ssh (clé unique, authentification forte) et les dépôts peuvent avoir un accès lecture seule ou lecture/écriture.
Pour modifier la configuration de Gitosis, on fait un pull du projet gitosis-admin, on obtient l’arborescence suivante :

• keydir dossier qui contient les fichiers de clés ssh publiques (.pub) de tous les utilisateurs
• gitosis.conf fichier qui contient la configuration des dépôts

Ensuite modifications, commit, push comme vu plus haut.
Les dépôts contrôlés par Gitosis sont situés dans /home/git/repositories, mais rien n’empêche de faire des liens symbolique pour les stocker ailleurs.
Exemple de fichier de configuration :

[gitosis]
## Autoriser gitweb à montrer tous les dépôts
gitweb = no

## Autoriser git-daemon à publier tous les dépôts
daemon = no

[group quux]
members = jdoe wsmith @anothergroup
writable = repo1 repo2
readonly = repo3

[group anothergroup]
members = alice bill

[repo foo]
## Configuration par dépôt au lieu de la configuration globale pour gitweb (idem pour git daemon)
gitweb = yes

On définit des groupes avec des membres et les dépôts auxquels ils peuvent accéder en lecture seule ou lecture/écriture. La syntaxe de contrôle est inversée par rapport à ce qu’on a l’habitude de voir : un dépôt ne définit pas ses permissions, c’est un groupe qui définit ses accès.
Le seul défaut de Gitosis est que la granularité des accès se font au niveau du dépôt complet (y compris pour les tags). Pour avoir un contrôle plus fin on sera obligé de passer par des hooks (le hook update en l’occurrence) ou de se tourner vers Gitolite qui a un comportement identique avec la possibilité de définir précisément les droits d’accès.

Pour accéder à un dépôt on procède de la manière suivante :

git clone git@serveur:repo1

Tutoriel GIT by Grégory Soutadé est mis à disposition selon les termes de la licence Creative Commons Paternité-Partage des Conditions Initiales à l’Identique 2.0 France.

Présentation rapide

Développer en WebObjects se fait sous Mac OS X avec eclipse équipé du plug-in WoLips.
À l’origine WebObjects est développé et maintenu par Apple. Toutefois ils sont assez lents à apporter des mises à jours notamment pour correspondre aux besoins du web moderne comme par exemple des composants Ajax. Pour combler ces manques, le projet Wonder a été créé. Celui-ci est OpenSource et propose non pas d’être une surcouche à WebObjects (dans le sens couche logicielle par dessus une autre) mais remplace la plupart des classes du framework par un équivalent qui dans la plupart des cas hérite du composant d’origine. En clair, vous n’allez plus utiliser un WOTextField mais un ERXTextField, qui hérite de WOTextfield et lui ajoute quelques nouveautés.

De ce que j’en sais, il est possible de développer en WebObjects sous Windows mais Apple ne le supporte pas … Je n’aborderais pas ce point mais si quelqu’un a l’expérience de développement WO sous Windows, libre à lui de laisser un commentaire.

Une version imprimable de ce tutoriel est disponible au format PDF.

Base de données

Le développement en WebObjects se fait généralement au dessus d’une base de données. Assurez vous donc d’en avoir une d’installée sur votre machine.
J’ai personnellement fait le choix d’utiliser MySQL 5.1 avec le MySQL GUI Tools pour l’administrer. Certains puristes vous orienteraient plutôt vers Frontbase, je n’entrerais pas dans le débat.

Pour cette partie je vous laisse faire, vous disposez qui plus est peut-être déjà d’une base de donnée sur votre machine donc autant l’utiliser. Il suffira de s’adapter dans les prochains tutoriels lors de la configuration de la base de données, ce qui n’est vraiment pas difficile.

Eclipse

Comme vous pourrez le voir sur le site de la WO Community la version 3.5 d’eclipse n’est pas vraiment recommandée pour faire du développement WebObjects. Orientez vous donc vers la version 3.4 et de préférence en version développement J2EE notamment pour la gestion de ant et d’autres parties bien pratiques. Vous trouverez l’archive d’eclipse sur cette page: eclipse ganymede.

Quelques conseils à propos de eclipse. Dès que vous l’avez installé, rendez vous dans le menu des Préférences afin d’y effectuer quelques changements:

• dans General > Workspace mettez l’encodage du texte par défaut sur UTF-8
• dans General > Workspace toujours mettez la fin de ligne sur Unix, c’est à dire ‘\n’
• dans General > Keys assignez un raccourci qui vous convient pour « Content Assist » (qui affiche l’aide pour auto-complétion)
• dans General > Keys assignez un raccourci qui vous convient pour la génération de Getter et Setter, c’est plus pratique pour travailler vite

Pour le reste, je vous renvoie à mon billet sur les raccourcis claviers, sections General et Eclipse.

WebObjects

Sauf indication contraire, je vous oriente vers la version 5.4.3 qui est disponible à cette adresse. Si vous utilisez Mac OS 10.5 il est possible que vous ayez une version récente d’installée. Pour les utilisateur de la 10.6 dite Snow Leopard, WebObjects n’est plus installée par défaut. Utilisez donc le lien que je viens de fournir.

Wonder

Vous trouverez les fichiers nécessaires au bon fonctionnement de Wonder sur leur site officiel. Prenez le fichier Wonder-latest-Frameworks suivi de la version de WebObjects que vous avez choisi (5.3 ou 5.4).
Une fois l’archive récupérée et décompressez, déplacez tous les dossiers .framework vers /Library/Frameworks. Félicitation, vous avez installé Wonder.

WOLips

Maintenant qu’eclipse est correctement installé, il est temps d’ajouter le plug-in WOLips.
Celui ci est très simple à installer. Direction le menu « Help » puis « Software Updates… » tout en bas du menu. Ouvrez le panneau « Available Software » et repérez à droite le bouton « Add Site… ».

L’adresse du dépot est la suivante: http://webobjects.mdimension.com/hudson/job/WOLipsStable/lastSuccessfulBuild/artifact/site/
Une fois  le nouveau dépot disponible, déroulez le et choisissez dans Standart Install les paquets WOLips, WOLips Base, WOLips Goodies Mac et WOLips Third Party Feature. Cliquez sur Install, acceptez le contrat de licence et à la fin de la barre de progression, eclipse vous indiquera qu’il souhaite redémarrer. Une fois cela fait vous disposez à présent de la Perspective « WOLips », et vous pouvez créer un projet de type « WebObjects Application » ou « Wonder Application ».

Félicitations

Vous venez de terminer l’installation de votre environnement de travail pour attaquer le développement sur WebObjects.
Le prochain tutoriel abordera la création de mon premier projet, son premier model et la mise en place d’une première page.

Vous vous lancez dans un petit projet perso ? Vous aurez toutes les clés en main pour que GIT soit votre gestionnaire de versions sur ce projet.

Cet article ne se veut pas exhaustif mais reflète le résultat d’un usage quotidien par un autodidacte. Si vous souhaitez corriger une éventuelle erreur ou partager une connaissance, n’hésitez pas à laisser un commentaire.
Il est recommandé pour la bonne compréhension de cet article de connaitre SVN.
L’auteur du tutoriel est un utilisateur Linux et certaines commandes peuvent poser problème sur d’autres système (notamment gitk).

Note à nos amis sous Windows: vous pouvez utiliser git sur Windows à l’aide de msysgit disponible ici.

Tout d’abord qu’est ce que git ?! Et bien avant d’être un logiciel de gestion de versions décentralisé (ou DSCM pour Distributed Source Code Management) il a été conçu comme un système de fichiers avec un système de versionning, le tout construit pour la performance. Et quoi de plus normal quand on sait qu’il était destiné à être le système de gestion de versions du noyau Linux en remplacement de BitKeeper. Git a été écrit par Junio Hamano et Linus Torvald lui même. Bref on a entre les mains un gros bébé, pourtant simple à utiliser et performant : tout est instantané !
On entend par décentralisé le fait de pouvoir « commiter » et faire évoluer un bout de code en local indépendamment d’un serveur central (contrairement à svn qui nécessite un serveur central), cela offre un confort de développement très important car on ne commite que ce qui marche VRAIMENT. Bien sûr on a tout le loisir de travailler avec un serveur central, il est même possible de faire des ponts avec un serveur svn, mais l’aspect collaboratif ne sera pas abordé ici.

Comme pour svn, chaque commit donne lieu à une nouvelle version (ou révision). Git a choisit non pas d’utiliser des numéros de révision, mais un identifiant unique SHA-1 pour chaque commit (donc révision). Cela évite d’avoir des conflits entre les différentes révisions de toutes les branches de tous les clones du dépôt. Il n’est pas toujours nécessaire d’indiquer le SHA-1 complet d’un objet, mais seulement les premiers octets qui le différencie des autres objets. Si j’ai deux commits :
3bdc6feaa01b6b86a0f94acab32bc3ad4c207a5d
3bdc4d695b90545c891392a486da9a9e07c053b
je peux identifier le premier avec 3bdc6 et le second avec 3bdc4

Chaque commande git peut être appelée de deux manières différentes :

git commande

Après ces petites notions théoriques passons à la pratique !!

Par où qu’on commence ?

Et bien pour commencer il faut initialiser ou récupérer un dépôt. Avant d’initialiser un dépôt il faut renseigner quelques variables permettant de vous identifier lors des commit. Donc :

git config –global user.name Grégory
git config –global user.email greg@wordpress.com
git config –global core.editor emacs
mkdir MonDepot
cd MonDepot
git init

L’avant dernière ligne est importante si vous ne savez/voulez pas utiliser vim comme éditeur de messages lors des commits. Un joli fichier ~/.gitconfig contiendra votre configuration pour les projets suivants. Si vous omettez le –global, les informations ne seront inscrites que pour le dépôt crée.

Il est aussi possible de récupérer un dépôt git déjà existant depuis : ssh, système de fichier local, internet (http://, ftp://, git://) :

git clone soutade@monserveur:/mondepot mondepot
git clone /mon/de/pot mondepot
git clone http://www.kernel.org/mondepot
…

Et maintenant qu’on a un beau dépôt ?!

Et bien il faut faire des opérations sur les fichiers :

Modification

emacs MonFichier.c

Ajout au dépôt

git add MonFichier.c

Renomage du fichier

git mv [-f] MonFichier.c MonFichier2.c

Si vous ne passez par cette commande, git considère que le fichier aura été supprimé et il faudra faire un git add sur le nouveau fichier.
-f pour forcer le rennomage (si le fichier existe)

Suppression

git rm [-f] [--cached] MonFichier.c

Si vous ajoutez l’option –cached, le fichier sera uniquement supprimé du gestionnaire de versions, mais pas du système de fichier.

Oui, mais maintenant ça compile !

Si ça compile, c’est que ça marche (…). Bref il est temps de commiter ! Mais avant j’effectue toujours deux opérations :

git status

Cela permet de voir les fichiers ajoutés/supprimés/modifiés, voir si on n’a rien oublié (un nouveau fichier par exemple). « Untracked files » correspond aux fichiers qui existent mais qui ne sont pas (encore) pris en compte dans le gestionnaire de versions.

git diff [--color]

Avec cette opération on peut visualiser les modifications (au format « patch ») effectuées sur nos fichiers, cela va nous aider à renseigner le message du commit.

Cette commande peut prendre plusieurs options :

git diff [--color] [<commit1>..<commit2>] [--] [paths]

et toutes les options de diff

<commit1>..<commit2> est un intervalle de commits, sachant que <commit> peut être désigné sous la forme :

• le SHA-1 d’un commit
• le tag
• une référence depuis le commit courant

paths correspond à n fichiers

Apparté : Le commit courant

Dans git, le commit courant (ou dernier commit avant modifications) s’appelle HEAD. On peut accéder aux commits précédents en les référençant par rapport à HEAD :
HEAD^ : Père du commit courant
HEAD^^ : Grand père du commit courant
HEAD~n : ancêtre de nième génération de HEAD (grand grand … grand parent de HEAD)

Apparté : .gitignore

.gitignore est un fichier à créer dans le dépôt git pour ignorer un certains nombre de fichiers (dans git status). Par exemple tous les fichiers « MonFichier~ » crées par emacs. A chaque ligne on intègre une expression régulière pour le ou les fichiers à ignorer (*~ pour emacs):
Si la ligne fini par /, cela désigne un répertoire et tous ce qu’il y a dessous.
Si la ligne commence par !, on a la négation de l’expression.
Si la ligne est vide ou qu’elle commence par #, elle est ignorée.

Étant donné qu’on ne va pas re créer ce fichier pour chaque dépôt, on peut en spécifier un qui sera réutilisé à chaque fois (qui peut être composé avec un .gitignore interne au dépôt). Pour cela il faut créer un fichier quelconque avec les même règles que .gitignore et inscrire la variable globale core.excludesfile :

git config –global core.excludesfile CheminFichier

Attention toutefois, le chemin ne supporte pas ~ (Référence à la racine du répertoire personnel).

Et le tant attendu :

git commit [-a] [-m « message »] [paths]

L’option -a (recommandée) permet d’ajouter toutes les modifications au dépôt, sinon il faut spécifier les fichiers dans paths ou faire explicitement un git add (même sur des fichiers modifiés) pour chaque fichier à intégrer au commit.
Si vous ne précisez pas le message sur la ligne de commande (-m), un éditeur va s’ouvrir (vim par défaut) pour que vous entriez le message du commit. Le message du commit est obligatoire !

Si Bob s’est trompé dans son message de commit, il est toujours possible de le modifier avec :

git commit –amend -c <commit>

Un peu d’histoire

Maintenant qu’on a fait plusieurs commits et que notre projet grossi il peut être intéressant d’avoir un résumé de l’état du projet. Pour cela deux commandes :

git log [options] [<commit1>..<commit2>] [--] [paths]

Liste des commits avec leurs message influant sur les fichiers paths.

git show [options] <commit> [--] [paths]

Contenu de tous les fichiers modifiés ou seulement ceux dans paths.
Les options sont celles de git diff.

En ligne de commande la visualisation n’est pas aisée, c’est pourquoi je recommande l’utilisation de la commande gitk qui permettra d’avoir une vue graphique et synthétique du dépôt.

Eh Bob, j’ai une idée !

Oui, mais les idées de Bob c’est pas toujours terrible, heureusement git permet de créer FACILEMENT des branches, pas besoin d’appeler la gconf et d’imputer sur le budget du projet déjà en déficit …
Bref pour créer un branche :

git branch NomDeLaBranche [BrancheInitiale]

Et voilà la branche est crée à partir de HEAD ou de BrancheInitiale.

ATTENTION vous êtes toujours dans la branche de départ, pour pouvoir changer de branche il faut faire un :

git checkout NomDeLaBranche

Pour récupérer uniquement un fichier d’une autre branche :

git checkout AutreBranche paths

Ces deux actions peuvent être combinée en :

git checkout -b NomDeLaBranche [BrancheInitiale]

Bon ben en fait Bob il a des idées toutes pourries, suppression de la branche :

git branch -d NomDeLaBranche

ATTENTION la branche sera détruite sans confirmation, toutes les modifications seront perdues et il ne sera pas possible de les retrouver !!

On peut lister les branches avec :

git branch

Pour voir le contenu d’un fichier d’une autre branche :

git show MaBranche:MonFichier

Oui, mais mon idée était beaucoup plus classe que celle de Bob, je vais donc l’intégrer dans la branche principale (master) :

git checkout master
git merge MesBranches

(on peut merger depuis plusieurs branches)
S’il n’y a pas de conflit, l’opération est commitée (sauf option –no-commit).

Ah il y a un conflit que git n’est pas capable de résoudre: il nous l’indique et il faut le résoudre  manuellement. Le fichier accusé sera de la forme :

<<<<<<< HEAD:test.c
printf(« Hello world 2\n ») ;
=======
printf(« Hello world 1\n ») ;
>>>>>>> test:test.c

HEAD, c’est la branche actuelle ! test est ici une branche de test. Le fichier en conflit sera affiché dans git status comme unmerged.

Pas très lisible ?  On peut voir séparément les différences introduites par les deux commits sur le fichier en conflit :

git log –merge -p test.c

Une autre option très pratique pour choisir entre telle et telle version quand on est fainéant et qu’on n’a pas envie de tout éditer à la main (de toutes façons c’est ma version la meilleure) :

git show :z:test.c

où z correspond à :

• l’ancêtre commun des deux branches
• branche actuelle
• branche distante

Qui montre la version z du fichier test.c. On redirige ensuite la sortie dans le fichier test.c

Ne pas oublier de commiter les changements introduits par le merge (en cas de conflits) !

On a enfin une version stable !!

Il est possible de la tagger pour avoir une référence un peu plus explicite que son SHA-1.

git tag MonTag [<commit>]

Par défaut HEAD de la branche courante. Un commit peut avoir plusieurs tags.

Ah, en fait non, Bob avait laissé un buffer overflow, supprimer un tag :

git tag -d MonTag

Ouais, en fait la v1 c’était le top. Il est possible de revenir à une version précédente (et heureusement) via trois techniques.

Je m’appelle Rambo et rien ne me fait peur

git reset [--mixed | --soft | --hard] [<commit>]

Ici on revient à un commit précédent en SUPPRIMANT tous les commits suivants
–mixed : les changements n’affectent que le gestionnaire de versions et pas le système de fichier
–soft : On revient simplement au commit <commit> au niveau du gestionnaire de versions, mais les fichiers ne sont pas changés sur le disque (un prochain commit n’effacera pas le commit suivante [i.e qu'on a reseté])
–hard : Le gestionnaire de versions et les fichiers sur le disque se retrouvent en position <commit>, les commits suivants sont perdus.

Méthode propre

git revert <commit>

Cette méthode est « propre » car elle permet de conserver les changements introduits (même si on veut s’en séparer) en introduisant un commit faisant le travail inverse de ce qui a été cassé.

Méthode pour un ensemble restreint de fichiers

git checkout <commit> paths

Cela permet de retrouver ponctuellement un fichier d’une ancienne version.

J’te jure ça marchait et j’ai rien touché !

12 commits ont été réalisé pendant que vous étiez en vacances et maintenant plus rien ne compile (Bob ??). Bref, git offre un mécanisme très puissant pour identifier le commit qui a tout fait planter : bisect ! On va pouvoir faire une recherche semi-automatique voir même automatique du commit fautif, git se chargera tout seul de mettre l’espace de travail tel qu’il était à chaque commit (sinon il aurait fallu jouer avec reset/revert).

On commence par démarrer une session de bisect en identifiant le point où ça bloque (en général HEAD) et le point où on est sûr que c’était bon:

git bisect start [<commit-bad>] [<commit-good>]

Puis on va identifier les différents commits (la recherche est dichotomique, c’est à dire qu’il prend toujours le commit intermédiaire dans l’intervalle good-bad afin de trouver au plus vite la version responsable du problème) avec :

git bisect bad
git bisect good

Chaque appel de cette commande « tag » le commit avec good ou bad et passe au commit suivant jusqu’à tomber sur le fautif (ou qu’on en ais marre). Si on sait qu’un commit (ou un intervalle de commits (ie : v1..v2)) est bon par avance on peux l’ignorer avec :

git bisect skip [<commit>[..<commit>]]

good et bad ne sont que des marqueurs, il appartient ensuite au développeur d’effectuer les actions pour retrouver un environnement correct/stable/sans bugs. On peut visualiser l’état des marqueurs (dans gitk) avec :

git bisect visualize

Une fois qu’on a fini le boulot on peut revenir au point de départ (effacer les tags et retour à HEAD) avec :

git bisect reset

Il est possible d’enregistrer toutes les opérations (ou au moins les « visualiser ») avec :

git bisect log

Et on peut ensuite les rejouer avec :

git bisect replay <fichier créée par git bisect log>

Mais là où git est très intéressant c’est avec le mode tout automatique :

git bisect run cmd

cmd est une commande (ou un script) qui va être appliqué sur tous les commits entre bad et good et qui va les marquer selon son code de retour :

• 0 : good
• 125 : skip
• autre : bad

Une fois qu’on a le commit fautif on peut savoir exactement qui a fait quoi dans le fichier qui a fait que et quand il l’a fait :

git blame <paths>

Ce qui donne quelque chose comme :

1692b633 (Grégory 2009-09-19  1 ) #include <stdio.h>
1692b633 (Grégory 2009-09-19  2 )
1692b633 (Grégory 2009-09-19  3 )
1692b633 (Grégory 2009-09-19  4 )
1692b633 (Grégory 2009-09-19  5 ) int main()
1692b633 (Grégory 2009-09-19  6 ) {
795a06c9 (Grégory 2009-09-29 7 )   printf( « Hello world\n » ) ;
1692b633 (Grégory 2009-09-19  8 )
1692b633 (Grégory 2009-09-19  9 )   return 0 ;
1692b633 (Grégory 2009-09-19 10) }

Ça fait stash !

Vous êtes tranquillement en train de travailler sur l’ajout d’une fonctionnalité révolutionnaire quand Bob vous apprend catastrophé qu’il a trouvé un bug terrible dans le projet et qu’il faut le corriger dans la seconde. On peut bien évidement créer une branche pour reporter les modifications et merger par la suite d’une manière plus ou moins élégante, mais git introduit un concept très intéressant : le « stash ». Cela permet de mettre les modifications en cours dans une pile et de revenir à la dernière version (~ git reset –hard HEAD), faire les bonnes modifications, commiter et retrouver son espace de travail.

Créer le stash (éventuellement avec un message) :

git stash [save [message]]

Voir la liste des stashs :

git stash list

Récupérer les modifications du stash et le supprimer de la liste des stashs :

git stash pop [stash]

La syntaxe des stashs est : stash@{0}

Le stash le plus récent est toujours 0. Si aucun stash n’est précisé, le plus récent est celui par défaut

Voir les modifications du stash :

git stash show [stash]

Appliquer les modifications d’un stash sans le supprimer de la pile :

git stash apply [stash]

Supprimer tous les stashs :

git stash clear

Supprimer un stash sans l’appliquer :

git stash drop [stash]

Hooks

Les hooks sont des scripts appelés durant l’exécution de certaines tâches, ils se trouvent dans le répertoire .git/hooks. Cela permet de contrôler/valider certaines actions. Si la valeur de retour du script est différente de 0, alors l’action ne sera pas exécutée. Git propose les hooks suivants :

pre/post commit

[prepare-]commit-msg : invoqué lors de la création du message dans git commit

pre-rebase : invoqué avant un git rebase

post-checkout : invoqué après un git checkout

post-merge : après un merge et/ou un pull

pre/post receive : invoqué (sur le serveur uniquement) lors d’un git push

update : invoqué (sur le serveur uniquement) lors d’un git push

post-rewrite : invoqué lorsque le message d’un commit est modifié (git commit –amend ou git rebase)

Pour les différents paramètres que prennent les hooks, voir le man. Des exemples se trouvent dans le dossier (les .sample). Pour qu’un hook soit pris en compte il faut enlever l’extension .sample (attention à ne pas oublier les droits en exécution).

Git, mon couteau Suisse

Quelques commandes supplémentaires :

Exporter les sources du projet (sans le .git)

git archive –format=[tar|zip] –output=File <commit> [paths ...]

Appliquer un/des patch(s)

git apply <patchs>

Supprimer les fichiers qui sont dans le dépôt, mais pas dans le gestionnaire de versions (untracked files) :

git clean [-d] [fichiers]

Si l’argument fichiers est renseigné, seuls ces fichiers là seront supprimés.
-d : Supprimer aussi les dossiers

Optimiser le dépôt local pour de meilleures performances (à faire de temps en temps)

git gc

Pour aller plus loin

La documentation de git (en pages man) est très bien faite, il y a deux solutions :

git help command

Toutes les options pour les commandes présentées n’ont pas été spécifiées ici, je vous recommande donc pour certaines tâches spécifiques d’aller voir le man.
L’aspect travail collaboratif (pull, push, rebase) n’a pas été abordé, si vous êtes curieux il y a d’autres documentation qui en parlent (peut être pour une prochaine version de ce tutoriel).

Pour savoir pourquoi git est le meilleur gestionnaire de versions du noyau : http://www.youtube.com/watch?v=4XpnKHJAok8

Le Terminal c’est bien, mais bon

Vous devriez maintenant être capable d’utiliser git en ligne de commande pour vos besoins personnels. Le terminal … ça va bien un moment mais on aime aussi avoir un client graphique un peu plus convivial qui fait le boulot pour nous ! Faisons un petit tour d’horizon des solutions existantes. Malheureusement, je n’ai pas pu tester ces solutions, libre à vous donc de vous faire une opinion sur l’état d’avancement et la fiabilité de chacun, n’hésitez pas à laisser un commentaire pour partager vos retours.

QGit: Client Qt4 (donc pour les utilisateur KDE principalement). Hébergé par SourceForce avec une dernière version datée du 9 Mai de cette année. De bons retours indiqués sur le site.

TortoiseGIT: Client Windows se voulant le remplaçant de TortoiseSVN. Nécessite l’installation préalable de msysgit.

GitX: Application pour Mac OS X.

GitNub: Autre application pour Mac OS X écrite en RubyCocoa.

EGit: Plug-in pour eclipse, malheureusement peu avancé. Si vous avez du temps et de la motivation, n’hésitez pas à participer.

Ressources

http://git-scm.com/

http://fr.wikipedia.org/wiki/Git

http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html
http://linux.efrei.fr/doku.php/tutoriaux/git
http://github.com/
http://www.unixgarden.com/index.php/administration-systeme/git-pour-les-futurs-barbus
http://www.unixgarden.com/index.php/administration-systeme/git-les-mains-dans-le-cambouis

Tutoriel GIT by Grégory Soutadé est mis à disposition selon les termes de la licence Creative Commons Paternité-Partage des Conditions Initiales à l’Identique 2.0 France.

Adobe Flex est un framework de développement de clients riches (ou clients lourds) compilé vers la machine virtuelle Flash. Pour les personnes connaissant Silverlight, Flex a inspiré Microsoft pour sa création. Les interfaces sont réalisées à l’aide d’un langage basé sur XML, le MXML (XAML pour Silverlight) et le comportement est écrit à l’aide du langage Action Script 3 (.Net pour Silverlight).
Il ne surtout pas considérer Flex comme un outil fait pour les designeurs, c’est un framework créé pour les développeurs.

Déploiement

Comme dit dans l’introduction, Flex est compilé dans un fichier SWF qui est lu par la machine virtuelle Flash. Pour lire une application Flex, la version 9 du plug-in est au minimum nécessaire, or plus de 95% des personnes répondent à ce besoin. C’est un point assez fort du framework, surtout en comparaison avec Silverlight qui peine à passer les 30% (toutes versions confondues).
Étant donné que Flex se base sur le plug-in Flash, vous bénéficiez également d’une compatibilité entre les différents systèmes d’exploitation et les différents navigateurs. Pas de mal de tête à assurer le même rendu entre IE6 sur Windows et Safari sur Mac, c’est le travail des gens d’Adobe.
Pas de doute ici, c’est un gros point fort et un très bon travail d’Adobe qui donne à Flex un avantage certain sur ses concurrents directs. On pourra également remarquer sur l’utilisation de Flash la mise à disposition d’une excellente librairie pour créer des animations de l’interface qui donnent un cachet très professionnel aux applications.

ActionScript et API

Le comportement et le business d’une application Flex est décrit dans le langage ActionScript 3. Pour le langage en lui-même, il est souple et propose un certain nombre de fonctionnalités puissantes et pratiques, je citerais en exemple la possibilité d’appeler une méthode sur une variable à l’aide de l’opérateur [] comme suit: maVariable["maMethode"].
En revanche on peut vraiment reprocher à Adobe la pauvreté de l’API. Pour l’anecdote, sachez que la méthode addAll permettant d’ajouter tous les éléments d’un tableau dans un autre tableau vient d’être implémentée dans la version 3.4 du framework … Sachez également que la gestion de dictionnaire est extrêmement réduite, impossible par exemple de récupérer l’ensemble des clés d’un dictionnaire …
Il est certes possible d’écrire soit-même toutes ses classes, mais d’une part on n’a pas forcément envie de coder toutes les classes de base lorsque l’on s’attaque à un projet ambitieux et d’autre part, si Adobe comble le manque un jour il faudra faire le remplacement partout.

Modèle MVC

A première vue, Flex semble proposer une bonne architecture pour respecter le pattern Modèle-Vue-Contrôleur avec les interfaces et leur comportement décrites en MXML, des classes de comportement et des classes de modèle. Cependant en pratique, on a rapidement tendance à mélanger la vue et le contrôleur. En effet il est possible d’écrire de l’ActionScript dans le fichier MXML et la tentation est grande d’y écrire le code business de la vue.

Quelques framework tentent d’imposer de bonnes pratiques (je citerais Cairngorn et Tide) mais ils ne sont pas toujours simple à mettre en place. En pratique il devient également difficile de maintenir du code propre au sein d’un projet de grande envergure. Le projet peut être découpé en modules qui sont chargés à la demande, mais on arrive assez facilement à des dépendances inter-modules ou de la recopie de code pour effectuer la même action dans deux endroits différents mais inaccessibles entre eux.

Asynchronisme et thread unique

Le plug-in Flash est presque mono-threadé. Je dis presque car en réalité un deuxième thread existe, qui attend les réponses aux requêtes effectuées vers des adresses externes. De cette situation ressort deux choses.

Toute demande de données est asynchrone. La demande est déposée vers le thread de communication qui propagera un évènement lorsque celle-ci sera complétée. S’il n’est pas dérangeant que vos données arrivent de façon asynchrone, pas de soucis mais dans le cas où vous aimeriez attendre d’avoir concrètement les informations, vous allez commencer à rencontrer des difficultés.

Il est impossible d’effectuer deux actions à la fois, cela incluant le dessin de l’interface ou le traitement d’un clic souris. Par conséquent, si vous lancez un traitement lourd de calculs, l’interface sera figée. Avantage en contrepartie, vous n’avez pas du tout à vous préoccupé de problèmes de validité des données entres threads ou de deadlocks, cela est impossible !

Bindings

Il est possible dans les interfaces MXML de réaliser des « bindings » entre une variable ActionScript et une propriété d’un élément graphique. Une fois le binding mis en place, la modification de la valeur de la variable entrainera la modification de la valeur de la propriété de l’élément graphique. Cela est très pratique puisque le mécanisme permet de réaliser à vitesse grand V l’écran de visualisation d’un objet Business en « bindant » sur ses différents attributs.

Dans la version 3 de Flex quelques embuches appaissent pour mettre en place des double bindings, c’est à dire que les modifications de valeur s’effectuent dans les deux sens. En effet, le premier binding mis en place aura pour effet d’effacer la valeur d’une des deux variables avec la valeur de l’autre. Dans le cas d’un objet business et un objet graphique, il vaut mieux effacer la valeur de la propriété graphique avec celle de l’objet business et non pas le contraire … Ce petit problème a été corrigé dans Flex 4 qui sortira prochainement.

Flex est un outil

En conclusion de l’article et avant de tirer avantages et inconvénient, j’aimerais donner un avis très subjectif sur le framework. Flex un outil jeune mais toutefois puissant pour développer rapidement les applications pour lesquelles il a été créé. Et je vais insister sur ce point.

A mon idée, Flex est parfait pour des applications simples, avec peu de code business. La manière classique de travailler va être d’appeler un WebService ou une page Web, parser les résultats pour remplir des variables sur lesquelles l’interface est bindée. Le résultat sera obtenu rapidement, propre, et joliment animée.

En revanche, Flex n’est pas fait pour une lourde application avec de nombreuses implications de code business entre les écrans et des grappes d’objets à récupérer, modifier, renvoyer, etc. Pour avoir tenté d’utiliser le framework pour ce type d’application, je peux dire qu’on passe plus de temps à lutter contre Flex qu’à lutter contre les difficultés de l’application elle-même.

Comme beaucoup d’autres framework, Flex est un outil. Flex est un tournevis cruciforme. Si votre application est faite de vis cruciformes, ce sera un excellent outil et vous allez aboutir rapidement à un résultat de qualité. Si en revanche vous devez fabriquer une chaise avec des clous, vous êtes condamné à taper sur les clous avec le manche, et au final vos clous seront plantés de travers, votre chaise sera bancale et s’effondrera à la troisième personne qui tentera de s’assoir dessus et enfin vous vous serez fait mal à la main.

Mais assez parlé et voyons le bilan avantages/inconvénients

Avantages

• Compatibilité OS/Navigateur
• Plug-In flash très répandu (95%)
• Animations simple à utiliser et très classes
• Pas de problématique de programmation concurrente
• Mécanisme de binding très pratique

Inconvénients

• Inconvénients de Flash (vous devriez les trouver facilement sur d’autres sites)
• Pauvreté de l’API ActionScript
• Trop grande facilité de mélanger Vue et Contrôleur
• Impossibilité d’utiliser la programmation concurrente
• Obligation de récupérer les données de façon asynchrone
• Doubles bindings laborieux (résolu normalement dans Flex 4)

WebObjects est un framework initialement développé en Objective C par la société NeXT de Steve Jobs qui sera ensuite rachetée par Apple. Il est constitué d’une couche basse d’abstraction de la base de donnée appelée EOModel, d’une architecture de gestion de cache et de persistance et d’un moteur de template. WebObjects passera progressivement d’Objective C à Java vers l’an 2000. Bien que différents par de nombreux points, il est comparable aux technologies J2EE.

Je tiens à signaler que mes commentaires sont faits sur la version 5.3 de WebObjects et je ne sais pas si certaines choses n’ont pas été corrigées en version 5.4.

Coût de formation et cadre de développement

Soyons assez clair, le coup d’entrée de WebObjects est assez élevé. Le framework a été pensé pour réaliser des projets d’entreprise et vous ne pourrez pas sortir une page de démonstration en moins d’une heure comme le proposent des plateformes de développement comme Google App Engine. En revanche, une fois formé à l’architecture logiciel vous disposerez d’un cadre de programmation assez stricte dans la forme, mais souple dans les possibilités. Comprenez que vous pourrez faire à peu près n’importe quoi, mais pas n’importe comment. À mon sens, c’est un avantage puisque vous êtes à peu près certain que les personnes utilisant WebObjects vont travailler relativement proprement, contrairement à d’autres technologies où il est possible de faire tout et n’importe quoi, surtout n’importe quoi.

Tenue de charge et modularité

WebObjects est designé pour être capable de gérer de grandes charges, aussi les données sont toujours chargées progressivement au moment où elles sont réellement nécessaires. Au niveau du fonctionnement lui-même, le framework est construit autour de dictionnaires de données. Par exemple pour les attributs d’un objet, les getters vont simplement chercher la valeur dans un dictionnaire à partir du nom de l’attribut. C’est de ce mécanisme que vient toute la souplesse de WebObjects puisqu’il est possible de faire évoluer dynamiquement le modèle pendant l’exécution. Même si les occasions d’utiliser une telle possibilité sont assez rares, elles sont quasiment impossible à réaliser autrement.

Mélange d’API

Comme je l’ai dis dans mon introduction, WebObjects reposait initialement sur le langage Objective C, mais a été migré vers le langage Java depuis plusieurs années maintenant. Cependant les choix qui ont été faits me laissent quelque peu sceptiques. En effet afin que les personnes ayant travaillé avec l’Objective C ne perdent pas leurs connaissances acquises, les classes de  base de NeXT ont été portées en Java. Un ingénieur d’expérience sur l’API Java sera donc un peu perdu face aux NSArray, NSMutableArray et autres NSDictionnary. Pire encore, ces classes implémentent des interfaces de l’API Java, mais n’implémentent pas les méthodes qu’elles apportent, se contentant de propager une exception ! Assez perturbant donc et pouvant se révéler source de surprises.

[MISE A JOUR]
On me signale que le problème des exceptions sur les méthodes ont été corrigé en version 5.4 sauf dans les cas où il y avait une raison. Je m’explique, en WebObjects il éxiste deux types de tableaux, les NSArray en lecture seul et les NSMutableArray en lecture écriture. Bien évidemment la méthode ADD n’a aucun sens dans un NSArray qui ne supporte que des GET. En revanche la méthode ADD ne NSMutableArray ne demande plus d’utiliser à la place la méthode addObject.
Il reste toutefois que quelqu’un ayant utilisé un certain temps les classes de la JRE de base, ArrayList et autres, aura besoin d’un petit temps d’adaptation.

Trouver des personnes

Abordons finalement un point assez critique: les ressources. Il sera difficile à la plupart des personnes ayant des années d’expérience sur des plateformes J2EE de se former à WebObjects en raison des différences conceptuelles et à l’API s’écartant de celle de Java. Le coup de formation est assez élevé et l’intégration à des processus d’entreprises comme Maven, bien qu’existant, peut s’avérer coûteuse en temps.
En comparaison d’autres framework, WebObjects souffre d’une très faible documentation. Le site d’Apple propose une documentation technique, mais très peu d’autres sites proposent des exemples ou des explications différentes de la version officielle. On se retrouve donc facilement le bec dans l’eau devant un problème dont la solution n’est pas documentée sur le site d’Apple. Une solution existe: la mailing list qui est fréquentée par des experts de la technologie, mais on ne peut évidemment pas abuser et questionner ces personnes en permanence.
Il est très profitable d’avoir au sein de son entreprise une personne expérimentée en WebObjects donc, cependant il s’agit d’une ressource rare. Lors d’un recensement récent, 800 développeurs ont été dénombrés dans le Monde, dont 40 en France. Autant dire qu’il est difficile de se procurer un « expert » dans le domaine, sachant que connaissant la technologie, je ne me considère pas du tout comme un expert, mais un simple utilisateur.

En conclusion, voici un petit récapitulatif de ce billet en avantages/inconvénients.

Avantages

• Framework avec architecture
• Développement propre
• Flexible
• Pensé pour tenir la charge

Inconvénients

• Peu de ressources et très peu d’experts
• Mélange d’API Java/Objective C
• Manque de documentation tierce

Heureusement, quelques personnes comme fnicollet aident la communauté avec un site web d’une très bonne qualité. Le site Adobe Flex Tutorial comporte en effet des explications sur un très grand nombre de classes du framework et propose notamment des exemples différents de ceux de la documentation officielle. Convenant aux utilisateurs avancés recherchant précisément l’utilisation d’un composant, le site peut également tout à fait convenir à un débutant souhaitant découvrir Flex.

Adobe Flex Tutorial

On trouve des informations de base telles que l’utilisation de l’environnement de programmation ou les principes du langage Action Script 3. Sont documentés également des fonctionnalités spéciales du framework comme les états, les transitions et les validateur, et enfin il est possible de consulter des exemples d’utilisation de très nombreux composants, des plus basiques au plus avancés. L’auteur du site fait actuellement un gros travail sur le très complexe composant AdvancedDataGrid.
Je tenais à faire découvrir ce site aux personnes ne le connaissant pas, et j’aimerais aussi féliciter son auteur pour son travail s’il venait à passer par ici ! Voilà maintenant un an que je travaille avec Flex et j’ai arrêté depuis bien longtemps de compter mes visites sur ce site pour trouver l’information qu’il me fallait.

Notons également dans le même genre de site mais en anglais cette fois le site Flex Examples qui a commencé à publier un bon nombre d’articles sur Flex 4.