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

Tip & tricks

• http://mislav.uniqpath.com/2010/07/git-tips/

• Modifier le dernier message de commit git commit –amend -m “New commit message” (src)
• voir les serveurs distants (ajouter -v pour avoir les urls) git remote
• editer la conf par defaut git config -e

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

Ce qui suit est assez ancien et à prendre avec des pincettes (m'étonne qu'il n'y ai pas –bare pour la création du dépôt centralisateur).

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

Ci dessous qq démos, pour vous faire une idée.

Les ligne qui commencent par “#>” correspondent à la sortie de la commande précédente, pour permettre de copier/coller tout en console sans avoir de tri à faire

J'essaie ici d'avoir un dépôt local avec différentes branches qui suivent chacune son dépôt distant, mais le tracking marche pas comme ce que j'avais compris (testé en debian squeeze, avec git 1.7.2.5).

Voici ce que j'ai fait (un seul serveur ici, mais si ça marche pour A…)

mkdir serveurA 
cd serveurA/
h=$(basename $(pwd)); touch $h a c; echo $h > c;
git init --bare
 
# un clones (pour vérifier que le push sur les serveurs est bien ce qui est attendu)
cd ..
git clone serveurA cloneA
# et aussi pour le peuplement initial
cd cloneA
h=$(basename $(pwd)); touch $h c1 c2; echo $h > c2;
git add .
git commit -a -m "1er commit $h"
git push origin master
 
# et un dépôt local
cd ..
mkdir loc
cd loc
git init
# avec qq fichiers
h=$(basename $(pwd)); touch $h c2; echo $h > c2;
git add .
git commit -a -m "1er commit $h"
# ça nous a créé une branche master, mais on veut la nommer autrement pour pas confondre avec ceux des remote
# et éviter d′éventuel push/pull non désiré entre ce ce master local et les remote
git branch -m master commun
 
# un alias pour le serveur
git remote add remoteA ../serveurA master
 
# une branche que l′on va synchroniser avec le serveur A
git fetch remoteA                               # => 1er fetch donc créé la "branche" remoteA/master
git checkout --track -b brancheA remoteA/master # => créé la branche brancheA en lien avec remoteA/master
 
# on modifie un fichier
echo  "mod 1" > cloneA
git commit -m "mod 1" cloneA
# que l′on veut envoyer
git push
#>Everything up-to-date
# Ah bon ? Le tracking marche pas ?
git push remoteA brancheA:master
# ça push mieux
# 2e modif pour voir si ça track mieux maintenant qu′on lui a montré
echo  "mod 2" >> cloneA
git commit -m "mod 2" cloneA
git push
# tj rien :-S, et avec -u ?
git push -u remoteA brancheA:master
#> [...]
#> To ../serveurA
#>    3b00bff..cb44c59  brancheA -> master
#> Branch brancheA set up to track remote branch master from remoteA.
# ça parait pourtant clair, mais
echo  "mod 3" >> cloneA
git commit -a -m "mod 3"
git push
#> Everything up-to-date
# pas mieux...