Archives par mot-clé : git

Simple Git

Capture du 2013-02-02 17:49:22
Git est connu pour apporter une nouvelle façon de penser le travail collaboratif. Lui et et sa bande de copains que sont les gestionnaires de sources décentralisés ont définis de nouvelles organisations comme le « Integration-Manager Workflow » ou « Dictator and Lieutenant Workflow ». Ces workflows définissent des responsables pour les étapes de merge libérant ainsi le développeur de cette tache.

Oui mais (parce qu’il en faut toujours un) lorsqu’on passe d’un outil centralisé comme Subversion à Git, on ne change pas toute l’organisation. La création des branches conservent le même rythme et chaque développeur n’aura pas son dépôt publique de si tôt. C’est une habitude purement centralisée avec des branches par version qui sont souvent conservé. Cet article se veut être le guide de survie du Git centralisé en résumant les commandes élémentaires et nécessaire de connaître.

  • git clone

C’est la première étape qui va vous permettre de cloner le dépôt à partir duquel vous souhaitez travailler.

git clone ssh://host:/mondepot
  • git checkout

Cette commande va vous permettre de sélectionner la branche dans laquelle travailler. En effet, c’est l’ensemble du dépôt que vous avez cloné et pas uniquement une branche.

git checkout branch-new-feature
  • git add

Vous venez de créer et modifier des fichiers dans votre espace de travail. La commande « add » va faire passer ces modifications dans l’espace de « staging ».

Il faut bien concevoir que lorsqu’on travail en local avec Git, on dispose de 3 espaces : l’espace de travail qui sont les répertoires et fichiers que nous manipulons directement, le dépôt qui est une copie du dépôt distant et qui enregistre les commits et il y a le « staging » (ou « index ») qui est une zone intermédiaire qui traque les fichiers qui vont faire parti du prochain commit

vi README
git add README
  • git commit

La commande ressemble à celle des autres gestionnaires de sources. Et elle fait la même chose, elle enregistre les modifications associés à un message dans le dépôt mais uniquement dans votre copie locale du dépôt.

git commit

Pour que le commit prenne en compte les fichiers modifiés dans votre espace de travail mais non transité dans l’index, vous pouvez utiliser l’option « -a » (attention, ça ne prend pas en compte les nouveaux fichiers uniquement les modifiés).

  • git push

Votre dépôt local a enregistré une série de commit et vous êtes satisfait de vos développements, il ne vous reste plus qu’à les envoyer sur le dépôt officiel avec cette simple commande :

git push

Git reprend la source de la commande c »clone » pour savoir où envoyer les commits enregistrés dans votre dépôt. Si d’autres commit ont été « pushés » avant vous sur le dépôt distant (à partir du moment où vous l’avez cloné), il faudra alors mettre votre dépôt à jour avant de pouvoir envoyer quoique ce soit.

  • git pull

C’est la commande qui permet de mettre à jour le dépôt local à partir du dépôt distant. Dans le cas le plus simple (vous n’avez pas de modification sur votre dépôt local), la commande rapatrie toutes les modifications du dépôt. Si des modifications locales il existe, deux modes de fonctionnement il existe :

  1. En invoquant la commande sans option, nous faisons alors un « pull » en mode « merge ». Lorsque les commits distants sont rapatriés sur votre dépôt local, un commit supplémentaire contenant le résultat du merge automatique est créé.
  2. En invoquant la commande avec l’option « –rebase », nous faisons alors un « pull » en mode « rebase ». Lorsque les commits distants sont rapatriés sur votre dépôt local, vos commits locaux sont déplacés au sommets des commits et comprennent le résultat du merge automatique

Dans les deux cas, si le merge automatique ne fonctionne pas, la commande « pull » signalera les fichiers en conflit. Comme avec Subversion les fichiers en question seront marqués avec des extraits de la version local et distante et ce sera à vous de résoudre le conflit. Une fois un fichier résolu, il suffit de l’ajouter dans l’index avec la commande « add ».

Une fois tous les conflits résolus, s’il s’agissait d’un « pull » en mode « merge » et il ne reste plus qu’à commiter le merge avec la commande « commit ». Sinon, c’était un « pull » en mode « rebase » et il faut terminer le rebase :

git rebase --continue

Dans le cas d’une utilisation en mode centralisé, je pense qu’il est préférable d’utiliser des « pull » en mode « rebase ». En effet, sinon le dépôt laisse apparaitre des commits de merge qui n’ont pas vraiment de sens puisqu’aucune branche n’a réellement été mergé (même si dans les faits votre dépôt local est considéré comme une branche par Git).

Besoin de quelques références sur Git :
http://git-scm.com/book
http://blog.octo.com/git-dans-la-pratique-22/

Git : Le commit qui fait mal

Imaginez-vous, un soir, vous êtes mal luné et vous remonté un fichier personnel qui vous a servi à faire vos tests dans votre gestionnaire de source. Les développements avancent. D’itération en itération, votre fichier personnel est trimbalé jusqu’au jour où arrive la livraison et que votre fichier personnel se retrouve dans le livrable de votre client.

Bon, c’est vrai, je pousse la caricature un peu loin. Si votre est arrivé jusque là, c’est qu’il n’avais pas tant d’importance que ça ce fichier. Ou alors, vous vouliez parfaitement illustrer mon propos à vos collègues. Dans ce cas, je ne peux que vous en remercier.

Toujours est-il que la trace de votre fichier sera toujours visible dans ce satané commit. Et les futurs développeurs de votre projet (dont vous serez peut-être le chef dans 5-10 ans) sera toujours accessible. Heureusement, je viens de tomber sur la commande magique de Git :

git filter-branch --tree-filter 'rm -f my_file' HEAD

Le fichier my_file aura alors disparu de tous vos commits. Et la prochaine fois, vous éviterez de mélanger le boulot avec votre vie personnelle.

 

Gitblit : premier commit

Gitblit est dans la place et j’en suis pour le moment très satisfait. Il faut dire qu’avec trois dépôts à usage personnel, je ne risque pas de créer des cas compliqués d’usage 😉
Cependant, une chose ne m’a pas paru intuitive. Lorsqu’on créé un dépôt tout neuf sans repartir d’aucun code existant, la commande push pour remonter mes commits ne semblait pas fonctionner correctement. En effet, avec les commandes ci-dessous :

git clone http://127.0.0.1:8080/gitblit/git/maintest.git
cd maintest
echo "TEST" > test.txt
git add .
git commit -a -m "Commit de test"
git push

Cette dernière commande n’a jamais rien affiché de plus qu’un magnifique :

Everything up-to-date

Et rien n’est pas apparu dans mon dépôt.

Après quelques essais, ce que je comprends, c’est lors de la création du dépôt par Gitblit, aucune branche master n’existe (ou du moins, elle n’est pas correctement associée à l’origin du dépôt). Pour remettre les choses en place, la simplissime commande ci-dessous suffit à remettre les choses en place :

 git push origin master

Après ça, la branche master locale est bien reliée à la branche master sur origin (donc sur notre serveur Gitblit).

Gitblit & Jenkins : l’authentification du risque

Tout récemment, je me suis amusé avec Gitblit et Jenkins. Je ne pensais vraiment rencontrer le moindre souci pour intégrer ces 2 outils (tellement ça me paraissait être l’état de l’art du développement). Oui mais en fait si, il y a bien quelques petits soucis. Pas grand chose me diront certain.

Gitblit est une application Web permettant de créer, organiser ses dépôts Git. Elle est assez jeune et très prometteuse je trouve car elle fonctionne out of the box (comme on dit). Nullement besoin d’installer un binaire git à côté de l’application ou un serveur HTTP pour que les développeurs accèdent aux dépôts. Toutes les couches de communications, la gestion des utilisateurs et la gestion des dépôts sont dans l’application Web.

Je ne présente plus Jenkins, l’outil d’intégration continue qui se charge d’extraire le contenu du gestionnaire de source, de builder, de tester, ….

Voici le problème (qui est une intersection de 2 problèmes) :

  • Par choix, je veux des dépôts qu’on peut librement cloner mais je veux en restreindre les push. C’est génial, c’est tout à fait faisable dans Gitblit. Aïe ! Oui on peut le faire mais le clonage n’est pas vraiment libre car il demande un compte. 1er problème
  • Jenkins a un plugin pour l’intégration d’un dépôt git. Super, je ne devrais pas avoir de problème particulier. Ah mais c’est pas possible, ils m’en veulent ! Impossible de saisir un login et un mot de passe pour accéder au dépôt. Qu’est-ce que c’est que ce plugin à moitié fini.

Résultat : mes dépôts sont en libre accès (ce qui n’est pas un problème pour moi car je suis le seul participant à mes projets) mais ça m’embêterait d’avantage dans une organisation plus conséquente en équipe.