Git est un gestionnaire de versions (comme svn, cvs ou d'autres) décentralisé.

Un bon résumé de git et de son fonctionnement sur http://www.siteduzero.com/tutoriel-3-254198-gerez-vos-codes-source-avec-git.html

Avant de se lancer, il vaut mieux lire au moins les chapitres 1 et 2 du livre pro git http://git-scm.com/book/fr (ou un autre), pour bien comprendre les concepts de base (git fonctionne sur des snapshots de l'état du dépôt, faut d'abord cerner ce qu'est un blob et un objet commit), pour éviter ensuite de se retrouver dans une situation où l'on croyait savoir mais on y comprend plus rien. Il faut faire la distinction entre

• workspace : le répertoire courant, changer de branche revient à faire un échange de snapshots de ce répertoire (ou d'une partie), pas à en changer (par opposition à svn où on passe de trunk à branche/ma_branche)
• index (ou stage) : la liste de ce qui se passera au prochain commit. Contrairement à svn on peut faire un commit de plusieurs fichiers, mais pas forcément dans leur état courant, on commit l'index, donc il faut faire un add (passer dans l'index) puis commit, même si souvent on fait un “commit -a” qui revient à ajouter à l'index tous les fichiers modifiés puis à faire le commit. Pour une utilisation basique, i.e. si on ne fait que des “commit -a” sans add préalable, on peut oublier cet état, mais attention si vous faite un add puis modifier le fichier, un git diff donnera alors la différence depuis le add, pas depuis le dernier commit (pour ça faut préciser “git diff HEAD”). Ne pas oublier : “un commit est un pointeur vers l'instantané du contenu qui a été indexé” (un snapshot de ce qu'on a mis en stage|index). Rq c'est ce que j'ai compris de la littérature mais chez mois un commit -m “commentaire” fichier envoie le fichier dans son état actuel et pas dans l'état du dernier add :-S
• local repository : la base git locale (qui contient tout l'historique du dépôt)
• remote repository : un dépôt distant, il peut y en avoir plein, et on peut avoir des branches qui pointent vers différents dépôt.
• stash : ça on peut s'en passer dans un 1er temps, même si c'est pratique. C'est un espace “tampon”, pour y mettre ses modifs locales que l'on ne veut pas encore passer en commit (cf la remise pour des exemples). Indispensable avant de changer de branche par ex.

Résumé des commandes git :

• graphique interactif efficace : http://ndpsoftware.com/git-cheatsheet.html
• http://jonas.nitro.dk/git/quick-reference.html
• http://cheat.errtheblog.com/s/git
• https://na1.salesforce.com/help/doc/en/salesforce_git_developer_cheatsheet.pdf
• chez fedora

La référence (les pages man) : http://git-scm.com/docs

Il y a aussi le git community book en fr, avec son pdf

Des alias intéressant sur https://git.wiki.kernel.org/index.php/Aliases

La page de doc du plugin netbeans http://netbeans.org/kb/docs/ide/git.html

Le décentralisé c'est très bien, mais parfois un dépôt qui centralise est bien pratique, et c'est aussi possible.

Cf http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way, http://www.nikrou.net/post/2009/02/20/Mettre-en-place-un-d%C3%A9p%C3%B4t-central-git ou http://blog.touv.fr/2009/06/depot-git-prive-et-personnel-sur.html pour l'install du dépot central.

Ensuite, quelques liens utiles

• http://linux-attitude.fr/post/Git-%C3%A0-tous-les-%C3%A9tages
• http://alexgirard.com/git-book/3_workflows_distribu%25C3%25A9s.html
• http://xhfamily.com/x/notes/20080819_git-process.html

Pour créer un dépôt centralisé avec gitosis :

• http://www.siteduzero.com/tutoriel-3-187504-heberger-des-depots-git-avec-gitosis.html
• http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way

Pour créer le dépôt, faut d'abord modifier gitosis.conf pour lister le nouveau repository sur la ligne writable du group qui va bien (pour déclarer qui aura le droit d'écrire sur ce dépôt). Et pour modifier ce gitosis.conf

# Si ce n'est déjà fait on récupère une copie localement (coté client donc)
git clone git@<server>:gitosis-admin.git # on suppose que git est le user du server qui permet d'accéder aux dépôts)
cd gitosis-admin
joe gitosis.conf
# ensuite on envoie ce fichier
git commit -m 'ajout du dépot machintruc' gitosis.conf
git push
# et on peut balancer notre nouveau projet qui existe localement
cd /path/2/mon_projet
# si le dépot local git n'existe pas on le créé
git init
# on ajoute tous les fichiers (mais on pourrait n'en préciser que certains seulement)
git add .
git commit -a -m 'Premier commit'
# on créé le dépot distant (on a déjà déclaré mon_projet dans gitosis.conf tout à l'heure), on l'appelle origin
git remote add origin git@<server>:<mon_projet>.git
# et on envoie sur le depot origin notre branche locale master
git push origin master
# pour les push suivant, on pourra faire un simple "git push"

Pour que des anonymes puissent cloner un dépôt, il faut dire à git-daemon qu'il peut l'exporter en lecture seule sans vérifier les clés ssh avec

cd <le --base-path spécifié dans /etc/sv/git-daemon/run>
touch <mon_projet.git>/git-daemon-export-ok
# et pour retirer ces droits de lecture anonyme il suffit d'effacer ce fichier vide.

Avant le paquet git-daemon-run, il fallait créer un script de démarrage (cf historique de cette page), mais maintenant c'est dans debian :

aptitude install git-daemon-run
ln -s /usr/bin/sv /etc/init.d/git-daemon
# et on va modifier /etc/sv/git-daemon/run pour préciser le --base-path