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

Maintenant que vous avez étudié git, voyons à quoi il peut servir.

Configuration

Git peut, entre autre, fonctionner en local, comme RCS. Git est plus intéressant que d'autres outils comme svn pour plusieurs raison :

  • Il stocke tout en local à la racine du répertoire de travail
  • Il n'éparpille pas de fichiers un peu partout
  • Il prend 2 à 3 fois moins de place que svn pour des petits fichiers comme les fichiers de configuration
  • Il est un ordre de grandeur plus rapide que svn (ce qui importe peu pour /etc)

Notez que mercurial répond aussi à ces besoins.

Git est donc parfaitement adapté à votre configuration qui se trouve dans /etc :

# En root
$ cd /etc
$ git init

J'ai commencé par faire un "git add *" mais en pratique ce n'est pas une très bonne idée car on récupè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 conflit avec les gestionnaires de paquet et gestionnaire s de configuration et c'est assez gênant lors des migrations. Une bonne utilisation est plutôt de faire un "git add" uniquement pour les logiciels dont on modifie la configuration. Ainsi, vous avez dans votre dépôt toutes vos modifications et uniquement vos modifications. Cela nécessite de s'imposer de faire les "git add" mais c'est plus simple.

D'autre part, rien ne vous empêche d'avoir un cron de commit automatique pour rattraper 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 problème de configuration :

# 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 configuration

Mieux, j'utilise maintenant git pour mon home :

$ cd 
$ git init

Pour le coup, on ne met vraiment que ce qu'on modifie, au coup par coup. Pour savoir quoi y mettre, commencez par lister tout ce qui commence par un point :

$ ls -ad .*

A vous de savoir ce que vous voulez y mettre sachant que ça sera transféré sur toutes vos machines. Exemples :

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

Et du coup, il devient facile de se "téléporter". Dès que j'obtiens un compte sur une nouvelle machine, j'y emporte toute ma configuration. C'est assez simple (avec toutes 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écentralisé de git, vous pouvez faire les modification où bon vous semble et les propager au fur et à mesure de votre usage. Voyons cela !

Ne pas oublier de de commiter

Pour les gérer les oublis, Vous avez le choix entre un autocommit régulier (voir plus haut) et un warning automatique à chaque connexion

# dans mon .bashrc
$ git status | grep modified
Vérifier les mises à jour à chaque connexion

A chaque nouvelle connexion faites un git pull, cela vous mettra à jour les données en provenance de la machine parente. Vous avez ainsi une synchronisation quasi automatique de vos répertoires personnels entre vos comptes.

# je le mets dans mon .bashrc mais c'est assez lourd si vous n'avez pas de clé ssh
$ git pull
Pousser une mise à jour vers le parent

Lorsque vous faites une modification sur un machine qui n'est pas la source (celle pour laquelle vous n'avez pas fait de git clone), il est appréciable de faire un git push pour propager les choses dans l'autre sens. Un inconvénient toutefois, c'est un lourd difficile à faire. Le plus simple est de récupérer les données depuis la source, mais ce n'est pas toujours facile à faire, cela peut nécessiter plusieurs tunnels.

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