WikiBR - Contributions [fr]

Git

2013-02-14T17:19:47Z

Arthur :

{{menu Root Toolbox}}

Git est un [[VCS|système de contrôle de version]]. Assez proche de [[SVN]] par certains côtés, il présente néanmoins un grand nombre de différences.

Avant de découvrir les spécificités de Git, il est nécessaire de connaître les concepts généraux des [[VCS|systèmes de contrôle de version]].

Cette page donne un bref aperçu des fonctionnalités de Git. Un autre bon aperçu est disponible [http://giudoku.sourceforge.net/media/GitHandbook.pdf ici] (lien non BR)

Une cheatsheet est également disponible [http://ndpsoftware.com/git-cheatsheet.html ici], c'est un bon aide mémoire.

== Dépôts ==

Alors que [[CVS]] et [[SVN]] sont des systèmes de versionnement centralisés (i.e un serveur contient le dépôt, et chaque utilisateur effectue un ''checkout'' depuis ce dépôt), Git est complètement décentralisé. Cela signifie que chaque contributeur a sa propre copie locale de tout l'historique d'un projet. Si aujourd'hui vous considérez que l'espace disque sur votre ordinateur est un problème, allez faire un tour, partez admirer les merveilles de la technologies qui nous entoure, et revenez demain. Sur cette page, tous les examples sont tirés du Git de [[Frankiz]], mais voici d'autres dépôts bien utiles :
* [http://www.github.com/ GitHub]
* [http://git.frankiz.net/ Frankiz]
* [http://git.polytechnique.org/ Polytechnique.org]

== Récupérer le code d'un projet existant ==

Pour télécharger un projet existant, il y a deux possibilités : avec un compte de développeur ou sans compte. Avec un compte SSH simple, il suffit d'exécuter la commande suivante :
git clone mybeautifulname@git.frankiz.net:/hosting/git/frankiz
Sans compte, certains projets sont téléchargeables avec le protocole HTTP, mais vous ne pourrez pas uploader vos modifications.
git clone http://git.frankiz.net/frankiz

Cela crée un '''clone''' du dépôt d'origine (i.e une copie conforme), qui peut d'ailleurs servir de backup si le dépôt d'origine était perdu. Notre clone contient tout l'historique du dépôt depuis sa création, toutes les branches, etc. Cette première opération est très souple. On peut cloner des dépôt via SSH, HTTP, GIT, ou même en local le dépôt d'un autre utilisateur...

Par exemple la commande suivante clone dans le dossier ''platal'' la branche ''core/master'' d'une version de Plat/al potientiellement modifiée par le vice-prez 2010 :
git clone /home/2010/fishilico/dev/platal/.git platal -b core/master

== Accéder à l'aide ==
Avant toute chose, il est essentiel de savoir où trouver de l'aide, d'autant plus que l'aide de Git est très bien faite.
* Sur internet, il y a le wikiBR, les pages de manuel ([http://linux.die.net/man/1/git sur Linux Die] par exemple) et le [http://book.git-scm.com/ Git Book]
* En terminal, ''git help'' pour une liste des commandes, ''git help cmd'' ou ''git cmd --help'' pour l'aide complète de la commande ''cmd'', ou encore simplement ''git cmd -h'' pour une aide courte sur la commande ''cmd''

== Quel est l'état de ma copie de travail ? ==
Ceci est la question que vous devez vous posez avant de reprendre après une pause votre travail sur un projet versionné. Il peut y avoir eu des changements sur le projet entre temps, des patchs mal faits en production, ... Pour cela, il y a trois commandes essentielles :
* Pour vérifier que le dépôt est correct, ''git status'' doit dire cela :
git status
# On branch master
nothing to commit (working directory clean)
* En cours de travail, la réponse ressemble plus à :
git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: un-fichier-random.blah
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# un-fichier-chombier-ajouté.42
no changes added to commit (use "git add" and/or "git commit -a")
* Lire l'historique est bien pour savoir quel est le dernier commit
git log
commit 2a424aae1e746fb5f33de3b3bc3e8a31ee25c684
Author: Nicolas Iooss <fishilico@eleves.polytechnique.fr>
Date: Fri Mar 9 00:27:35 2012 +0100
* Voir les différences entre la version sur le dépôt distant et celle de travail
git diff

De plus, après avoir téléchargé les derniers commits avec ''git fetch'', il est possible d'obtenir le message suivant :
git status
# On branch master
# Your branch is behind 'origin/master' by 42 commits, and can be fast-forwarded.
Cela signifie que la copie locale a 42 commits de retard sur le dépôt distant, mais qu'un ''git rebase origin/master'' suffit pour mettre à jour la copie locale.

== Réinitialiser le dépôt ==
Pour restaurer un fichier, il suffit de le ''checkout'' à partir de l'index. En français, cela signifie que lorsque vous faites une modification sur un fichier, vous pouvez effacer les modifications et revenir la dernière version enregistrée dans l'index Git avec la commande :
git checkout -- chemin/vers/mon/fichier.blih
Pour réinitialiser l'index dans l'état indiqué par une branche (comme ''master'' par exemple) sans modifier les fichier, il suffit d'écrire :
git reset master
Si cela ne marche pas car des fichiers seront modifiés ou effacés, on peut forcer la main à Git, mais alors il faut être prêt à subir les conséqences que cela implique (perte des modifications non commitées)
git reset --hard master

== Mettre à jour la copie de travail ==
=== git fetch && git rebase origin/master ===
Dans le cas général, vous travaillez sur la branche ''master'' et vous synchronisez votre projet sur un seul serveur. Si votre cas est plus compliqué, vous devez être suffisamment compétent pour vous débrouillez par vous-même. On disait donc... dans le cas simple, Git stocke en interne deux branches : ''master'' et ''origin/master''. Sur Frankiz, c'est un peu plus compliqué car il y a une branche de production, mais les développeurs n'utilisent que master.
git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/f579e1971a66623b2948bf0e20c2e23481022b41
remotes/origin/fkz2
remotes/origin/kangz-h4ck3s
remotes/origin/master
remotes/origin/prod

Pour mettre à jour sa copie de travail, il faut donc commencer par mettre à jour les branches distantes, avec '''au choix''' l'une des commandes suivantes
git fetch
git fetch origin

Ensuite, il faut appliquer les éventuelles modifications locales à la suite de celles effectuées sur le dépôt, c'est le '''rebase'''.
git rebase origin/master
Git essaiera alors d'appliquer les commits locaux successivement, en indiquant chaque fois qu'il y a un problème (conflit ou fichier supprimé). En cas de problème, il faut
# Résoudre le problème (les fichiers avec des conflits apparaîssent comme ''Changed but not updated'' dans ''git status'')
# Ajouter les fichiers (''git add'')
# Indiquer à git de continuer : ''git rebase --continue''

Remarque : git pull --rebase est un raccourci pour l'ensemble git fetch && git rebase. Attention cependant lors du travail sur plusieurs branches.

Ceci permet de transformer l'état suivant (les ''O'' sont les commits, ''A'' le moment où les deux versions ont commencé à diverger, ''B'' la version du dépôt, ''E'' la version locale, ''C'' et ''D'' des commits locaux

-C--D--E
/
-O--A--O--B

En l'état plus propre :
-O--A--O--B--C'--D'--E'

Avec C, D et E convertis en C', D' et E' : ils ont été modifiés pour être des modifications relatives à B au lieu de A.

=== Pourquoi il ne faut JAMAIS utiliser git pull ===
Certains développeurs utilisent la commande ''git pull'' pour mettre à jour leur dépôt. Cette pratique est justifiée lorsque la copie de travail était propre (sans commit en attente de push entre autres), mais sinon, cela peut avoir des conséquences très graves et sales. En effet, ''git pull' est assimilé à la succession de commandes suivantes :
git fetch origin && git merge origin/master
Le problème est le merge. En reprenant les schémas précédents, cela transforme l'état suivant :

-C--D--E
/
-O--A--O--B

en :

-C--D--E
/ \
-O--A--O--B----M

où M est le commit ''de fusion de branches''. '''Cela est très moche et à éviter absolument'''. Si vous vous retrouvez dans cette suituation (pour vérifier : ''git log''), vous pouvez toujours tenter un ''git rebase origin/master'' qui peut fonctionner si le ''merge'' était trivial (sans conflit). Sinon, un ''git reset --hard origin/master'' s'impose pour assurer votre salut.

=== Sauvegarder des modifications locales (git stash) ===
Avant de faire un merge particulièrement délicat, ou si l'on doit résoudre un bug alors que l'on a pas mal de modifications non commitées en cours, il est parfois utile de sauvegarder l'état courant de la copie de travail.

Pour cela, il faut utiliser '''avant''' un changement (avec ''git rebase'' par exemple) :
git stash
Une fois les modifications effectuées, on peut restorer la copie locale à l'état sauvegardé avec :
git stash pop

== Effectuer un commit ==
Un '''commit''' est un ensemble de fichiers modifiés. Cela permet plus de cohérence dans le suivi des versions. Par exemple, si l'ajout d'une fonctionnalité sur Frankiz modifie les fichiers ''blah'', ''blih'' et ''bloh'', le ''commit'' regroupe les modifications de ces trois fichiers, et associe à cette modification une date et un auteur.

Pour effectuer un commit, il faut :
* Vérifier l'état de la copie de travail, pour ne commiter que ce qui est nécessaire
git status
git diff
* Indiquer à Git quels fichiers feront partie du commit ; ceci permet de ne committer que les modifications de quelques fichiers
git add path/to/blih path/to/blah path/to/bloh
* Vérifier que l'on a ajouté les fichiers que l'on voulait :
git status
* Faire le commit (le ''-s'' ajoute une ligne ''Signed of by'' dans le message, pour pouvoir retrouver plus efficacement l'auteur réel du commit)
git commit -s
* Cette commande ouvre un éditeur (vi, nano ou emacs selon la configuration de la variable EDITOR). Il faut alors entrer un bref descriptif du commit. '''Pour certains projets (dont Frankiz), les conventions de codage obligent les développeurs à écrire les descriptions en anglais.''' Il est un bon usage de s'adapter en conséquence, car un commit peut être refusé en production s'il est mal fait.
* Mettre à jour la copie locale avec le dépôt distant (cela décale le nouveau commit à la fin). '''IL NE FAUT SURTOUT PAS FAIRE DE git pull OU DE git merge ICI'''
git fetch
git rebase origin/master
* Transmettre les commits au dépôt d'origine
git push

La dernière commande provient du fait que git n'est pas centralisé : il n'envoie pas les modifications locales au dépôt parent spontanément.

Ceci permet de faire quelques modifications locales puis de n'envoyer cela au reste des développeurs que lorsque les modifications sont stables et complètes, par exemple.

== Gérer les branches ==
On peut voir la liste des branches accessibles avec :
git branch -a
* La ligne avec une étoile est la branche courante
* Les lignes blanches sont les branches ''locales'' (elles suivent généralement une branche distante)
* Les lignes rouges (si les couleurs sont activées) sont les branches distantes.

Pour récupérer une autre branche, il faut d'abord l'ajouter localement :
git checkout -b NomLocal origin/NomDistant

Cela aura également pour effet de basculer sur la branche NomLocal.
Les modifications que l'on avait effectuées sont bien entendu conservées.

Une fois la branche ajoutée, on peut basculer de branche en branche à l'aide de :
git checkout NomLocal

== Créer un dépôt ==
Contrairement à [[SVN]] où il faut installer un serveur subversion, créer un dépôt Git est très rapide : dans le dossier que l'on souhaite versionner, il suffit de taper
git init
Et voilà, le dossier est versionné : on peut donc commencer à faire des modifications, des commits, etc. (bien entendu, on ne peut pas ''pusher'' ses commits, puisqu'il n'y a pas de serveur distant).

Cette particularité rend Git très efficace pour versionner un petit projet, un exercice de TD, etc.

Pour créer un dépôt qui peut être cloné, il faut exécuter les commandes suivantes :
git init --bare mon_projet
cd mon_projet && git update-server-info

Enfin, pour configurer un serveur HTTP (gitweb), il ne faut pas oublier de créer un fichier vide '''git-daemon-export-ok''' dans le dossier, afin de permettre le clonage.

== Structure interne ==

Git stocke les commits de manière très particulière : un commit correspond à peu près à une sauvegarde de l'état des fichiers, à un message, et à une référence vers le commit parent.
Contrairemant à [[SVN]], il n'y a donc pas de notion de numéro de révision : chaque commit est identifié par une chaîne hexadécimale de 40 caractères (par exemple : ''04fd02e59b1bdc430c7a7dcc1ca9f4cbc2b04037'' )

Un ''tag'' est en fait un nom «lisible» donné à un ''commit'' ; une ''branche'' indique également le ''commit'' principal d'une branche.

== Du bon usage de gitignore ==
Dans un projet, il est inutile de versionner les fichiers temporaires et les fichiers compilés (qu'ils soient binaires ou non). On utilise généralement un Makefile pour créer ces fichiers. Pour éviter de les versionner, il suffit d'utiliser un fichier ''.gitignore'' bien placé. Généralement, chaque projet a un tel fichier dans son dossier principal. Voici par exemple un extrait du gitignore de Frankiz :
configs/frankiz.conf
htdocs/.htaccess
htdocs/data/*
htdocs/css/*
spool/*
upgrade/2.0.0_to_3.0.0/unversionned

== Configuration globale ==
Si vous avez déjà commitez, vous aurez certainement remarqué qu'il faut utiliser ''git config'' pour configurer vos informations personnelles. Ainsi, les deux premières commandes que tout utilisateur doit taper avant de faire un commit sont :
git config --global user.name "Prénom Nom de famille"
git config --global user.email "prenom.nom.promo@polytechnique.org"

Ensuite, si vous aimez les couleurs, vous avez envie de taper cette commande :
git config --global color.ui auto

Enfin, si vous en avez assez des projets qui ne mettent pas les fichiers temporaires dans le gitignore, vous pouvez configurer un fichier gitignore global. Si votre ''/home/user/.gitignore_global'' ressemble à
*~
*.swp
*.tmp
il suffit de taper :
git config --global core.excludesfile /home/user/.gitignore_global

Tout cela permet de gérer la configuration globale, visible par
git config --global -l
En enlevant ''--global'' dans toutes les commandes précédentes, on configure la copie locale.

=== Exemple de configuration ===
Voici un exemple de fichier ~/.gitconfig (qui stocke la configuration ''--global'', le même format peut être utilisé dans les fichier ''$REPO/.git/config'' de chaque dépot) :
[gc]
auto = 1
[color]
ui = true
[color "diff"]
whitespace = red reverse
[core]
whitespace=fix,-indent-with-non-tab,trailing-space,cr-at-eol
[alias]
st = status
ci = commit
br = branch
co = checkout
df = diff
dc = diff --cached
lg = log -p
lo = log --graph --decorate --pretty=oneline --abbrev-commit -n 10
lol = log --graph --decorate --pretty=oneline --abbrev-commit
lola = log --graph --decorate --pretty=oneline --abbrev-commit --all
ls = ls-files
# Show files ignored by git:
ign = ls-files -o -i --exclude-standard
amend = commit --amend -C HEAD
[branch]
autosetuprebase = always

== Utiliser le proxy de l'X avec Git ==
Si vous hébergez un projet sur [http://www.github.com GitHub], vous avez envie de dire à Git de se connecter à GitHub en SSH en passant par le proxy de l'X (qui est [http://kuzh.polytechnique.fr:8080 kuzh:8080]). Pour cela, il suffit de configurer le client SSH pour utiliser le proxy à chaque connexion vers github.com. Cela s'effecute par le fichier de configuration suivant dans /home/user/.ssh/config (adaptez avec votre dossier personnel)
Host github.com
ProxyCommand socat - PROXY:kuzh.polytechnique.fr:%h:%p,proxyport=8080

'''Si vous souhaitez uniquement cloner un dépôt GitHub''' dont vous n'êtes pas contributeur, il suffit d'utiliser le lien HTTPS en ligne de commande, en précisant le proxy.
export https_proxy=http://kuzh.polytechnique.fr:8080
git clone https://github.com/BinetReseau/frankiz.git

= Pour Windows =

Pour utiliser Git sur Windows, on peut par exemple télécharger MSys Git : [http://msysgit.github.com/ http://msysgit.github.com/].

[[Catégorie:Root]]

Diagnostiquer une panne réseau

2013-02-14T16:22:21Z

Arthur : /* Proxy */ ortho

Tu as une panne réseau à l'X ? Un problème se pose ? Voici quelques tests usuels qui permettent de déterminer tout seul précisément d'où vient le problème. Cela est utile '''avant''' de spammer les équipes de support du Binet Réseau ou de la DSI.

== Connexion au réseau du bâtiment ==

=== Est-ce que votre ordinateur arrive à se connecter au réseau du bâtiment ? ===

Le test usuel pour cela est le ''ping de la passerelle'' ou le ''ping du voisin''. La passerelle est un composant du réseau qui permet de relayer des communications internet avec autre chose. Par exemple, si votre adresse IP est 129.104.13.37 et que la passerelle est 129.104.13.254, la commande suivante teste la connectivité entre votre ordinateur et la passerelle du bâtiment :
ping 129.104.13.254

En cas de succès, ceci s'affiche :
PING 129.104.13.254 (129.104.13.254) 56(84) bytes of data.
64 bytes from 129.104.13.254: icmp_seq=1 ttl=60 time=1.94 ms
64 bytes from 129.104.13.254: icmp_seq=2 ttl=60 time=1.56 ms
64 bytes from 129.104.13.254: icmp_seq=3 ttl=60 time=2.01 ms
64 bytes from 129.104.13.254: icmp_seq=4 ttl=60 time=1.65 ms
64 bytes from 129.104.13.254: icmp_seq=5 ttl=60 time=4.82 ms
--- 129.104.13.254 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 1.565/2.400/4.821/1.222 ms

En cas d'échec, c'est cela qu'il se passe :
PING 129.104.13.254 (129.104.13.254) 56(84) bytes of data.
--- 129.104.13.254 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4008ms

Parfois, il se peut que la passerelle ne réponde jamais au ping alors qu'elle est accessible. Dans ce cas, il faut essayer avec l'adresse IP de son voisin (et en profiter pour faire sa connaissance si ce n'est pas déjà fait). Par exemple, si mon voisin a un ordinateur connecté avec l'adresse IP 129.104.13.42, la commande '''ping 129.104.13.42''' permet de tester la connectivité.

=== Que faire si la passerelle est inaccessible ? ===
* Regarde si le câble est bien branché.
* Vérifie ton adresse IP et le masque de sous-réseau.
* Vérifie qu'il n'y a pas actuellement une coupure de courant.
* Connecte-toi directement à la prise ethernet si tu passais par le téléphone.

== Connexion au réseau de l'école ==

=== Est-ce que le réseau de l'X est accessible ? ===
Pour savoir, il suffit d'exécuter un ping sur une machine toujours accessible, par exemple kuzh (129.104.247.2) ou deiz (129.104.30.90). La ligne de commande est '''ping 129.104.247.2''' et son résultat se lit comme précédemment.

=== Que faire si la machine testée ne répond pas ? ===
Il peut y avoir une panne temporaire sur le réseau, regarde si ton voisin arrive à communiquer avec la machine concernée. Vérifie les paramétrages de la passerelle.

== Noms de domaine (DNS) de l'internet ==

Est-ce que les noms de domaine d'internet sont correctement résolus par des adresses IP ? Pour le savoir, comme précédemment, une commande universelle : ping. Par exemple '''ping kuzh.polytechnique.fr''' doit afficher quelque chose qui ressemble à :
PING kuzh.polytechnique.fr (129.104.247.2) 56(84) bytes of data.
64 bytes from kuzh.polytechnique.fr (129.104.247.2): icmp_seq=1 ttl=62 time=13.1 ms

et ne pas répondre :
ping: unknown host kuzh.polytechnique.fr

En cas de problème, vérifie la configuration des serveurs DNS.

== Noms de domaine (DNS) du BR ==

Le BR fournit deux serveurs DNS (129.104.201.53 et 129.104.201.51) qui fournissent, en plus des DNS globales, des noms privés en eleves.polytechnique.fr. Le BR conseille de configurer ce domaine ainsi que polytechnique.fr en tant que suffixe DNS afin d'éviter de le retaper.

En configuration BR, la commande '''ping frankiz''' doit renvoyer un résultat qui commence par :
PING frankiz.eleves.polytechnique.fr (129.104.201.51) 56(84) bytes of data.

Si ce n'est pas le cas, vérifie la configuration des serveurs DNS.

== Proxy ==

Après avoir testé le réseau de l'X et les DNS, il y a des tests en navigateur qui permettent de diagnostiquer rapidement les problèmes liés au proxy. Le BR a mis en place la page http://config/test.html afin de tester si un navigateur web (Internet Explorer, Safari, Opera, Firefox, Chrome, Konqueror, Links, ...) peut accéder aux serveurs du BR. Si cette page est inaccessible, essaie directement http://config.eleves.polytechnique.fr/test.html ou http://129.104.201.51/test.html.

Si cela donne une page d'erreur "L'URL demandée n'a pu être chargée (...) L'erreur suivante a été rencontrée : Impossible d'associer une adresse IP à la machine (Name Error: The domain name does not exist.)", c'est que le navigateur est configuré sur un proxy forcé et il faut le modifier en proxy automatique pour accéder à la zone BR (cf [[Configuration du proxy]]).

Ensuite, si une requête vers http://www.google.fr/ n'aboutit pas (expiration du délai de réponse), c'est peut-être que le proxy n'est pas du tout configuré. Si Google est accessible mais GMail ne l'est pas (ou d'autres sites en HTTPS), il faut bien faire attention à configurer le proxy pour tous les protocoles et pas uniquement pour HTTP. La configuration du proxy est détaillée sur la page appropriée, [[Configuration du proxy]].

== Toujours un problème ? ==

Cette page est trop synthétique pour être exhaustive. Si malgré les tests proposés des problèmes réseaux persistent, n'hésite pas à contacter le support du BR à [mailto:support@eleves.polytechnique.fr support@eleves.polytechnique.fr], en détaillant ce qui fonctionne et ce qui est cassé, en citant les paragraphes de cette page.

SSH

2012-12-18T13:06:18Z

Arthur : /* Mémorisation de configuration SSH */

SSH est un protocole permettant d'obtenir un accès Shell sur une machine distante en toute sécurité.
Il permet, via SCP, de transférer des fichiers entre diverses machines.

Nous allons voir ici quelques options intéressantes.

== Clé publique ==
Il est possible de se connecter en SSH à une machine sans avoir à taper son mot de passe !

C'est parfois la seule manière, par exemple dans le cas des machines visibles à l'extérieur, depuis l'extérieur de l'X.

=== Création de la clé ===
En local, sur une machine où l'on est le seul administrateur (machine perso) :
ssh-keygen
Laisser la valeur par défaut pour le nom du fichier (~/.ssh/id_rsa) et taper une passphrase (longue et complexe). Ceci va générer en local un couple clé privée / clé publique, chiffrée en RSA.

=== Export vers les autres machines ===
Il faut ensuite envoyer le fichier contenant la clé publique (~/.ssh/id_rsa.pub) sur les machines auxquelles on veut se connecter :
==== Avec ssh-copy-id ====
ssh-copy-id login_distant@machine_distante
==== Manuellement ====
Sur les mac, par exemple, ssh-copy-id n'est pas disponible. Il faut donc rajouter manuellement la clé publique à liste des clés autorisées sur la machine distante en copiant le contenu de ~/.ssh/id_rsa.pub (en local) dans .ssh/authorized_keys (sur la machine distante) :
* sur la machine locale :
scp ~/.ssh/id_rsa.pub login_distant@machine_distante:~
* sur la machine distante :
cat ~/id_rsa.pub >> ~/.ssh/authorized_keys

=== ssh-agent ===
Il s'agit d'un programme qui vient faciliter l'utilisation des clés privées : en le lançant au début de ta session graphique, il suffit de taper dans un shell
ssh-add
pour qu'il demande la passphrase de la clé privée, puis la charger en mémoire : plus besoin de taper cette passphrase lors d'un SSH !
Tu peux indiquer par l'option ''-A'' dans ton ssh que tu souhaites ''forwarder'' l'agent : si tu as exporté ta clé publique sur les machines hostA et hostB, alors en faisant
ssh -A hostA
puis, sur hostA
ssh hostB

le second ssh utilisera le ssh-agent qui tourne localement sur ton ordinateur pour récupérer la clé privée et s'authentifier auprès de hostB. Il devient alors intéressant d'utiliser l'option ForwardAgent (cf plus bas) pour pouvoir se balader librement entre les différentes machines.

=== Connection ===
Pour se connecter, on tape
ssh login_distant@machine_distante

Si on a lancé le ssh-agent avant (ssh-add), le client ssh va demander la passphrase de la clé, puis établir la connexion.

=== Fonctionnement===
Lors d'un SSH par clé privée / clé publique
# le serveur ssh va indiquer au client "j'accepte les clés publiques suivantes" en lisant le fichier authorized_keys
# mon client va voir qu'il a la clé privée correspondant
# mon client me demander ma passphrase
# si la passphrase est bonn, mon client va établir le ssh sans me demander mon mot de passe user

== Mémorisation de configuration SSH ==

Il est possible de configurer SSH pour ne pas avoir à préciser le login ou le nom complet de la machine.

Il faut éditer le fichier ''.ssh/config'' :

Host alias
Hostname nom.complet.de.la.machine
User login_distant

On peut également y rajouter les options relatives au Proxy :
ProxyCommand - PROXY:kuzh.polytechnique.fr:%h:%p,proxyport=8080
ou
ProxyCommand connect -H kuzh.polytechnique.fr:8080 %h %p
ou celles relatives au transfert d'agent ssh :
ForwardAgent yes

Ainsi,
ssh alias
sera traduit automatiquement en
ssh -A -o ProxyCommand="socat - PROXY:kuzh.polytechnique.fr:%h:%p,proxyport=8080" login_distant@nom.complet.de.la.machine
ou
ssh -A -o ProxyCommand="connect -H kuzh.polytechnique.fr:8080 %h %p" login_distant@nom.complet.de.la.machine

Git

2012-10-11T22:34:42Z

Arthur : /* Configuration globale */

Git est un [[VCS|système de contrôle de version]]. Assez proche de [[SVN]] par certains côtés, il présente néanmoins un grand nombre de différences.

Avant de découvrir les spécificités de Git, il est nécessaire de connaître les concepts généraux des [[VCS|systèmes de contrôle de version]].

Cette page donne un bref aperçu des fonctionnalités de Git. Un autre bon aperçu est disponible [http://giudoku.sourceforge.net/media/GitHandbook.pdf ici] (lien non BR)

== Dépôts ==

Alors que [[CVS]] et [[SVN]] sont des systèmes de versionnement centralisés (i.e un serveur contient le dépôt, et chaque utilisateur effectue un ''checkout'' depuis ce dépôt), Git est complètement décentralisé. Cela signifie que chaque contributeur a sa propre copie locale de tout l'historique d'un projet. Si aujourd'hui vous considérez que l'espace disque sur votre ordinateur est un problème, allez faire un tour, partez admirer les merveilles de la technologies qui nous entoure, et revenez demain. Sur cette page, tous les examples sont tirés du Git de [[Frankiz]], mais voici d'autres dépôts bien utiles :
* [http://www.github.com/ GitHub]
* [http://git.frankiz.net/ Frankiz]
* [http://git.polytechnique.org/ Polytechnique.org]

== Récupérer le code d'un projet existant ==

Pour télécharger un projet existant, il y a deux possibilités : avec un compte de développeur ou sans compte. Avec un compte SSH simple, il suffit d'exécuter la commande suivante :
git clone mybeautifulname@git.frankiz.net:/hosting/git/frankiz
Sans compte, certains projets sont téléchargeables avec le protocole HTTP, mais vous ne pourrez pas uploader vos modifications.
git clone http://git.frankiz.net/frankiz

Cela crée un '''clone''' du dépôt d'origine (i.e une copie conforme), qui peut d'ailleurs servir de backup si le dépôt d'origine était perdu. Notre clone contient tout l'historique du dépôt depuis sa création, toutes les branches, etc. Cette première opération est très souple. On peut cloner des dépôt via SSH, HTTP, GIT, ou même en local le dépôt d'un autre utilisateur...

Par exemple la commande suivante clone dans le dossier ''platal'' la branche ''core/master'' d'une version de Plat/al potientiellement modifiée par le vice-prez 2010 :
git clone /home/2010/fishilico/dev/platal/.git platal -b core/master

== Accéder à l'aide ==
Avant toute chose, il est essentiel de savoir où trouver de l'aide, d'autant plus que l'aide de Git est très bien faite.
* Sur internet, il y a le wikiBR, les pages de manuel ([http://linux.die.net/man/1/git sur Linux Die] par exemple) et le [http://book.git-scm.com/ Git Book]
* En terminal, ''git help'' pour une liste des commandes, ''git help cmd'' ou ''git cmd --help'' pour l'aide complète de la commande ''cmd'', ou encore simplement ''git cmd -h'' pour une aide courte sur la commande ''cmd''

== Quel est l'état de ma copie de travail ? ==
Ceci est la question que vous devez vous posez avant de reprendre après une pause votre travail sur un projet versionné. Il peut y avoir eu des changements sur le projet entre temps, des patchs mal faits en production, ... Pour cela, il y a trois commandes essentielles :
* Pour vérifier que le dépôt est correct, ''git status'' doit dire cela :
git status
# On branch master
nothing to commit (working directory clean)
* En cours de travail, la réponse ressemble plus à :
git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: un-fichier-random.blah
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# un-fichier-chombier-ajouté.42
no changes added to commit (use "git add" and/or "git commit -a")
* Lire l'historique est bien pour savoir quel est le dernier commit
git log
commit 2a424aae1e746fb5f33de3b3bc3e8a31ee25c684
Author: Nicolas Iooss <fishilico@eleves.polytechnique.fr>
Date: Fri Mar 9 00:27:35 2012 +0100
* Voir les différences entre la version sur le dépôt distant et celle de travail
git diff

De plus, après avoir téléchargé les derniers commits avec ''git fetch'', il est possible d'obtenir le message suivant :
git status
# On branch master
# Your branch is behind 'origin/master' by 42 commits, and can be fast-forwarded.
Cela signifie que la copie locale a 42 commits de retard sur le dépôt distant, mais qu'un ''git rebase origin/master'' suffit pour mettre à jour la copie locale.

== Réinitialiser le dépôt ==
Pour restaurer un fichier, il suffit de le ''checkout'' à partir de l'index. En français, cela signifie que lorsque vous faites une modification sur un fichier, vous pouvez effacer les modifications et revenir la dernière version enregistrée dans l'index Git avec la commande :
git checkout -- chemin/vers/mon/fichier.blih
Pour réinitialiser l'index dans l'état indiqué par une branche (comme ''master'' par exemple) sans modifier les fichier, il suffit d'écrire :
git reset master
Si cela ne marche pas car des fichiers seront modifiés ou effacés, on peut forcer la main à Git, mais alors il faut être prêt à subir les conséqences que cela implique (perte des modifications non commitées)
git reset --hard master

== Mettre à jour la copie de travail ==
=== git fetch && git rebase origin/master ===
Dans le cas général, vous travaillez sur la branche ''master'' et vous synchronisez votre projet sur un seul serveur. Si votre cas est plus compliqué, vous devez être suffisamment compétent pour vous débrouillez par vous-même. On disait donc... dans le cas simple, Git stocke en interne deux branches : ''master'' et ''origin/master''. Sur Frankiz, c'est un peu plus compliqué car il y a une branche de production, mais les développeurs n'utilisent que master.
git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/f579e1971a66623b2948bf0e20c2e23481022b41
remotes/origin/fkz2
remotes/origin/kangz-h4ck3s
remotes/origin/master
remotes/origin/prod

Pour mettre à jour sa copie de travail, il faut donc commencer par mettre à jour les branches distantes, avec '''au choix''' l'une des commandes suivantes
git fetch
git fetch origin

Ensuite, il faut appliquer les éventuelles modifications locales à la suite de celles effectuées sur le dépôt, c'est le '''rebase'''.
git rebase origin/master
Git essaiera alors d'appliquer les commits locaux successivement, en indiquant chaque fois qu'il y a un problème (conflit ou fichier supprimé). En cas de problème, il faut
# Résoudre le problème (les fichiers avec des conflits apparaîssent comme ''Changed but not updated'' dans ''git status'')
# Ajouter les fichiers (''git add'')
# Indiquer à git de continuer : ''git rebase --continue''

Ceci permet de transformer l'état suivant (les ''O'' sont les commits, ''A'' le moment où les deux versions ont commencé à diverger, ''B'' la version du dépôt, ''E'' la version locale, ''C'' et ''D'' des commits locaux)

-C--D--E
/
-O--A--O--B

En l'état plus propre :
-O--A--O--B--C'--D'--E'

Avec C, D et E convertis en C', D' et E' : ils ont été modifiés pour être des modifications relatives à B au lieu de A.

=== Pourquoi il ne faut JAMAIS utiliser git pull ===
Certains développeurs utilisent la commande ''git pull'' pour mettre à jour leur dépôt. Cette pratique est justifiée lorsque la copie de travail était propre (sans commit en attente de push entre autres), mais sinon, cela peut avoir des conséquences très graves et sales. En effet, ''git pull' est assimilé à la succession de commandes suivantes :
git fetch origin && git merge origin/master
Le problème est le merge. En reprenant les schémas précédents, cela transforme l'état suivant :

-C--D--E
/
-O--A--O--B

en :

-C--D--E
/ \
-O--A--O--B----M

où M est le commit ''de fusion de branches''. '''Cela est très moche et à éviter absolument'''. Si vous vous retrouvez dans cette suituation (pour vérifier : ''git log''), vous pouvez toujours tenter un ''git rebase origin/master'' qui peut fonctionner si le ''merge'' était trivial (sans conflit). Sinon, un ''git reset --hard origin/master'' s'impose pour assurer votre salut.

=== Sauvegarder des modifications locales (git stash) ===
Avant de faire un merge particulièrement délicat, ou si l'on doit résoudre un bug alors que l'on a pas mal de modifications non commitées en cours, il est parfois utile de sauvegarder l'état courant de la copie de travail.

Pour cela, il faut utiliser '''avant''' un changement (avec ''git rebase'' par exemple) :
git stash
Une fois les modifications effectuées, on peut restorer la copie locale à l'état sauvegardé avec :
git stash pop

== Effectuer un commit ==
Un '''commit''' est un ensemble de fichiers modifiés. Cela permet plus de cohérence dans le suivi des versions. Par exemple, si l'ajout d'une fonctionnalité sur Frankiz modifie les fichiers ''blah'', ''blih'' et ''bloh'', le ''commit'' regroupe les modifications de ces trois fichiers, et associe à cette modification une date et un auteur.

Pour effectuer un commit, il faut :
* Vérifier l'état de la copie de travail, pour ne commiter que ce qui est nécessaire
git status
git diff
* Indiquer à Git quels fichiers feront partie du commit ; ceci permet de ne committer que les modifications de quelques fichiers
git add path/to/blih path/to/blah path/to/bloh
* Vérifier que l'on a ajouté les fichiers que l'on voulait :
git status
* Faire le commit (le ''-s'' ajoute une ligne ''Signed of by'' dans le message, pour pouvoir retrouver plus efficacement l'auteur réel du commit)
git commit -s
* Cette commande ouvre un éditeur (vi, nano ou emacs selon la configuration de la variable EDITOR). Il faut alors entrer un bref descriptif du commit. '''Pour certains projets (dont Frankiz), les conventions de codage obligent les développeurs à écrire les descriptions en anglais.''' Il est un bon usage de s'adapter en conséquence, car un commit peut être refusé en production s'il est mal fait.
* Mettre à jour la copie locale avec le dépôt distant (cela décale le nouveau commit à la fin). '''IL NE FAUT SURTOUT PAS FAIRE DE git pull OU DE git merge ICI'''
git fetch
git rebase origin/master
* Transmettre les commits au dépôt d'origine
git push

La dernière commande provient du fait que git n'est pas centralisé : il n'envoie pas les modifications locales au dépôt parent spontanément.

Ceci permet de faire quelques modifications locales puis de n'envoyer cela au reste des développeurs que lorsque les modifications sont stables et complètes, par exemple.

== Gérer les branches ==
On peut voir la liste des branches accessibles avec :
git branch -a
* La ligne avec une étoile est la branche courante
* Les lignes blanches sont les branches ''locales'' (elles suivent généralement une branche distante)
* Les lignes rouges (si les couleurs sont activées) sont les branches distantes.

Pour récupérer une autre branche, il faut d'abord l'ajouter localement :
git checkout -b NomLocal origin/NomDistant

Cela aura également pour effet de basculer sur la branche NomLocal.
Les modifications que l'on avait effectuées sont bien entendu conservées.

Une fois la branche ajoutée, on peut basculer de branche en branche à l'aide de :
git checkout NomLocal

== Créer un dépôt ==
Contrairement à [[SVN]] où il faut installer un serveur subversion, créer un dépôt Git est très rapide : dans le dossier que l'on souhaite versionner, il suffit de taper
git init
Et voilà, le dossier est versionné : on peut donc commencer à faire des modifications, des commits, etc. (bien entendu, on ne peut pas ''pusher'' ses commits, puisqu'il n'y a pas de serveur distant).

Cette particularité rend Git très efficace pour versionner un petit projet, un exercice de TD, etc.

Pour créer un dépôt qui peut être cloné, il faut exécuter les commandes suivantes :
git init --bare mon_projet
cd mon_projet && git update-server-info

Enfin, pour configurer un serveur HTTP (gitweb), il ne faut pas oublier de créer un fichier vide '''git-daemon-export-ok''' dans le dossier, afin de permettre le clonage.

== Structure interne ==

Git stocke les commits de manière très particulière : un commit correspond à peu près à une sauvegarde de l'état des fichiers, à un message, et à une référence vers le commit parent.
Contrairemant à [[SVN]], il n'y a donc pas de notion de numéro de révision : chaque commit est identifié par une chaîne hexadécimale de 40 caractères (par exemple : ''04fd02e59b1bdc430c7a7dcc1ca9f4cbc2b04037'' )

Un ''tag'' est en fait un nom «lisible» donné à un ''commit'' ; une ''branche'' indique également le ''commit'' principal d'une branche.

== Du bon usage de gitignore ==
Dans un projet, il est inutile de versionner les fichiers temporaires et les fichiers compilés (qu'ils soient binaires ou non). On utilise généralement un Makefile pour créer ces fichiers. Pour éviter de les versionner, il suffit d'utiliser un fichier ''.gitignore'' bien placé. Généralement, chaque projet a un tel fichier dans son dossier principal. Voici par exemple un extrait du gitignore de Frankiz :
configs/frankiz.conf
htdocs/.htaccess
htdocs/data/*
htdocs/css/*
spool/*
upgrade/2.0.0_to_3.0.0/unversionned

== Configuration globale ==
Si vous avez déjà commitez, vous aurez certainement remarqué qu'il faut utiliser ''git config'' pour configurer vos informations personnelles. Ainsi, les deux premières commandes que tout utilisateur doit taper avant de faire un commit sont :
git config --global user.name "Prénom Nom de famille"
git config --global user.email "prenom.nom.promo@polytechnique.org"

Ensuite, si vous aimez les couleurs, vous avez envie de taper cette commande :
git config --global color.ui auto

Enfin, si vous en avez assez des projets qui ne mettent pas les fichiers temporaires dans le gitignore, vous pouvez configurer un fichier gitignore global. Si votre ''/home/user/.gitignore_global'' ressemble à
*~
*.swp
*.tmp
il suffit de taper :
git config --global core.excludesfile /home/user/.gitignore_global

Tout cela permet de gérer la configuration globale, visible par
git config --global -l
En enlevant ''--global'' dans toutes les commandes précédentes, on configure la copie locale.

=== Exemple de configuration ===
Voici un exemple de fichier ~/.gitconfig (qui stocke la configuration ''--global'', le même format peut être utilisé dans les fichier ''$REPO/.git/config'' de chaque dépot) :
[gc]
auto = 1
[color]
ui = true
[color "diff"]
whitespace = red reverse
[core]
whitespace=fix,-indent-with-non-tab,trailing-space,cr-at-eol
[alias]
st = status
ci = commit
br = branch
co = checkout
df = diff
dc = diff --cached
lg = log -p
lo = log --graph --decorate --pretty=oneline --abbrev-commit -n 10
lol = log --graph --decorate --pretty=oneline --abbrev-commit
lola = log --graph --decorate --pretty=oneline --abbrev-commit --all
ls = ls-files
# Show files ignored by git:
ign = ls-files -o -i --exclude-standard
amend = commit --amend -C HEAD
[branch]
autosetuprebase = always

== Utiliser le proxy de l'X avec Git ==
Si vous hébergez un projet sur [http://www.github.com GitHub], vous avez envie de dire à Git de se connecter à GitHub en SSH en passant par le proxy de l'X (qui est [http://kuzh.polytechnique.fr:8080 kuzh:8080]). Pour cela, il suffit de configurer le client SSH pour utiliser le proxy à chaque connexion vers github.com. Cela s'effecute par le fichier de configuration suivant dans /home/user/.ssh/config (adaptez avec votre dossier personnel)
Host github.com
ProxyCommand socat - PROXY:kuzh.polytechnique.fr:%h:%p,proxyport=8080

'''Si vous souhaitez uniquement cloner un dépôt GitHub''' dont vous n'êtes pas contributeur, il suffit d'utiliser le lien HTTPS en ligne de commande, en précisant le proxy.
export https_proxy=http://kuzh.polytechnique.fr:8080
git clone https://github.com/BinetReseau/frankiz.git

= Pour Windows =

Pour utiliser Git sur Windows, on peut par exemple télécharger MSys Git : [http://msysgit.github.com/ http://msysgit.github.com/].

Git

2012-10-11T22:31:03Z

Arthur : /* Du bon usage de gitignore */

Git est un [[VCS|système de contrôle de version]]. Assez proche de [[SVN]] par certains côtés, il présente néanmoins un grand nombre de différences.

Avant de découvrir les spécificités de Git, il est nécessaire de connaître les concepts généraux des [[VCS|systèmes de contrôle de version]].

Cette page donne un bref aperçu des fonctionnalités de Git. Un autre bon aperçu est disponible [http://giudoku.sourceforge.net/media/GitHandbook.pdf ici] (lien non BR)

== Dépôts ==

Alors que [[CVS]] et [[SVN]] sont des systèmes de versionnement centralisés (i.e un serveur contient le dépôt, et chaque utilisateur effectue un ''checkout'' depuis ce dépôt), Git est complètement décentralisé. Cela signifie que chaque contributeur a sa propre copie locale de tout l'historique d'un projet. Si aujourd'hui vous considérez que l'espace disque sur votre ordinateur est un problème, allez faire un tour, partez admirer les merveilles de la technologies qui nous entoure, et revenez demain. Sur cette page, tous les examples sont tirés du Git de [[Frankiz]], mais voici d'autres dépôts bien utiles :
* [http://www.github.com/ GitHub]
* [http://git.frankiz.net/ Frankiz]
* [http://git.polytechnique.org/ Polytechnique.org]

== Récupérer le code d'un projet existant ==

Pour télécharger un projet existant, il y a deux possibilités : avec un compte de développeur ou sans compte. Avec un compte SSH simple, il suffit d'exécuter la commande suivante :
git clone mybeautifulname@git.frankiz.net:/hosting/git/frankiz
Sans compte, certains projets sont téléchargeables avec le protocole HTTP, mais vous ne pourrez pas uploader vos modifications.
git clone http://git.frankiz.net/frankiz

Cela crée un '''clone''' du dépôt d'origine (i.e une copie conforme), qui peut d'ailleurs servir de backup si le dépôt d'origine était perdu. Notre clone contient tout l'historique du dépôt depuis sa création, toutes les branches, etc. Cette première opération est très souple. On peut cloner des dépôt via SSH, HTTP, GIT, ou même en local le dépôt d'un autre utilisateur...

Par exemple la commande suivante clone dans le dossier ''platal'' la branche ''core/master'' d'une version de Plat/al potientiellement modifiée par le vice-prez 2010 :
git clone /home/2010/fishilico/dev/platal/.git platal -b core/master

== Accéder à l'aide ==
Avant toute chose, il est essentiel de savoir où trouver de l'aide, d'autant plus que l'aide de Git est très bien faite.
* Sur internet, il y a le wikiBR, les pages de manuel ([http://linux.die.net/man/1/git sur Linux Die] par exemple) et le [http://book.git-scm.com/ Git Book]
* En terminal, ''git help'' pour une liste des commandes, ''git help cmd'' ou ''git cmd --help'' pour l'aide complète de la commande ''cmd'', ou encore simplement ''git cmd -h'' pour une aide courte sur la commande ''cmd''

== Quel est l'état de ma copie de travail ? ==
Ceci est la question que vous devez vous posez avant de reprendre après une pause votre travail sur un projet versionné. Il peut y avoir eu des changements sur le projet entre temps, des patchs mal faits en production, ... Pour cela, il y a trois commandes essentielles :
* Pour vérifier que le dépôt est correct, ''git status'' doit dire cela :
git status
# On branch master
nothing to commit (working directory clean)
* En cours de travail, la réponse ressemble plus à :
git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: un-fichier-random.blah
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# un-fichier-chombier-ajouté.42
no changes added to commit (use "git add" and/or "git commit -a")
* Lire l'historique est bien pour savoir quel est le dernier commit
git log
commit 2a424aae1e746fb5f33de3b3bc3e8a31ee25c684
Author: Nicolas Iooss <fishilico@eleves.polytechnique.fr>
Date: Fri Mar 9 00:27:35 2012 +0100
* Voir les différences entre la version sur le dépôt distant et celle de travail
git diff

De plus, après avoir téléchargé les derniers commits avec ''git fetch'', il est possible d'obtenir le message suivant :
git status
# On branch master
# Your branch is behind 'origin/master' by 42 commits, and can be fast-forwarded.
Cela signifie que la copie locale a 42 commits de retard sur le dépôt distant, mais qu'un ''git rebase origin/master'' suffit pour mettre à jour la copie locale.

== Réinitialiser le dépôt ==
Pour restaurer un fichier, il suffit de le ''checkout'' à partir de l'index. En français, cela signifie que lorsque vous faites une modification sur un fichier, vous pouvez effacer les modifications et revenir la dernière version enregistrée dans l'index Git avec la commande :
git checkout -- chemin/vers/mon/fichier.blih
Pour réinitialiser l'index dans l'état indiqué par une branche (comme ''master'' par exemple) sans modifier les fichier, il suffit d'écrire :
git reset master
Si cela ne marche pas car des fichiers seront modifiés ou effacés, on peut forcer la main à Git, mais alors il faut être prêt à subir les conséqences que cela implique (perte des modifications non commitées)
git reset --hard master

== Mettre à jour la copie de travail ==
=== git fetch && git rebase origin/master ===
Dans le cas général, vous travaillez sur la branche ''master'' et vous synchronisez votre projet sur un seul serveur. Si votre cas est plus compliqué, vous devez être suffisamment compétent pour vous débrouillez par vous-même. On disait donc... dans le cas simple, Git stocke en interne deux branches : ''master'' et ''origin/master''. Sur Frankiz, c'est un peu plus compliqué car il y a une branche de production, mais les développeurs n'utilisent que master.
git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/f579e1971a66623b2948bf0e20c2e23481022b41
remotes/origin/fkz2
remotes/origin/kangz-h4ck3s
remotes/origin/master
remotes/origin/prod

Pour mettre à jour sa copie de travail, il faut donc commencer par mettre à jour les branches distantes, avec '''au choix''' l'une des commandes suivantes
git fetch
git fetch origin

Ensuite, il faut appliquer les éventuelles modifications locales à la suite de celles effectuées sur le dépôt, c'est le '''rebase'''.
git rebase origin/master
Git essaiera alors d'appliquer les commits locaux successivement, en indiquant chaque fois qu'il y a un problème (conflit ou fichier supprimé). En cas de problème, il faut
# Résoudre le problème (les fichiers avec des conflits apparaîssent comme ''Changed but not updated'' dans ''git status'')
# Ajouter les fichiers (''git add'')
# Indiquer à git de continuer : ''git rebase --continue''

Ceci permet de transformer l'état suivant (les ''O'' sont les commits, ''A'' le moment où les deux versions ont commencé à diverger, ''B'' la version du dépôt, ''E'' la version locale, ''C'' et ''D'' des commits locaux)

-C--D--E
/
-O--A--O--B

En l'état plus propre :
-O--A--O--B--C'--D'--E'

Avec C, D et E convertis en C', D' et E' : ils ont été modifiés pour être des modifications relatives à B au lieu de A.

=== Pourquoi il ne faut JAMAIS utiliser git pull ===
Certains développeurs utilisent la commande ''git pull'' pour mettre à jour leur dépôt. Cette pratique est justifiée lorsque la copie de travail était propre (sans commit en attente de push entre autres), mais sinon, cela peut avoir des conséquences très graves et sales. En effet, ''git pull' est assimilé à la succession de commandes suivantes :
git fetch origin && git merge origin/master
Le problème est le merge. En reprenant les schémas précédents, cela transforme l'état suivant :

-C--D--E
/
-O--A--O--B

en :

-C--D--E
/ \
-O--A--O--B----M

où M est le commit ''de fusion de branches''. '''Cela est très moche et à éviter absolument'''. Si vous vous retrouvez dans cette suituation (pour vérifier : ''git log''), vous pouvez toujours tenter un ''git rebase origin/master'' qui peut fonctionner si le ''merge'' était trivial (sans conflit). Sinon, un ''git reset --hard origin/master'' s'impose pour assurer votre salut.

=== Sauvegarder des modifications locales (git stash) ===
Avant de faire un merge particulièrement délicat, ou si l'on doit résoudre un bug alors que l'on a pas mal de modifications non commitées en cours, il est parfois utile de sauvegarder l'état courant de la copie de travail.

Pour cela, il faut utiliser '''avant''' un changement (avec ''git rebase'' par exemple) :
git stash
Une fois les modifications effectuées, on peut restorer la copie locale à l'état sauvegardé avec :
git stash pop

== Effectuer un commit ==
Un '''commit''' est un ensemble de fichiers modifiés. Cela permet plus de cohérence dans le suivi des versions. Par exemple, si l'ajout d'une fonctionnalité sur Frankiz modifie les fichiers ''blah'', ''blih'' et ''bloh'', le ''commit'' regroupe les modifications de ces trois fichiers, et associe à cette modification une date et un auteur.

Pour effectuer un commit, il faut :
* Vérifier l'état de la copie de travail, pour ne commiter que ce qui est nécessaire
git status
git diff
* Indiquer à Git quels fichiers feront partie du commit ; ceci permet de ne committer que les modifications de quelques fichiers
git add path/to/blih path/to/blah path/to/bloh
* Vérifier que l'on a ajouté les fichiers que l'on voulait :
git status
* Faire le commit (le ''-s'' ajoute une ligne ''Signed of by'' dans le message, pour pouvoir retrouver plus efficacement l'auteur réel du commit)
git commit -s
* Cette commande ouvre un éditeur (vi, nano ou emacs selon la configuration de la variable EDITOR). Il faut alors entrer un bref descriptif du commit. '''Pour certains projets (dont Frankiz), les conventions de codage obligent les développeurs à écrire les descriptions en anglais.''' Il est un bon usage de s'adapter en conséquence, car un commit peut être refusé en production s'il est mal fait.
* Mettre à jour la copie locale avec le dépôt distant (cela décale le nouveau commit à la fin). '''IL NE FAUT SURTOUT PAS FAIRE DE git pull OU DE git merge ICI'''
git fetch
git rebase origin/master
* Transmettre les commits au dépôt d'origine
git push

La dernière commande provient du fait que git n'est pas centralisé : il n'envoie pas les modifications locales au dépôt parent spontanément.

Ceci permet de faire quelques modifications locales puis de n'envoyer cela au reste des développeurs que lorsque les modifications sont stables et complètes, par exemple.

== Gérer les branches ==
On peut voir la liste des branches accessibles avec :
git branch -a
* La ligne avec une étoile est la branche courante
* Les lignes blanches sont les branches ''locales'' (elles suivent généralement une branche distante)
* Les lignes rouges (si les couleurs sont activées) sont les branches distantes.

Pour récupérer une autre branche, il faut d'abord l'ajouter localement :
git checkout -b NomLocal origin/NomDistant

Cela aura également pour effet de basculer sur la branche NomLocal.
Les modifications que l'on avait effectuées sont bien entendu conservées.

Une fois la branche ajoutée, on peut basculer de branche en branche à l'aide de :
git checkout NomLocal

== Créer un dépôt ==
Contrairement à [[SVN]] où il faut installer un serveur subversion, créer un dépôt Git est très rapide : dans le dossier que l'on souhaite versionner, il suffit de taper
git init
Et voilà, le dossier est versionné : on peut donc commencer à faire des modifications, des commits, etc. (bien entendu, on ne peut pas ''pusher'' ses commits, puisqu'il n'y a pas de serveur distant).

Cette particularité rend Git très efficace pour versionner un petit projet, un exercice de TD, etc.

Pour créer un dépôt qui peut être cloné, il faut exécuter les commandes suivantes :
git init --bare mon_projet
cd mon_projet && git update-server-info

Enfin, pour configurer un serveur HTTP (gitweb), il ne faut pas oublier de créer un fichier vide '''git-daemon-export-ok''' dans le dossier, afin de permettre le clonage.

== Structure interne ==

Git stocke les commits de manière très particulière : un commit correspond à peu près à une sauvegarde de l'état des fichiers, à un message, et à une référence vers le commit parent.
Contrairemant à [[SVN]], il n'y a donc pas de notion de numéro de révision : chaque commit est identifié par une chaîne hexadécimale de 40 caractères (par exemple : ''04fd02e59b1bdc430c7a7dcc1ca9f4cbc2b04037'' )

Un ''tag'' est en fait un nom «lisible» donné à un ''commit'' ; une ''branche'' indique également le ''commit'' principal d'une branche.

== Du bon usage de gitignore ==
Dans un projet, il est inutile de versionner les fichiers temporaires et les fichiers compilés (qu'ils soient binaires ou non). On utilise généralement un Makefile pour créer ces fichiers. Pour éviter de les versionner, il suffit d'utiliser un fichier ''.gitignore'' bien placé. Généralement, chaque projet a un tel fichier dans son dossier principal. Voici par exemple un extrait du gitignore de Frankiz :
configs/frankiz.conf
htdocs/.htaccess
htdocs/data/*
htdocs/css/*
spool/*
upgrade/2.0.0_to_3.0.0/unversionned

== Configuration globale ==
Si vous avez déjà commitez, vous aurez certainement remarqué qu'il faut utiliser ''git config'' pour configurer vos informations personnelles. Ainsi, les deux premières commandes que tout utilisateur doit taper avant de faire un commit sont :
git config --global user.name "Prénom Nom de famille"
git config --global user.email "prenom.nom.promo@polytechnique.org"

Ensuite, si vous aimez les couleurs, vous avez envie de taper cette commande :
git config --global color.ui auto

Enfin, si vous en avez assez des projets qui ne mettent pas les fichiers temporaires dans le gitignore, vous pouvez configurer un fichier gitignore global. Si votre ''/home/user/.gitignore_global'' ressemble à
*~
*.swp
*.tmp
il suffit de taper :
git config --global core.excludesfile /home/user/.gitignore_global

Tout cela permet de gérer la configuration globale, visible par
git config --global -l
En enlevant ''--global'' dans toutes les commandes précédentes, on configure la copie locale.

== Utiliser le proxy de l'X avec Git ==
Si vous hébergez un projet sur [http://www.github.com GitHub], vous avez envie de dire à Git de se connecter à GitHub en SSH en passant par le proxy de l'X (qui est [http://kuzh.polytechnique.fr:8080 kuzh:8080]). Pour cela, il suffit de configurer le client SSH pour utiliser le proxy à chaque connexion vers github.com. Cela s'effecute par le fichier de configuration suivant dans /home/user/.ssh/config (adaptez avec votre dossier personnel)
Host github.com
ProxyCommand socat - PROXY:kuzh.polytechnique.fr:%h:%p,proxyport=8080

'''Si vous souhaitez uniquement cloner un dépôt GitHub''' dont vous n'êtes pas contributeur, il suffit d'utiliser le lien HTTPS en ligne de commande, en précisant le proxy.
export https_proxy=http://kuzh.polytechnique.fr:8080
git clone https://github.com/BinetReseau/frankiz.git

= Pour Windows =

Pour utiliser Git sur Windows, on peut par exemple télécharger MSys Git : [http://msysgit.github.com/ http://msysgit.github.com/].

Git

2012-10-11T22:28:53Z

Arthur : /* Du bon usage de gitignore */

Git est un [[VCS|système de contrôle de version]]. Assez proche de [[SVN]] par certains côtés, il présente néanmoins un grand nombre de différences.

Avant de découvrir les spécificités de Git, il est nécessaire de connaître les concepts généraux des [[VCS|systèmes de contrôle de version]].

Cette page donne un bref aperçu des fonctionnalités de Git. Un autre bon aperçu est disponible [http://giudoku.sourceforge.net/media/GitHandbook.pdf ici] (lien non BR)

== Dépôts ==

Alors que [[CVS]] et [[SVN]] sont des systèmes de versionnement centralisés (i.e un serveur contient le dépôt, et chaque utilisateur effectue un ''checkout'' depuis ce dépôt), Git est complètement décentralisé. Cela signifie que chaque contributeur a sa propre copie locale de tout l'historique d'un projet. Si aujourd'hui vous considérez que l'espace disque sur votre ordinateur est un problème, allez faire un tour, partez admirer les merveilles de la technologies qui nous entoure, et revenez demain. Sur cette page, tous les examples sont tirés du Git de [[Frankiz]], mais voici d'autres dépôts bien utiles :
* [http://www.github.com/ GitHub]
* [http://git.frankiz.net/ Frankiz]
* [http://git.polytechnique.org/ Polytechnique.org]

== Récupérer le code d'un projet existant ==

Pour télécharger un projet existant, il y a deux possibilités : avec un compte de développeur ou sans compte. Avec un compte SSH simple, il suffit d'exécuter la commande suivante :
git clone mybeautifulname@git.frankiz.net:/hosting/git/frankiz
Sans compte, certains projets sont téléchargeables avec le protocole HTTP, mais vous ne pourrez pas uploader vos modifications.
git clone http://git.frankiz.net/frankiz

Cela crée un '''clone''' du dépôt d'origine (i.e une copie conforme), qui peut d'ailleurs servir de backup si le dépôt d'origine était perdu. Notre clone contient tout l'historique du dépôt depuis sa création, toutes les branches, etc. Cette première opération est très souple. On peut cloner des dépôt via SSH, HTTP, GIT, ou même en local le dépôt d'un autre utilisateur...

Par exemple la commande suivante clone dans le dossier ''platal'' la branche ''core/master'' d'une version de Plat/al potientiellement modifiée par le vice-prez 2010 :
git clone /home/2010/fishilico/dev/platal/.git platal -b core/master

== Accéder à l'aide ==
Avant toute chose, il est essentiel de savoir où trouver de l'aide, d'autant plus que l'aide de Git est très bien faite.
* Sur internet, il y a le wikiBR, les pages de manuel ([http://linux.die.net/man/1/git sur Linux Die] par exemple) et le [http://book.git-scm.com/ Git Book]
* En terminal, ''git help'' pour une liste des commandes, ''git help cmd'' ou ''git cmd --help'' pour l'aide complète de la commande ''cmd'', ou encore simplement ''git cmd -h'' pour une aide courte sur la commande ''cmd''

== Quel est l'état de ma copie de travail ? ==
Ceci est la question que vous devez vous posez avant de reprendre après une pause votre travail sur un projet versionné. Il peut y avoir eu des changements sur le projet entre temps, des patchs mal faits en production, ... Pour cela, il y a trois commandes essentielles :
* Pour vérifier que le dépôt est correct, ''git status'' doit dire cela :
git status
# On branch master
nothing to commit (working directory clean)
* En cours de travail, la réponse ressemble plus à :
git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: un-fichier-random.blah
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# un-fichier-chombier-ajouté.42
no changes added to commit (use "git add" and/or "git commit -a")
* Lire l'historique est bien pour savoir quel est le dernier commit
git log
commit 2a424aae1e746fb5f33de3b3bc3e8a31ee25c684
Author: Nicolas Iooss <fishilico@eleves.polytechnique.fr>
Date: Fri Mar 9 00:27:35 2012 +0100
* Voir les différences entre la version sur le dépôt distant et celle de travail
git diff

De plus, après avoir téléchargé les derniers commits avec ''git fetch'', il est possible d'obtenir le message suivant :
git status
# On branch master
# Your branch is behind 'origin/master' by 42 commits, and can be fast-forwarded.
Cela signifie que la copie locale a 42 commits de retard sur le dépôt distant, mais qu'un ''git rebase origin/master'' suffit pour mettre à jour la copie locale.

== Réinitialiser le dépôt ==
Pour restaurer un fichier, il suffit de le ''checkout'' à partir de l'index. En français, cela signifie que lorsque vous faites une modification sur un fichier, vous pouvez effacer les modifications et revenir la dernière version enregistrée dans l'index Git avec la commande :
git checkout -- chemin/vers/mon/fichier.blih
Pour réinitialiser l'index dans l'état indiqué par une branche (comme ''master'' par exemple) sans modifier les fichier, il suffit d'écrire :
git reset master
Si cela ne marche pas car des fichiers seront modifiés ou effacés, on peut forcer la main à Git, mais alors il faut être prêt à subir les conséqences que cela implique (perte des modifications non commitées)
git reset --hard master

== Mettre à jour la copie de travail ==
=== git fetch && git rebase origin/master ===
Dans le cas général, vous travaillez sur la branche ''master'' et vous synchronisez votre projet sur un seul serveur. Si votre cas est plus compliqué, vous devez être suffisamment compétent pour vous débrouillez par vous-même. On disait donc... dans le cas simple, Git stocke en interne deux branches : ''master'' et ''origin/master''. Sur Frankiz, c'est un peu plus compliqué car il y a une branche de production, mais les développeurs n'utilisent que master.
git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/f579e1971a66623b2948bf0e20c2e23481022b41
remotes/origin/fkz2
remotes/origin/kangz-h4ck3s
remotes/origin/master
remotes/origin/prod

Pour mettre à jour sa copie de travail, il faut donc commencer par mettre à jour les branches distantes, avec '''au choix''' l'une des commandes suivantes
git fetch
git fetch origin

Ensuite, il faut appliquer les éventuelles modifications locales à la suite de celles effectuées sur le dépôt, c'est le '''rebase'''.
git rebase origin/master
Git essaiera alors d'appliquer les commits locaux successivement, en indiquant chaque fois qu'il y a un problème (conflit ou fichier supprimé). En cas de problème, il faut
# Résoudre le problème (les fichiers avec des conflits apparaîssent comme ''Changed but not updated'' dans ''git status'')
# Ajouter les fichiers (''git add'')
# Indiquer à git de continuer : ''git rebase --continue''

Ceci permet de transformer l'état suivant (les ''O'' sont les commits, ''A'' le moment où les deux versions ont commencé à diverger, ''B'' la version du dépôt, ''E'' la version locale, ''C'' et ''D'' des commits locaux)

-C--D--E
/
-O--A--O--B

En l'état plus propre :
-O--A--O--B--C'--D'--E'

Avec C, D et E convertis en C', D' et E' : ils ont été modifiés pour être des modifications relatives à B au lieu de A.

=== Pourquoi il ne faut JAMAIS utiliser git pull ===
Certains développeurs utilisent la commande ''git pull'' pour mettre à jour leur dépôt. Cette pratique est justifiée lorsque la copie de travail était propre (sans commit en attente de push entre autres), mais sinon, cela peut avoir des conséquences très graves et sales. En effet, ''git pull' est assimilé à la succession de commandes suivantes :
git fetch origin && git merge origin/master
Le problème est le merge. En reprenant les schémas précédents, cela transforme l'état suivant :

-C--D--E
/
-O--A--O--B

en :

-C--D--E
/ \
-O--A--O--B----M

où M est le commit ''de fusion de branches''. '''Cela est très moche et à éviter absolument'''. Si vous vous retrouvez dans cette suituation (pour vérifier : ''git log''), vous pouvez toujours tenter un ''git rebase origin/master'' qui peut fonctionner si le ''merge'' était trivial (sans conflit). Sinon, un ''git reset --hard origin/master'' s'impose pour assurer votre salut.

=== Sauvegarder des modifications locales (git stash) ===
Avant de faire un merge particulièrement délicat, ou si l'on doit résoudre un bug alors que l'on a pas mal de modifications non commitées en cours, il est parfois utile de sauvegarder l'état courant de la copie de travail.

Pour cela, il faut utiliser '''avant''' un changement (avec ''git rebase'' par exemple) :
git stash
Une fois les modifications effectuées, on peut restorer la copie locale à l'état sauvegardé avec :
git stash pop

== Effectuer un commit ==
Un '''commit''' est un ensemble de fichiers modifiés. Cela permet plus de cohérence dans le suivi des versions. Par exemple, si l'ajout d'une fonctionnalité sur Frankiz modifie les fichiers ''blah'', ''blih'' et ''bloh'', le ''commit'' regroupe les modifications de ces trois fichiers, et associe à cette modification une date et un auteur.

Pour effectuer un commit, il faut :
* Vérifier l'état de la copie de travail, pour ne commiter que ce qui est nécessaire
git status
git diff
* Indiquer à Git quels fichiers feront partie du commit ; ceci permet de ne committer que les modifications de quelques fichiers
git add path/to/blih path/to/blah path/to/bloh
* Vérifier que l'on a ajouté les fichiers que l'on voulait :
git status
* Faire le commit (le ''-s'' ajoute une ligne ''Signed of by'' dans le message, pour pouvoir retrouver plus efficacement l'auteur réel du commit)
git commit -s
* Cette commande ouvre un éditeur (vi, nano ou emacs selon la configuration de la variable EDITOR). Il faut alors entrer un bref descriptif du commit. '''Pour certains projets (dont Frankiz), les conventions de codage obligent les développeurs à écrire les descriptions en anglais.''' Il est un bon usage de s'adapter en conséquence, car un commit peut être refusé en production s'il est mal fait.
* Mettre à jour la copie locale avec le dépôt distant (cela décale le nouveau commit à la fin). '''IL NE FAUT SURTOUT PAS FAIRE DE git pull OU DE git merge ICI'''
git fetch
git rebase origin/master
* Transmettre les commits au dépôt d'origine
git push

La dernière commande provient du fait que git n'est pas centralisé : il n'envoie pas les modifications locales au dépôt parent spontanément.

Ceci permet de faire quelques modifications locales puis de n'envoyer cela au reste des développeurs que lorsque les modifications sont stables et complètes, par exemple.

== Gérer les branches ==
On peut voir la liste des branches accessibles avec :
git branch -a
* La ligne avec une étoile est la branche courante
* Les lignes blanches sont les branches ''locales'' (elles suivent généralement une branche distante)
* Les lignes rouges (si les couleurs sont activées) sont les branches distantes.

Pour récupérer une autre branche, il faut d'abord l'ajouter localement :
git checkout -b NomLocal origin/NomDistant

Cela aura également pour effet de basculer sur la branche NomLocal.
Les modifications que l'on avait effectuées sont bien entendu conservées.

Une fois la branche ajoutée, on peut basculer de branche en branche à l'aide de :
git checkout NomLocal

== Créer un dépôt ==
Contrairement à [[SVN]] où il faut installer un serveur subversion, créer un dépôt Git est très rapide : dans le dossier que l'on souhaite versionner, il suffit de taper
git init
Et voilà, le dossier est versionné : on peut donc commencer à faire des modifications, des commits, etc. (bien entendu, on ne peut pas ''pusher'' ses commits, puisqu'il n'y a pas de serveur distant).

Cette particularité rend Git très efficace pour versionner un petit projet, un exercice de TD, etc.

Pour créer un dépôt qui peut être cloné, il faut exécuter les commandes suivantes :
git init --bare mon_projet
cd mon_projet && git update-server-info

Enfin, pour configurer un serveur HTTP (gitweb), il ne faut pas oublier de créer un fichier vide '''git-daemon-export-ok''' dans le dossier, afin de permettre le clonage.

== Structure interne ==

Git stocke les commits de manière très particulière : un commit correspond à peu près à une sauvegarde de l'état des fichiers, à un message, et à une référence vers le commit parent.
Contrairemant à [[SVN]], il n'y a donc pas de notion de numéro de révision : chaque commit est identifié par une chaîne hexadécimale de 40 caractères (par exemple : ''04fd02e59b1bdc430c7a7dcc1ca9f4cbc2b04037'' )

Un ''tag'' est en fait un nom «lisible» donné à un ''commit'' ; une ''branche'' indique également le ''commit'' principal d'une branche.

== Du bon usage de gitignore ==
Dans un projet, il est inutile de versionner les fichiers temporaires et les fichiers compilés (qu'ils soient binaires ou non). Ces projets utilisent généralement un Makefile pour créer ces fichiers. Pour éviter de les versionner, il suffit d'utiliser un fichier ''.gitignore'' bien placé. Généralement, chaque projet a un tel fichier dans son dossier princicial. Voici par exemple un extrait du gitignore de Frnakiz :
configs/frankiz.conf
htdocs/.htaccess
htdocs/data/*
htdocs/css/*
spool/*
upgrade/2.0.0_to_3.0.0/unversionned

== Configuration globale ==
Si vous avez déjà commitez, vous aurez certainement remarqué qu'il faut utiliser ''git config'' pour configurer vos informations personnelles. Ainsi, les deux premières commandes que tout utilisateur doit taper avant de faire un commit sont :
git config --global user.name "Prénom Nom de famille"
git config --global user.email "prenom.nom.promo@polytechnique.org"

Ensuite, si vous aimez les couleurs, vous avez envie de taper cette commande :
git config --global color.ui auto

Enfin, si vous en avez assez des projets qui ne mettent pas les fichiers temporaires dans le gitignore, vous pouvez configurer un fichier gitignore global. Si votre ''/home/user/.gitignore_global'' ressemble à
*~
*.swp
*.tmp
il suffit de taper :
git config --global core.excludesfile /home/user/.gitignore_global

Tout cela permet de gérer la configuration globale, visible par
git config --global -l
En enlevant ''--global'' dans toutes les commandes précédentes, on configure la copie locale.

== Utiliser le proxy de l'X avec Git ==
Si vous hébergez un projet sur [http://www.github.com GitHub], vous avez envie de dire à Git de se connecter à GitHub en SSH en passant par le proxy de l'X (qui est [http://kuzh.polytechnique.fr:8080 kuzh:8080]). Pour cela, il suffit de configurer le client SSH pour utiliser le proxy à chaque connexion vers github.com. Cela s'effecute par le fichier de configuration suivant dans /home/user/.ssh/config (adaptez avec votre dossier personnel)
Host github.com
ProxyCommand socat - PROXY:kuzh.polytechnique.fr:%h:%p,proxyport=8080

'''Si vous souhaitez uniquement cloner un dépôt GitHub''' dont vous n'êtes pas contributeur, il suffit d'utiliser le lien HTTPS en ligne de commande, en précisant le proxy.
export https_proxy=http://kuzh.polytechnique.fr:8080
git clone https://github.com/BinetReseau/frankiz.git

= Pour Windows =

Pour utiliser Git sur Windows, on peut par exemple télécharger MSys Git : [http://msysgit.github.com/ http://msysgit.github.com/].

Git

2012-10-11T22:28:29Z

Arthur : /* Du bon usage de gitignore */

Git est un [[VCS|système de contrôle de version]]. Assez proche de [[SVN]] par certains côtés, il présente néanmoins un grand nombre de différences.

Avant de découvrir les spécificités de Git, il est nécessaire de connaître les concepts généraux des [[VCS|systèmes de contrôle de version]].

Cette page donne un bref aperçu des fonctionnalités de Git. Un autre bon aperçu est disponible [http://giudoku.sourceforge.net/media/GitHandbook.pdf ici] (lien non BR)

== Dépôts ==

Alors que [[CVS]] et [[SVN]] sont des systèmes de versionnement centralisés (i.e un serveur contient le dépôt, et chaque utilisateur effectue un ''checkout'' depuis ce dépôt), Git est complètement décentralisé. Cela signifie que chaque contributeur a sa propre copie locale de tout l'historique d'un projet. Si aujourd'hui vous considérez que l'espace disque sur votre ordinateur est un problème, allez faire un tour, partez admirer les merveilles de la technologies qui nous entoure, et revenez demain. Sur cette page, tous les examples sont tirés du Git de [[Frankiz]], mais voici d'autres dépôts bien utiles :
* [http://www.github.com/ GitHub]
* [http://git.frankiz.net/ Frankiz]
* [http://git.polytechnique.org/ Polytechnique.org]

== Récupérer le code d'un projet existant ==

Pour télécharger un projet existant, il y a deux possibilités : avec un compte de développeur ou sans compte. Avec un compte SSH simple, il suffit d'exécuter la commande suivante :
git clone mybeautifulname@git.frankiz.net:/hosting/git/frankiz
Sans compte, certains projets sont téléchargeables avec le protocole HTTP, mais vous ne pourrez pas uploader vos modifications.
git clone http://git.frankiz.net/frankiz

Cela crée un '''clone''' du dépôt d'origine (i.e une copie conforme), qui peut d'ailleurs servir de backup si le dépôt d'origine était perdu. Notre clone contient tout l'historique du dépôt depuis sa création, toutes les branches, etc. Cette première opération est très souple. On peut cloner des dépôt via SSH, HTTP, GIT, ou même en local le dépôt d'un autre utilisateur...

Par exemple la commande suivante clone dans le dossier ''platal'' la branche ''core/master'' d'une version de Plat/al potientiellement modifiée par le vice-prez 2010 :
git clone /home/2010/fishilico/dev/platal/.git platal -b core/master

== Accéder à l'aide ==
Avant toute chose, il est essentiel de savoir où trouver de l'aide, d'autant plus que l'aide de Git est très bien faite.
* Sur internet, il y a le wikiBR, les pages de manuel ([http://linux.die.net/man/1/git sur Linux Die] par exemple) et le [http://book.git-scm.com/ Git Book]
* En terminal, ''git help'' pour une liste des commandes, ''git help cmd'' ou ''git cmd --help'' pour l'aide complète de la commande ''cmd'', ou encore simplement ''git cmd -h'' pour une aide courte sur la commande ''cmd''

== Quel est l'état de ma copie de travail ? ==
Ceci est la question que vous devez vous posez avant de reprendre après une pause votre travail sur un projet versionné. Il peut y avoir eu des changements sur le projet entre temps, des patchs mal faits en production, ... Pour cela, il y a trois commandes essentielles :
* Pour vérifier que le dépôt est correct, ''git status'' doit dire cela :
git status
# On branch master
nothing to commit (working directory clean)
* En cours de travail, la réponse ressemble plus à :
git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: un-fichier-random.blah
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# un-fichier-chombier-ajouté.42
no changes added to commit (use "git add" and/or "git commit -a")
* Lire l'historique est bien pour savoir quel est le dernier commit
git log
commit 2a424aae1e746fb5f33de3b3bc3e8a31ee25c684
Author: Nicolas Iooss <fishilico@eleves.polytechnique.fr>
Date: Fri Mar 9 00:27:35 2012 +0100
* Voir les différences entre la version sur le dépôt distant et celle de travail
git diff

De plus, après avoir téléchargé les derniers commits avec ''git fetch'', il est possible d'obtenir le message suivant :
git status
# On branch master
# Your branch is behind 'origin/master' by 42 commits, and can be fast-forwarded.
Cela signifie que la copie locale a 42 commits de retard sur le dépôt distant, mais qu'un ''git rebase origin/master'' suffit pour mettre à jour la copie locale.

== Réinitialiser le dépôt ==
Pour restaurer un fichier, il suffit de le ''checkout'' à partir de l'index. En français, cela signifie que lorsque vous faites une modification sur un fichier, vous pouvez effacer les modifications et revenir la dernière version enregistrée dans l'index Git avec la commande :
git checkout -- chemin/vers/mon/fichier.blih
Pour réinitialiser l'index dans l'état indiqué par une branche (comme ''master'' par exemple) sans modifier les fichier, il suffit d'écrire :
git reset master
Si cela ne marche pas car des fichiers seront modifiés ou effacés, on peut forcer la main à Git, mais alors il faut être prêt à subir les conséqences que cela implique (perte des modifications non commitées)
git reset --hard master

== Mettre à jour la copie de travail ==
=== git fetch && git rebase origin/master ===
Dans le cas général, vous travaillez sur la branche ''master'' et vous synchronisez votre projet sur un seul serveur. Si votre cas est plus compliqué, vous devez être suffisamment compétent pour vous débrouillez par vous-même. On disait donc... dans le cas simple, Git stocke en interne deux branches : ''master'' et ''origin/master''. Sur Frankiz, c'est un peu plus compliqué car il y a une branche de production, mais les développeurs n'utilisent que master.
git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/f579e1971a66623b2948bf0e20c2e23481022b41
remotes/origin/fkz2
remotes/origin/kangz-h4ck3s
remotes/origin/master
remotes/origin/prod

Pour mettre à jour sa copie de travail, il faut donc commencer par mettre à jour les branches distantes, avec '''au choix''' l'une des commandes suivantes
git fetch
git fetch origin

Ensuite, il faut appliquer les éventuelles modifications locales à la suite de celles effectuées sur le dépôt, c'est le '''rebase'''.
git rebase origin/master
Git essaiera alors d'appliquer les commits locaux successivement, en indiquant chaque fois qu'il y a un problème (conflit ou fichier supprimé). En cas de problème, il faut
# Résoudre le problème (les fichiers avec des conflits apparaîssent comme ''Changed but not updated'' dans ''git status'')
# Ajouter les fichiers (''git add'')
# Indiquer à git de continuer : ''git rebase --continue''

Ceci permet de transformer l'état suivant (les ''O'' sont les commits, ''A'' le moment où les deux versions ont commencé à diverger, ''B'' la version du dépôt, ''E'' la version locale, ''C'' et ''D'' des commits locaux)

-C--D--E
/
-O--A--O--B

En l'état plus propre :
-O--A--O--B--C'--D'--E'

Avec C, D et E convertis en C', D' et E' : ils ont été modifiés pour être des modifications relatives à B au lieu de A.

=== Pourquoi il ne faut JAMAIS utiliser git pull ===
Certains développeurs utilisent la commande ''git pull'' pour mettre à jour leur dépôt. Cette pratique est justifiée lorsque la copie de travail était propre (sans commit en attente de push entre autres), mais sinon, cela peut avoir des conséquences très graves et sales. En effet, ''git pull' est assimilé à la succession de commandes suivantes :
git fetch origin && git merge origin/master
Le problème est le merge. En reprenant les schémas précédents, cela transforme l'état suivant :

-C--D--E
/
-O--A--O--B

en :

-C--D--E
/ \
-O--A--O--B----M

où M est le commit ''de fusion de branches''. '''Cela est très moche et à éviter absolument'''. Si vous vous retrouvez dans cette suituation (pour vérifier : ''git log''), vous pouvez toujours tenter un ''git rebase origin/master'' qui peut fonctionner si le ''merge'' était trivial (sans conflit). Sinon, un ''git reset --hard origin/master'' s'impose pour assurer votre salut.

=== Sauvegarder des modifications locales (git stash) ===
Avant de faire un merge particulièrement délicat, ou si l'on doit résoudre un bug alors que l'on a pas mal de modifications non commitées en cours, il est parfois utile de sauvegarder l'état courant de la copie de travail.

Pour cela, il faut utiliser '''avant''' un changement (avec ''git rebase'' par exemple) :
git stash
Une fois les modifications effectuées, on peut restorer la copie locale à l'état sauvegardé avec :
git stash pop

== Effectuer un commit ==
Un '''commit''' est un ensemble de fichiers modifiés. Cela permet plus de cohérence dans le suivi des versions. Par exemple, si l'ajout d'une fonctionnalité sur Frankiz modifie les fichiers ''blah'', ''blih'' et ''bloh'', le ''commit'' regroupe les modifications de ces trois fichiers, et associe à cette modification une date et un auteur.

Pour effectuer un commit, il faut :
* Vérifier l'état de la copie de travail, pour ne commiter que ce qui est nécessaire
git status
git diff
* Indiquer à Git quels fichiers feront partie du commit ; ceci permet de ne committer que les modifications de quelques fichiers
git add path/to/blih path/to/blah path/to/bloh
* Vérifier que l'on a ajouté les fichiers que l'on voulait :
git status
* Faire le commit (le ''-s'' ajoute une ligne ''Signed of by'' dans le message, pour pouvoir retrouver plus efficacement l'auteur réel du commit)
git commit -s
* Cette commande ouvre un éditeur (vi, nano ou emacs selon la configuration de la variable EDITOR). Il faut alors entrer un bref descriptif du commit. '''Pour certains projets (dont Frankiz), les conventions de codage obligent les développeurs à écrire les descriptions en anglais.''' Il est un bon usage de s'adapter en conséquence, car un commit peut être refusé en production s'il est mal fait.
* Mettre à jour la copie locale avec le dépôt distant (cela décale le nouveau commit à la fin). '''IL NE FAUT SURTOUT PAS FAIRE DE git pull OU DE git merge ICI'''
git fetch
git rebase origin/master
* Transmettre les commits au dépôt d'origine
git push

La dernière commande provient du fait que git n'est pas centralisé : il n'envoie pas les modifications locales au dépôt parent spontanément.

Ceci permet de faire quelques modifications locales puis de n'envoyer cela au reste des développeurs que lorsque les modifications sont stables et complètes, par exemple.

== Gérer les branches ==
On peut voir la liste des branches accessibles avec :
git branch -a
* La ligne avec une étoile est la branche courante
* Les lignes blanches sont les branches ''locales'' (elles suivent généralement une branche distante)
* Les lignes rouges (si les couleurs sont activées) sont les branches distantes.

Pour récupérer une autre branche, il faut d'abord l'ajouter localement :
git checkout -b NomLocal origin/NomDistant

Cela aura également pour effet de basculer sur la branche NomLocal.
Les modifications que l'on avait effectuées sont bien entendu conservées.

Une fois la branche ajoutée, on peut basculer de branche en branche à l'aide de :
git checkout NomLocal

== Créer un dépôt ==
Contrairement à [[SVN]] où il faut installer un serveur subversion, créer un dépôt Git est très rapide : dans le dossier que l'on souhaite versionner, il suffit de taper
git init
Et voilà, le dossier est versionné : on peut donc commencer à faire des modifications, des commits, etc. (bien entendu, on ne peut pas ''pusher'' ses commits, puisqu'il n'y a pas de serveur distant).

Cette particularité rend Git très efficace pour versionner un petit projet, un exercice de TD, etc.

Pour créer un dépôt qui peut être cloné, il faut exécuter les commandes suivantes :
git init --bare mon_projet
cd mon_projet && git update-server-info

Enfin, pour configurer un serveur HTTP (gitweb), il ne faut pas oublier de créer un fichier vide '''git-daemon-export-ok''' dans le dossier, afin de permettre le clonage.

== Structure interne ==

Git stocke les commits de manière très particulière : un commit correspond à peu près à une sauvegarde de l'état des fichiers, à un message, et à une référence vers le commit parent.
Contrairemant à [[SVN]], il n'y a donc pas de notion de numéro de révision : chaque commit est identifié par une chaîne hexadécimale de 40 caractères (par exemple : ''04fd02e59b1bdc430c7a7dcc1ca9f4cbc2b04037'' )

Un ''tag'' est en fait un nom «lisible» donné à un ''commit'' ; une ''branche'' indique également le ''commit'' principal d'une branche.

== Du bon usage de gitignore ==
Dans un projet, il est inutile de versionner les fichiers temporaires et les fichiers compilés (qu'ils soit binaires ou non). Ces projets utilisent généralement un Makefile pour créer ces fichiers. Pour éviter de les versionner, il suffit d'utiliser un fichier ''.gitignore'' bien placé. Généralement, chaque projet a un tel fichier dans son dossier princicial. Voici par exemple un extrait du gitignore de Frnakiz :
configs/frankiz.conf
htdocs/.htaccess
htdocs/data/*
htdocs/css/*
spool/*
upgrade/2.0.0_to_3.0.0/unversionned

== Configuration globale ==
Si vous avez déjà commitez, vous aurez certainement remarqué qu'il faut utiliser ''git config'' pour configurer vos informations personnelles. Ainsi, les deux premières commandes que tout utilisateur doit taper avant de faire un commit sont :
git config --global user.name "Prénom Nom de famille"
git config --global user.email "prenom.nom.promo@polytechnique.org"

Ensuite, si vous aimez les couleurs, vous avez envie de taper cette commande :
git config --global color.ui auto

Enfin, si vous en avez assez des projets qui ne mettent pas les fichiers temporaires dans le gitignore, vous pouvez configurer un fichier gitignore global. Si votre ''/home/user/.gitignore_global'' ressemble à
*~
*.swp
*.tmp
il suffit de taper :
git config --global core.excludesfile /home/user/.gitignore_global

Tout cela permet de gérer la configuration globale, visible par
git config --global -l
En enlevant ''--global'' dans toutes les commandes précédentes, on configure la copie locale.

== Utiliser le proxy de l'X avec Git ==
Si vous hébergez un projet sur [http://www.github.com GitHub], vous avez envie de dire à Git de se connecter à GitHub en SSH en passant par le proxy de l'X (qui est [http://kuzh.polytechnique.fr:8080 kuzh:8080]). Pour cela, il suffit de configurer le client SSH pour utiliser le proxy à chaque connexion vers github.com. Cela s'effecute par le fichier de configuration suivant dans /home/user/.ssh/config (adaptez avec votre dossier personnel)
Host github.com
ProxyCommand socat - PROXY:kuzh.polytechnique.fr:%h:%p,proxyport=8080

'''Si vous souhaitez uniquement cloner un dépôt GitHub''' dont vous n'êtes pas contributeur, il suffit d'utiliser le lien HTTPS en ligne de commande, en précisant le proxy.
export https_proxy=http://kuzh.polytechnique.fr:8080
git clone https://github.com/BinetReseau/frankiz.git

= Pour Windows =

Pour utiliser Git sur Windows, on peut par exemple télécharger MSys Git : [http://msysgit.github.com/ http://msysgit.github.com/].

Contact

2012-01-22T18:22:45Z

Arthur : /* Contact */

{{menu BR}}

=== Contact ===
Vous pouvez contacter le BR :
* Par courrier electronique
** Pour des modifications de fiches TOL : tol *AT* eleves
** Pour les annonces Frankiz : web *AT* eleves
** Pour les brs : news *AT* eleves
** Pour les sites binets et les questions techniques : root *AT* eleves

* Par courrier postal
Binet Réseau - Kes des élèves
Ecole Polytechnique
91128 Palaiseau Cedex

Accueil

2011-11-02T15:06:19Z

Arthur :

__NOTOC____NOEDITSECTION__
=== Bienvenue sur le site du BR ! ===

Le Binet Réseau est l'association d'étudiants de l'[http://www.polytechnique.fr Ecole Polytechnique] qui s'occupent du réseau élève : maintenance des serveurs, mise en place de nouveaux services et développement (applications réseau et sites).

<div style="float: left; width: 46%; margin: 0 1% 0 0;">
=Les ressources en ligne=
==Utilisation de nos services==
* [[Miroir_FTP|Comment utiliser les miroirs FTP du BR?]]
* [[Configuration des clients pour le WiFi|Comment se connecter au WiFi?]]
* [[LDAP|Comment utiliser l'annuaire en ligne ?]] (permet de ne plus avoir à taper les adresses email!)
* [[Comptes Frankiz|Demander la création d'un compte Frankiz]]

==Fiches techniques==
* [[Pocket pc|Comment utiliser mon Pocket PC sur le réseau?]]
* [[Recuperation de donnees perdues|Comment récupérer mes données que j'ai effacées sur mon disque dur?]]
* [[Sauvegarde (ordinateur)|Comment faire une sauvegarde complète de mon système (sous Windows)?]]
</div>

<div style="float: right; width: 46%; margin: 0 1%;-moz-box-shadow: 1px 1px 12px #AAA; -webkit-box-shadow: 1px 1px 12px #AAA; padding: 1em; margin-top: 1em;">
===Le BR recrute===
Les membres du Binet Réseau ne sont pas pour autant tous des férus d'informatique et se partagent les taches en fonction de leurs capacités et de leurs envies : relations avec nos partenaires, communication avec les élèves constituent aussi des postes essentiels.

Ainsi, le Binet Reseau offre une chance unique d'approfondir ses connaissances en informatique, au service des autres et en se faisant plaisir
----
=== Deviens un membre actif du BR ! ===
À n'importe quelle époque de l'année, viens nous voir et nous t'accueillerons à bras ouverts. Il y a toujours des choses à faire pour améliorer les services ou faire de nouveaux services.
</div>
<div style="clear:both;"></div>

==En savoir plus sur...==
* [[News|Les brs]] (newsgroups) : quels brs existent ? comment ça marche ?
* [[Serveur IRC|IRC]] comme moyen de communication.
* [[MSDNAA|Les licenses MSDNAA]] : ce qui te permet d'avoir gratuitement '''et''' légalement Windows7 ou Visual Studio.

=N'hésite pas à nous contacter=
{| class="tableau-support"
| valign="top" |{{block|Au téléphone|support téléphone|Phone.png}}
| valign="top" |{{block|Par mail|support mail|Edit.png}}
| valign="top" |{{block|Sur les brs|support brs|News.png}}
| valign="top" |{{block|Sur IRC|support irc|Serveur.png}}
| valign="top" |{{block|En vrai|support vrai|People.png}}
|}

Comptes Sigma

2011-11-02T15:04:41Z

Arthur : Page créée avec « Contacter [mailto:frankiz@eleves.polytechnique.fr frankiz@eleves.polytechnique.fr] »

Contacter [mailto:frankiz@eleves.polytechnique.fr frankiz@eleves.polytechnique.fr]

Magouilleuse

2011-10-13T21:13:47Z

Arthur :

Cette page a pour but de faciliter le travail du magouilleur qui passera une ou deux semaines à La Courtine l'an prochain.

Une bonne connaissance de PHP, MYSQL et un peu de shell sont nécessaires pour ne pas se louper. Un root correct fait l'affaire.

Ne pas oublier d'activer le javascript dans la conf d'apache.

'''Me contacter à l'adresse qdm@melix.net pour récupérer les fichiers.'''

Le système est bien rôdé, il se compose de trois parties.

== L'interface web de choix des stages ==

Il s'agit d'un site web simple, en HTML / PHP / Javascript / MySQL. Ça tourne bien et c'est assez sécu.

Il n'accepte pas des choix qui ne répondent pas à des règles prédéfinies, et c'est pas insurmontable d'en rajouter...

Attention à les rajouter dans le javascript ainsi que dans le PHP, pour éviter de se faire niquer par des hackers en herbe...

== La Magouilleuse ==

Il s'agit d'une boîte noire programmée en python. Il faut avoir python 2.7 ainsi que quelques bibliothèques sur son ordinateur.
Un fichier README se trouve dans l'archive.

Sur un portable récent (core i7, 4Go de RAM) l'algorithme tourne en moins de deux minutes pour une groupe de 250 personnes.

== Une collection de scripts php / bash ==

Ces scripts sont très utiles pour
* importer un ficher excel dans la base des utilisateurs (il faut l'enregistrer en .csv avant),
* initaliser la table des choix/aptitudes
* importer les aptitudes / inaptitudes de chacun
* créer le fichier qu'on passe en entrée de la magouilleuse
* traiter le fichier de sortie de la magouilleuse, produire des statistiques ou un joli .csv

== Points importants ==
Voir avec l'infirmerie longtemps à l'avance pour récupérer les aptitudes de chacun. La nouvelle médecin-chef est souple et compréhensive.

Il faudrait lui donner à l'avance la liste des stages, pour qu'elle sorte un fichier adapté.

Penser à faire souvent des sauvegardes de la base de données, une mauvaise manip et tout fout le camp! Ça m'a servi plus qu'une fois!

Il faut s'y prendre longtemps à l'avance (mois de mai) pour s'assurer que tout tourne bien sur la machine perso du magouilleur.

== Organisation physique ==
Spammer [mailto:quentin.demetz@m4x.org QdM] ou [mailto:arthur.darcet@m4x.org Arthur] pour avoir des infos.

* Trois clients (Dell "fin", étiquetés "magouilleuse Client {1|2|3}"), IP = 129.104.201.6{1|2|3}) : Installation d'Archlinux normale. La seule config particulière est deux lignes dans <code>/etc/hosts</code> : <code>{magouilleuse|memorix} 129.104.201.60</code>
* Deux serveurs (Dell épais, étiquetés "magouilleuse Serveur {master|slave}", IP = 129.104.201.6{0|5}) : En dehors de l'IP et de la réplication mysql (qui n'est configurée que dans le sens master vers slave), les deux installations sont identiques.

Les serveurs ont Apache, mysql, php, phpmyadmin. Les mots de passe sont les habituels (root et mysql). Le site décrit au dessus est installé, ainsi qu'une version spéciale de memorix (pour retirer la possibilité de se connecter et d'ajouter des informations dans la base : c'est un site read-only). Un cron de backup SQL tourne normalement toutes les heures sur les deux serveurs pour faire un dump complet de la base de donnée.

À la courtine il suffit de brancher les cinq PC en RJ45 sur un switch (un de ceux du BJR qui sont au local) et tout tourne. Sur le platal il suffit de brancher les PC sur une prise dans le bataclan et ils ont internet (ils sont config pour utiliser la passerelle du bataclan). "Éventuellement" mettre à jour les PC avant de les embarquer l'année prochaine (ce n'est pas forcément une bonne idée : ça marche comme ça, un an de maj Archlinux c'est '''beaucoup''').

Si le serveur master meure : ne pas se poser trop de questions pour réparer, la base de donnée du slave est normalement parfaitement à jour. Donc éteindre le master et changer le <code>/etc/hosts</code> des trois clients pour mettre <code>{magouilleuse|memorix} 129.104.201.65</code>

itunnel est installé sur le serveur master : si le BRman a un pb à la courtine il peut brancher son iPhone sur le serveur et donner la main à quelqu'un d'autre.

Screen et IRC

2011-07-10T21:42:56Z

Arthur : /* Articles connexes */

== Introduction ==
C'est important de venir sur IRC chatter avec les membres du BR. Cela permet de discuter avec les autres BRmen, ce qui en plus d'être sympathique, est quand même quelque chose de parfois fondamental dans le travail de BRmen (quel qu'il soit), et donc dans le bon fonctionnement du BR de manière plus générale. Par ailleurs, on peut y trouver des anciens souvent disponibles, qui sont assez pratiques lorsqu'on a des questions. Le but de cet article est d'expliquer comment utiliser IRC comme un vrai BRman (ou une vraie BRwoman).

=== screen ? moaz ? IRC ? Petit tour d'horizon pour ceux qui sont déjà perdus ===

Tu peux trouver plus d'infos sur l'utilisation d'IRC à l'X [http://wikix.polytechnique.org/eleves/wikix/IRC sur le WikiX] ; voici juste un résumé de ce qui est utile à savoir : pour utiliser IRC, il faut se connecter à un serveur (ici, le serveur IRC du BR) par un logiciel que l'on appelle un client IRC. Les gens normaux utilisent un client IRC directement sur leur ordinateur pour se connecter à un serveur IRC (''cf'' la page du WikiX) ; mais au BR, on fait ça de façon un peu plus contournée mais beaucoup plus pratique - comme tu le verras par la suite. D'où cette page qui sert à expliquer cette méthode, dont je te conseille l'utilisation, quel que soit ton degré d'affinité avec les ordinateurs - elle n'est pas plus compliquée que la méthode normale et le gain est énorme.

Continuons notre tour d'horizon : screen est un logiciel qui permet de laisser fonctionner une session sur une machine distante, même lorsqu'on n'est plus en train d'utiliser cette machine (entre autres et en un peu simplifié, mais c'est cette fonctionnalité précise qui nous intéressera ici). L'idée, en l'occurrence, c'est de pouvoir laisser tourner un client IRC sur une machine du BR (et pas sur son ordinateur !), de façon à ne pas se déconnecter d'IRC lorsqu'on éteint son ordi (puisque le client IRC est sur la machine du BR, et pas sur son ordi personnel). On se connecte alors à la machine du BR pour utiliser le client IRC qui y tourne ; donc en gros, tout se déroule comme si on utilisait un client IRC sur son ordinateur, sauf qu'on utilise à la place un logiciel pour se connecter à une machine du BR et utiliser le client IRC qui fonctionne déjà sur cette machine, avec l'avantage que cette machine là ne s'éteint jamais (en principe). Cet avantage te parait peut-être minime, mais il est en fait assez fondamental : comme tout le monde n'est pas devant son ordinateur en même temps, il permet de pouvoir tenir des discussions sur IRC sans avoir à se déconnecter en plein milieu de la discussion parce qu'on va en cours ou parce que son ordi ne marche plus ; par ailleurs, de façon équivalente, il permet de garder l'historique des conversations à disposition sans passer par les logs. Enfin, de plus, il permet aussi de pouvoir accéder au client IRC par n'importe quel ordinateur qui peut se connecter à la machine du BR (donc n'importe quel ordinateur qui se trouve sur le platâl, ou même un smartphone qui se connecte via le wi-fi de la DSI... c'est une façon comme une autre de s'occuper en conf DFHM), et retrouver ainsi ses discussions sur IRC même si on utilise pas son propre ordinateur (enfin, il faut quand même faire attention lorsqu'on utilise un ordinateur public).

Et pour finir, moaz, c'est le petit nom de la machine du BR qui va héberger ton screen et ton client IRC persistant, et à laquelle tu vas se connecter pour les retrouver. Ainsi, pour résumer ce tour d'horizon, créer un screen sur moaz, cela te permet de laisser tourner ton client IRC (en l'occurrence irssi) tout le temps, et y accéder quand tu veux (voire d'où tu veux).

== Se connecter sur moaz ==

La connexion à moaz est la première étape à suivre. Pour se connecter à moaz, il y faut un compte ; en principe, on te l'a déjà créé, et si ce n'est pas le cas (ou si tu n'en sais rien), contacte un root (genre ton prez, il aime ça). Maintenant, la procédure pour se connecter à moaz est très simple et tu l'as peut-être même déjà suivie dans un autre cadre : il s'agit rigoureusement de la même que celle expliquée [http://wikix.polytechnique.org/eleves/wikix/Acc%C3%A8s_%C3%A0_distance_aux_ordinateurs_des_salles_info ici] pour accéder en ssh (''id est'' juste ouvrir une console) à un ordi des salles infos, sauf qu'à la place du nom de l'ordinateur de la salle info tu mets "moaz". Donc avec windows cela revient juste à lancer PuTTY, taper "moaz" pour le nom d'hôte, vérifier que le mode de connexion "SSH" est bien sélectionné, et cliquer sur "Open" ; sous Linux, cela revient à taper <code>ssh nom_d_utilisateur_sur_moaz@moaz</code> ; sous mac, je te laisse deviner.

== Utilisation de screen avec irssi ==

Une fois connecté sur moaz, lance screen. On arrive à une petite subtilité. Comme tu le sais maintenant, screen permet de lancer une session qui continue d'exister sur moaz une fois qu'on soit parti ; donc si tu as déjà lancé screen avant, et que tu te connectes sur moaz plus tard, il ne faut pas le lancer une seconde fois, il faut rejoindre la session déjà lancée. Par contre si tu n'as jamais lancé screen avant, il faut bien créer une session...

La commande suivante fait ce qu'il faut : si le screen <nowiki>irc</nowiki> (on pourrait choisir d'appeler son screen n'importe comment, ou de ne pas le nommer) n'existe pas, il est crée ; si le screen existe on le ré-attache (on le rejoint).
<nowiki>$ screen -RD irc</nowiki>

Ceci étant fait, tu es maintenant dans ta session screen ; partant de là, soit tu vois déjà IRC (si tu as rejoins une session qui existait déjà, et où irssi était déjà lancé, ce qui devrait généralement être le cas), soit tu ne vois pas IRC (si tu viens de lancer screen pour la première fois) et pour le lancer il te suffit de taper
<nowiki>$ irssi</nowiki>

Et hop, maintenant tu es connecté à IRC ! Bienvenue !

== Déconnexion ==

Lorsqu'on souhaite se déconnecter de moaz (pour redémarrer son ordi perso par exemple), il faut "détacher" le screen, avec C-a d (ça veut dire appuyer sur Ctrl et a en même temps, relâcher, puis appuyer sur d), ce qui ramène à la console de moaz depuis laquelle on peut fermer la session sur moaz (avec C-d sous linux, plus prosaïquement en fermant PuTTY sous Windows). La session screen et donc le client IRC irssi continuent alors à tourner sur moaz alors qu'on est déconnecté. Pour revenir, il suffit de se reconnecter à moaz puis de rejoindre le screen (mais tu sais déjà faire tout cela, non ?).

== Résumé ==

Si tu as déjà compris le principe d'utiliser screen et de te connecter à IRC et tout, ou si tu t'en fous et que tu veux juste aller vite, voici un résumé des actions à faire pour se connecter à IRC :
# Se connecter à moaz (PuTTY / <code>$ssh login@moaz</code> / ...)
# Rattacher ( = rejoindre) ta session screen avec <code>$ screen -RD irc</code>
# Éventuellement, lancer irssi avec <code>$ irssi</code> s'il n'est pas déjà en train de tourner
# Enjoy chatting

== Articles connexes ==

La page [[:screen]] contient des informations plus détaillées sur screen.

== Fichiers de config ==
Voilà des fichiers de config pour irssi et screen :
===~/.screenrc===
bell_msg "^G Bell in window %n"
autodetach on
startup_message off
nonblock on
vbell on
defutf8 on
defscrollback 1000

caption always
hardstatus string "%?%F%{= kG}%:%{= Wk}%? [$USER@%H] %n : %t"

# Always show lastline
caption string "%{= g}[ %{G}${USER}@%H%{g} ][%= %{= w}%?%-Lw%?%{r}(%{W}%n*%f %t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{B} %d/%m %{W}%c:%s %{g}][%{Y}%l%{g}]%{=b C}%{W}"

# Allow scrollback in xterm
termcap xterm* LP
termcapinfo xterm ti@:te@

===~/.irssi/config===
servers = (
{
address = "ircserver";
chatnet = "RezoSup";
port = "6767";
use_ssl = "yes";
ssl_verify = "no";
autoconnect = "yes";
no_proxy = "yes";
},
{
address = "irc.freenode.net";
chatnet = "FreeNode";
port = "6667";
autoconnect = "yes";
}
);

chatnets = {
RezoSup = {
type = "IRC";
nick = "Arthur";
autosendcmd = "/^msg nickserv IDENTIFY ******;";
};
FreeNode = {
type = "IRC";
nick = "ArthurD";
autosendcmd = "/^msg nickserv identify ******;";
};
};

channels = (
{ name = "#root-br"; chatnet = "RezoSup"; autojoin = "yes"; },
{ name = "#br-actif"; chatnet = "RezoSup"; autojoin = "yes"; },
{ name = "#br2k9"; chatnet = "RezoSup"; autojoin = "yes"; },
{ name = "#frankiz"; chatnet = "RezoSup"; autojoin = "yes"; },
{ name = "#news-br"; chatnet = "RezoSup"; autojoin = "yes"; },
{ name = "#web-br"; chatnet = "RezoSup"; autojoin = "yes"; },
{ name = "#br"; chatnet = "RezoSup"; autojoin = "yes"; },
{ name = "#irc-br"; chatnet = "RezoSup"; autojoin = "yes"; },
{ name = "#opers"; chatnet = "RezoSup"; autojoin = "yes"; },
{ name = "#x"; chatnet = "RezoSup"; autojoin = "yes"; },
{ name = "#federez"; chatnet = "RezoSup"; autojoin = "yes"; },
# { name = "#ascii"; chatnet = "RezoSup"; autojoin = "yes"; },
# { name = "#admin-windows"; chatnet = "RezoSup"; autojoin = "yes"; },
# { name = "#infobr"; chatnet = "RezoSup"; autojoin = "yes"; },
# { name = "#xnet"; chatnet = "RezoSup"; autojoin = "yes"; },
# { name = "#ailleurs"; chatnet = "RezoSup"; autojoin = "yes"; },
#TODO:Check if wanted#

# { name = "#poly.org"; chatnet = "Freenode"; autojoin = "yes"; },
{ name = "#archlinux"; chatnet = "RezoSup"; autojoin = "yes"; },
{ name = "#archlinux-fr"; chatnet = "Freenode"; autojoin = "yes"; },
# { name = "#gentoo"; chatnet = "Freenode"; autojoin = "yes"; }
# { name = "#physique"; chatnet = "RezoSup"; autojoin = "yes"; },
# { name = "#bural-br"; chatnet = "RezoSup"; autojoin = "yes"; },
# { name = "#resel"; chatnet = "RezoSup"; autojoin = "yes"; },
# { name = "#boulets"; chatnet = "RezoSup"; autojoin = "yes"; },
# { name = "#pi_perceptron"; chatnet = "RezoSup"; autojoin = "yes"; },
# { name = "#pendaison"; chatnet = "RezoSup"; autojoin = "yes"; },
# { name = "#br-vieux"; chatnet = "RezoSup"; autojoin = "yes"; },
# { name = "#br-private"; chatnet = "RezoSup"; autojoin = "yes"; },
# { name = "#channel"; chatnet = "freenode"; autojoin = "yes"; },
);

aliases = {
J = "join";
WJOIN = "join -window";
WQUERY = "query -window";
LEAVE = "part";
BYE = "quit";
EXIT = "quit";
SIGNOFF = "quit";
DESCRIBE = "action";
DATE = "time";
HOST = "userhost";
LAST = "lastlog";
SAY = "msg *";
WI = "whois";
WII = "whois $0 $0";
WW = "whowas";
W = "who";
N = "names";
M = "msg";
T = "topic";
C = "clear";
CL = "clear";
K = "kick";
KB = "kickban";
KN = "knockout";
BANS = "ban";
B = "ban";
MUB = "unban *";
UB = "unban";
IG = "ignore";
UNIG = "unignore";
SB = "scrollback";
UMODE = "mode $N";
WC = "window close";
WN = "window new hide";
SV = "say Irssi $J ($V) - http://irssi.org/";
GOTO = "sb goto";
CHAT = "dcc chat";

RUN = "SCRIPT LOAD";
UPTIME = "eval exec - expr `date +%s` - \\$F | awk '{print \"Irssi uptime: \"int(\\\\\\$1/3600/24)\"d \"int(\\\\\\$1/3600%24)\"h \"int(\\\\\\$1/60%60)\"m \"int(\\\\\\$1%60)\"s\" }'";
CALC = "exec - if which bc &>/dev/null\\; then echo '$*' | bc | awk '{print \"$*=\"$$1}'\\; else echo bc was not found\\; fi";
SBAR = "STATUSBAR";
INVITELIST = "mode $C +I";
Q = "QUERY";
"MANUAL-WINDOWS" = "set use_status_window off;set autocreate_windows off;set autocreate_query_level none;set autoclose_windows off;set reuse_unused_windows on;save";
EXEMPTLIST = "mode $C +e";
ATAG = "WINDOW SERVER";
ADDALLCHANNELS = "script exec foreach my \\$channel (Irssi::channels()) { Irssi::command(\"channel add -auto \\$channel->{name} \\$channel->{server}->{tag} \\$channel->{key}\")\\;}";
};

statusbar = {
# formats:
# when using {templates}, the template is shown only if it's argument isn't
# empty unless no argument is given. for example {sb} is printed always,
# but {sb $T} is printed only if $T isn't empty.
items = {
# start/end text in statusbars
barstart = "{sbstart}";
barend = "{sbend}";
topicbarstart = "{topicsbstart}";
topicbarend = "{topicsbend}";
# treated "normally", you could change the time/user name to whatever
time = "{sb $Z}";
user = "{sb {sbnickmode $cumode}$N{sbmode $usermode}{sbaway $A}}";
# treated specially .. window is printed with non-empty windows,
# window_empty is printed with empty windows
window = "{sb $winref:$itemname{sbmode $M}}";
window_empty = "{sb $winref{sbservertag $tag}}";
prompt = "{prompt $[.15]itemname}";
prompt_empty = "{prompt $winname}";
topic = " $topic";
topic_empty = " Irssi v$J - http://irssi.org/help/";
# all of these treated specially, they're only displayed when needed
lag = "{sb Lag: $0-}";
act = "{sb Act: $0-}";
more = "-- more --";
};
# there's two type of statusbars. root statusbars are either at the top
# of the screen or at the bottom of the screen. window statusbars are at
# the top/bottom of each split window in screen.

default = {
# the "default statusbar" to be displayed at the bottom of the window.
# contains all the normal items.
window = {
disabled = "no";
# window, root
type = "window";
# top, bottom
placement = "bottom";
# number
position = "1";
# active, inactive, always
visible = "active";
# list of items in statusbar in the display order
items = {
barstart = { priority = "100"; };
time = { };
user = { };
window = { };
window_empty = { };
lag = { priority = "-1"; };
more = { priority = "-1"; alignment = "right"; };
barend = { priority = "100"; alignment = "right"; };
usercount = { };
};
};
# statusbar to use in inactive split windows
window_inact = {
type = "window";
placement = "bottom";
position = "1";
visible = "inactive";
items = {
barstart = { priority = "100"; };
window = { };
window_empty = { };
more = { priority = "-1"; alignment = "right"; };
barend = { priority = "100"; alignment = "right"; };
};
};
# we treat input line as yet another statusbar :) It's possible to
# add other items before or after the input line item.
prompt = {
type = "root";
placement = "bottom";
# we want to be at the bottom always
position = "100";
visible = "always";
items = {
prompt = { priority = "-1"; };
prompt_empty = { priority = "-1"; };
# treated specially, this is the real input line.
input = { priority = "10"; };
};
};
# topicbar
topic = {
type = "root";
placement = "top";
position = "1";
visible = "always";
items = {
topicbarstart = { priority = "100"; };
topic = { };
topic_empty = { };
topicbarend = { priority = "100"; alignment = "right"; };
};
};
awl_0 = {
items = {
barstart = { priority = "100"; };
awl_0 = { };
barend = { priority = "100"; alignment = "right"; };
};
};
};
};

settings = {
core = {
real_name = "Arthur Darcet";
user_name = "Arthur";
nick = "Arthur";
recode = "yes";
recode_autodetect_utf8 = "yes";
recode_out_default_charset = "UTF-8";
recode_fallback = "CP1252";
server_reconnect_time = "10";
quit_message = "";
timestamp_format = "%d|%H:%M:%S";
# use_proxy = "yes";
# proxy_address = "129.104.247.2";
# proxy_port = "8080";
# proxy_string = "CONNECT %s:%d HTTP/1.0\012\012";
};
"fe-common/core" = {
autolog = "yes";
autolog_path = "~/irclogs/%Y/$tag-$0-%m-%d.log";
term_charset = "utf-8";
timestamps = "yes";
show_nickmode = "yes";
show_nickmode_empty = "yes";
theme = "mytheme";
bell_beeps = "yes";
beep_msg_level = "HILIGHT";
beep_when_window_active = "yes";
beep_when_away = "yes";
completion_char = " :";
};
"irc/core" = { lag_max_before_disconnect = "300"; knockout_time = "5"; };
"fe-text" = { indent = "8"; actlist_sort = "refnum"; };
"perl/core/scripts" = {
autorejoin_channels = "#root-br #br2k9 #br #x #news-br #frankiz #web-br #br-actif #federez #ascii #archlinux #archlinux-fr";
nicklist_automode = "screen";
awl_display_nokey_active = "$Q:$H$C$S";
awl_display_key = "$Q|$H$C$S";
awl_display_key_active = "$Q:$H$C$S";
awl_display_nokey = "$Q|$H$C$S";
};
};

hilights = (
# { text = "root"; nick = "yes"; word = "yes"; fullword = "no"; },
# {
# text = "CRIT";
# color = "%Y";
# nick = "no";
# word = "yes";
# fullword = "yes";
# channels = ( "#root-br" );
# },
# { text = "magnan"; nick = "yes"; word = "yes"; fullword = "yes"; },
{ text = "root"; nick = "yes"; word = "yes"; fullword = "yes"; },
{ text = "2k9"; nick = "yes"; word = "yes"; fullword = "yes"; },
{ text = "2009"; nick = "yes"; word = "yes"; fullword = "yes"; }
);

keyboard = (
{ key = "meta-a"; id = "change_window"; data = "2"; },
{ key = "meta-z"; id = "change_window"; data = "3"; },
{ key = "meta-e"; id = "change_window"; data = "4"; },
{ key = "meta-r"; id = "change_window"; data = "5"; },
{ key = "meta-t"; id = "change_window"; data = "6"; },
{ key = "meta-y"; id = "change_window"; data = "7"; },
{ key = "meta-u"; id = "change_window"; data = "8"; },
{ key = "meta-i"; id = "change_window"; data = "9"; },
{ key = "meta-o"; id = "change_window"; data = "10"; },
{ key = "meta-p"; id = "change_window"; data = "11"; },
{ key = "meta-q"; id = "change_window"; data = "12"; },
{ key = "meta-s"; id = "change_window"; data = "13"; },
{ key = "meta-d"; id = "change_window"; data = "14"; },
{ key = "meta-f"; id = "change_window"; data = "15"; },
{ key = "meta-g"; id = "change_window"; data = "16"; },
{ key = "meta-h"; id = "change_window"; data = "17"; },
{ key = "meta-j"; id = "change_window"; data = "18"; },
{ key = "meta-k"; id = "change_window"; data = "19"; },
{ key = "meta-l"; id = "change_window"; data = "20"; },
{ key = "meta-m"; id = "change_window"; data = "21"; }
);

logs = { };
ignores = ( );

Screen et IRC

2011-07-10T21:31:18Z

Arthur : /* Résumé */

Screen et IRC

2011-07-10T21:30:32Z

Arthur : /* Utilisation de screen avec irssi */

Frankiz

2011-07-07T08:38:18Z

Arthur : /* Authentification sur des sites externes */

Frankiz est le portail interne des élèves.

La version actuelle (3) a été lancée par le BR2k8 juste avant son départ du plateau. Elle est principalement destinée à pouvoir ouvrir l'utilisation de Frankiz aux écoles arrivant progressivement sur le plateau, et à devenir ainsi un portail de la vie associative du campus.

Le code de Frankiz3 est libre, et utilise git comme système de versionnement.
Il est intégralement disponible à l'adresse suivante : http://git.frankiz.net/frankiz/

= Développement =

Les principaux projets de développement sont actuellement (juillet 2001) :
* l'élargissement effectif aux autres écoles, en travaillant notamment sur :
** la simplicité de création de nouveaux comptes, avec nomination de modérateurs dans chaque école
** le cloisonnement des données et la possibilité de définir des champs de visibilité
* la création de mini-forums qui remplaceraient à la fois les annonces et les newsgroups

== Outils pour les développeurs ==
=== Authentification sur des sites externes ===

Frankiz permet à des sites externes (binets en particulier) d'utiliser sa base de données pour authentifier les utilisateurs.

Le webmaster du site en question doit auparavant faire une demande de mise en place de ce système en envoyant un mail à l'équipe frankiz (frankiz@frankiz.polytechnique.fr).
Il doit alors donner :
* l'url complète de la page de login de son site
* les informations auxquelles il souhaite accéder
* une justification de la demande (et oui, on ne partage évidemment pas notre base de données avec n'importe qui !)

Si la demande est acceptée, l'équipe frankiz renvoie alors une clé permettant d'authentifier les échanges d'informations entre frankiz et le site externe.
Le site est alors inscrit dans notre base de données, et peut utiliser le système d'authentification externe.

Ci dessous un exemple commenté de script d'authentification, à mettre sur le site externe :

<code php>

<?php
header($_SERVER['SERVER_PROTOCOL'] . ' 403 Forbidden');

//première étape, côté client

$timestamp = time(); // prendre le timestamp permet d'éviter le rejeu de la requête
$site = 'http://monsite/login'; // url de la page de login, doit correspondre *exactement* à celle entrée dans la base de données de frankiz (définie lors de l'inscription)

$location = "..."
// Champ non utile pour l'authentification et retransmis tel quel par frankiz.
// Il est prévu pour pouvoir mettre en place un système de redirection après
// authentification, vers la page à partir de laquelle le client avait tenté de se connecter.

$request = json_encode(array('names', 'rights'));
// Nature de la requête.
// Fkz renverra ici à la fois les noms de la personne mais aussi ses droits dans différents groupes.
// Il faut cependant que le site ait les droits sur les informations en question (à définir lors de son inscription).

$key = "..."; // clé fournie par l'équipe frankiz lors de l'inscription du site

$hash = md5($timestamp . $site . $key . $request);
// On hash le tout authentifier les données

$remote = $globals->frankiz->url . '/remote?' . 'timestamp=' . $timestamp . '&site=' . $site . '&location=' . $location . '&hash=' . $hash . '&request=' . $request;
header("Location:" . $remote); // et on redirige

// 2nd étape, côté frankiz :
// regarder sur git.frankiz.net si le code le code vous intéresse

// 3ème étape, côté client :

$timestamp = $_GET['timestamp'];
// On récupère le timestamp envoyé la première fois

if (abs($timestamp - time()) < 600)
{ // On vérifie qu'il est cohérent
$response = $_GET['response']; // On vérifie le hash de la réponse
if (md5($timestamp . $globals->frankiz->key . $response) == $_GET['hash'])
{
$response = json_decode($response, true); // On décode la réponse qui est en json
if (in_array('admin', $response['rights']['my_group']))
{ // On peut vérifier le niveau de droit de l'utilisateur dans certains groupes renvoyés
echo 'gagné !';
}
}
}

?>
</code>