Git pour tous

Niveau :
Résumé : cd && git init ; cd /etc && git init

Main­te­nant que vous avez étu­dié git, voyons à quoi il peut ser­vir.

Con­fi­gu­ra­tion

Git peut, entre autre, fonc­tion­ner en local, comme RCS. Git est plus inté­res­sant que d’autres outils comme svn pour plu­sieurs rai­son :

• Il sto­cke tout en local à la racine du réper­toire de tra­vail
• Il n’épar­pille pas de fichiers un peu par­tout
• Il prend 2 à 3 fois moins de place que svn pour des petits fichiers comme les fichiers de con­fi­gu­ra­tion
• Il est un ordre de gran­deur plus rapide que svn (ce qui importe peu pour /etc)

Notez que mer­cu­rial répond aussi à ces besoins.

Git est donc par­fai­te­ment adapté à votre con­fi­gu­ra­tion qui se trouve dans /etc :

# En root
$ cd /etc
$ git init

J’ai com­mencé par faire un “git add *” mais en pra­ti­que ce n’est pas une très bonne idée car on récu­père tout et n’importe quoi et à moins de ne pas avoir de backup, ce n’est pas très utile. En effet cela entre en con­flit avec les ges­tion­nai­res de paquet et ges­tion­naire s de con­fi­gu­ra­tion et c’est assez gênant lors des migra­tions. Une bonne uti­li­sa­tion est plu­tôt de faire un “git add” uni­que­ment pour les logi­ciels dont on modi­fie la con­fi­gu­ra­tion. Ainsi, vous avez dans votre dépôt tou­tes vos modi­fi­ca­tions et uni­que­ment vos modi­fi­ca­tions. Cela néces­site de s’impo­ser de faire les “git add” mais c’est plus sim­ple.

D’autre part, rien ne vous empê­che d’avoir un cron de com­mit auto­ma­ti­que pour rat­tra­per les cas où vous oubliez de le faire.

# Autocommit une fois par semaine, s'il n'y a rien à commiter, il ne fera rien
0 0 * * 1 cd /etc && git commit -a -m "Autocommit by cron"

Le jour où vous avez un pro­blème de con­fi­gu­ra­tion :

# On cherche ce qui a changé depuis le dernier commit (fonctionnel ?)
$ git diff
# On cherche quand ça a changé avant
$ git log
# On cherche ce qui a changé avant
$ git diff ee9eac2a4deb43e7c73b50444fcb7269f172fb69

Ma con­fi­gu­ra­tion

Mieux, j’uti­lise main­te­nant git pour mon home :

$ cd 
$ git init

Pour le coup, on ne met vrai­ment que ce qu’on modi­fie, au coup par coup. Pour savoir quoi y met­tre, com­men­cez par lis­ter tout ce qui com­mence par un point :

$ ls -ad .*

A vous de savoir ce que vous vou­lez y met­tre sachant que ça sera trans­féré sur tou­tes vos machi­nes. Exem­ples :

• .bashrc et les .bash_*
• .irssi
• .vimrc
• .ssh
• .gnupg

Et du coup, il devient facile de se “télé­por­ter”. Dès que j’obtiens un compte sur une nou­velle machine, j’y emporte toute ma con­fi­gu­ra­tion. C’est assez sim­ple (avec tou­tes les options) :

# Avec un git récent et une connexion bidirectionnelle
$ ssh peck@machine2.net
$ git clone ssh://peck@machine1.net/~peck/.git .

# Si la communication retour ne fonctionne pas directement
$ ssh -R 1022:localhost:22 peck@machine2.net
$ git clone ssh://peck@machine1.net:1022/~peck/.git .

# Si git se plaint de ne pouvoir créer le répertoire de destination
$ ssh peck@machine2.net
$ git clone ssh://peck@machine1.net/~peck/.git temporary
$ mv temporary/* .
$ rmdir temporary

De par le côté décen­tra­lisé de git, vous pou­vez faire les modi­fi­ca­tion où bon vous sem­ble et les pro­pa­ger au fur et à mesure de votre usage. Voyons cela !

Ne pas oublier de de com­mi­ter

Pour les gérer les oublis, Vous avez le choix entre un auto­com­mit régu­lier (voir plus haut) et un war­ning auto­ma­ti­que à cha­que con­nexion

# dans mon .bashrc
$ git status | grep modified

Véri­fier les mises à jour à cha­que con­nexion

A cha­que nou­velle con­nexion fai­tes un git pull, cela vous met­tra à jour les don­nées en pro­ve­nance de la machine parente. Vous avez ainsi une syn­chro­ni­sa­tion quasi auto­ma­ti­que de vos réper­toi­res per­son­nels entre vos comp­tes.

# je le mets dans mon .bashrc mais c'est assez lourd si vous n'avez pas de clé ssh
$ git pull

Pous­ser une mise à jour vers le parent

Lors­que vous fai­tes une modi­fi­ca­tion sur un machine qui n’est pas la source (celle pour laquelle vous n’avez pas fait de git clone), il est appré­cia­ble de faire un git push pour pro­pa­ger les cho­ses dans l’autre sens. Un incon­vé­nient tou­te­fois, c’est un lourd dif­fi­cile à faire. Le plus sim­ple est de récu­pé­rer les don­nées depuis la source, mais ce n’est pas tou­jours facile à faire, cela peut néces­si­ter plu­sieurs tun­nels.

# Sur la machine du changement 
$ git commit -a
# Sur la source
$ git pull ssh://peck@machine1.net/home/peck/.git