||<#ffa0a0> /!\ Les dépôts de sources AUF sont en cours de transition vers [[../GitHub|GitHub]]. /!\ ||

<<TableOfContents>>

Page présentant les manipulations à faire dans une perspective de développeur.

Remplacer « projet » par le nom de votre projet.

Instructions suivantes fonctionnent avec Ubuntu 8.04 (Hardy Heron) et Git 1.5.4.3.

== Préalables ==
Fournir sa clé SSH à l'un des administrateurs de git.auf.org (MoussaNombré, JeanChristopheAndré).

Installer le paquet '''git-core'''. À partir de Debian Squeeze (ou Lenny + backports) et Ubuntu Natty, le paquet s'appelle `git`.

== Créer un nouveau projet ==
 * Contacter un administrateur de git.auf.org pour config du nouveau projet.
 * Projet public ou privé. [détailler]
 * Créer son projet localement
 * Configurer ce que git doit ignorer : [[#Ignorerdesfichiersoudesdossiers|.gitignore]]
 * Créer un git local avec tous les fichiers du projet
 {{{
$ cd projet
$ git init
$ git add .
}}}
 * Faire le premier commit local du projet
 {{{
$ git commit -a -m "Première version : mise en route du suivi."
}}}
 * Créer la première version du projet sur le serveur
 {{{
$ git config remote.origin.url ssh://gitosis@git.auf/projet
}}}
 ou pour le dépôt privé :
 {{{
$ git remote add origin gitosis@git.auf:projet.git
}}}
 puis :
 {{{
$ git push
}}}
 '''''Note : au besoin : git push origin master'''''
 * Supprimer (sauvegarder) la copie locale du projet (incluant le répertoire racine)
 * Participer au développement du projet

== Suivre un projet (par exemple avec notre git-web) ==
{{{
mnombre@preprod-web:~$ sudo su - git-web
git-web:~$ git clone git://git.auf.org/ific.git test.ific.auf.org
git-web:~$ cd test.ific.auf.org/
git-web:/srv/www/test.ific.auf.org$
}}}

Par la suite, la seule opération à faire sera juste des pull {{{
git-web:/srv/www/test.ific.auf.org$ git pull
}}} pour mettre à jour le dépôt local.

== Participer à un projet ==
 * Importer localement la version du serveur
 {{{
$ git clone ssh://gitosis@git.auf/projet
}}}
 ou pour le développement hors RPV :
 {{{
$ git clone gitosis@git.auf.org:projet.git
}}}
 ou pour projet dans dépôt privé :
 {{{
$ git clone gitosis@git.auf:projet.git
}}}
 ''Note: on n'a pas besoin de créer le répertoire du projet. Il sera automatiquement créé. Cette commande doit donc être lancée dans le répertoire parent.''
 * Ensuite le travail se fait en local : vérifier le statut des fichiers par rapport au dernier commit
 {{{
$ git status
}}}
 * Éditer localement les fichiers
 * Informer le git local de vos modifications (important car sinon git ignore certaines modifications telles que l'ajout de fichier)
 {{{
$ git add fichier
}}}
 . ou encore
 {{{
$ git rm fichier
}}}
 . (pour supprimer une arboresence, écrire le nom du répertoire à supprimer ainsi que -r [récursif]) mais aussi
 {{{
$ git add .
}}}
 . cependant attention : cette dernière commande pourrait annuler des `git rm` fait auparavant (on peut éviter ce problème en faisant des `git commit` réguliers)
 * Commiter localement les modifications faites
 {{{
$ git commit -a -m "Ma contribution du moment."
}}}
 ''Note: pour laisser un commentaire plus substantiel, omettre le paramètre -m... un éditeur texte sera lancé : la première ligne servira pour les logs, le reste pour le détail.''
 * Configurer la branche master (branche par défaut) :
 {{{
$ git config branch.master.remote origin
$ git config branch.master.merge refs/heads/master
}}}
 * Vérifier si vous avez bien la dernière version du serveur.
 {{{
$ git pull
}}}
 Si vous transmettez vos modifications au serveur mais que vous n'avez pas la dernière version à jour du serveur : votre version s'ajoute au serveur et votre git local vous invite à télécharger cette dernière version (et à régler les éventuels conflits)... Vaut mieux faire un « pull » avant, plutôt que de mettre une version sur le serveur sans être sûr que celle-ci inclut déjà la dernière modification.
 * Transmettre au serveur vos modifications
 {{{
$ git push
}}}

== Étiquetter une version ==
 Lorsque votre contribution correspond à une version stable, l'identifier en y apposant une étiquette avec le nom de la version. [détailler]

 * Ajouter une étiquette
 {{{
$ git tag -a -m "Commentaire etiquette" nom_etiquette
}}}

 Les étiquettes sont locales et ne seront pas transmises au serveur lors d'un push à moins de le spécifier explicitement.

 {{{
$ git push --tags
}}}
 ''Note: ce push ne transmet pas les commit au serveur, seulement les tags.''

 * Lister toutes les étiquettes
 {{{
$ git tag -l
}}}

 * Supprimer une étiquette localement
 {{{
$ git tag -d nom_etiquette
}}}

 * Supprimer une étiquette sur le serveur (à éviter)
 {{{
$ git push origin :refs/tags/nom_etiquette
}}}

 * Utiliser une étiquette
 {{{
$ git pull origin tag 1.3.1
}}}

 ''Fait un pull du serveur de la version correspondant à une étiquette spécifique (ici 1.3.1).''


== Utiliser des branches ==
Les branches permettent d'expérimenter plusieurs voies.

 * Importer localement une branche distante
 {{{
$ git fetch --all
$ git branch -r
$ git branch labranchevoulue -t origin/labranchevoulue
}}}
 * Créer une branche (local)
 {{{
$ git branch experimental
}}}
 ''Note: le contenu initial de cette nouvelle branche est le dernier commit (HEAD) de la branche en cours.''
 * Lister les branches (celle en cours marquée par un astérisque)
 {{{
$ git branch
  experimental
* master
}}}
 ''Note: créer une branche ne vous déplace pas dans celle-ci.''
 * Changer de branche
 {{{
$ git checkout experimental
$ git branch
* experimental
  master
}}}
 * Créer une branche (remote)
 {{{
$ git push origin mabrancheremote
}}}
 * Fusionner des branches
 {{{
$ git merge master
}}}
 ''Note: fusionne la branche en cours (ici : experimental) avec celle passée en paramètre (ici : master).''
 * Supprimer une branche (local)
 {{{
$ git branch -d mabranchelocale
}}}
 * Supprimer une branche (remote)
 {{{
$ git branch -d -r origin/mabrancheremote
}}}
 ou moins élégamment : 
 {{{
$ git push origin :mabrancheremote
}}}

== Ignorer des fichiers ou des dossiers ==

[[http://www.kernel.org/pub/software/scm/git/docs/gitignore.html]]

On peut lister les fichiers à ignorer dans le fichier .gitignore (à la racine du projet). Ce fichier pourra éventuellement être suivi par git et être partagé par tous les développeurs.
Par exemple, pour ignorer les fichiers `.pyc` et `.pyo`, on rajoute la ligne suivante dans le fichier .gitignore:
{{{
*.pyc
*.pyo
}}}

Pour ignorer les fichiers de façon locale (par exemple si votre éditeur de texte crée des fichiers tampons commençant par '~'), on rajoutera les règles d'exclusion plutôt dans le fichier `.git/info/exclude`
{{{
~*
}}}

=== Modèle de .gitignore ===

{{{
# binaires
*.pyc
*.pyo

# Fichier temporaires:
.*.swp
*~
\#*#
# src/*

# DB de dev
*.db

# restants de merge
*.orig
*.rej

# Configuration du projet - par environnement
conf.py
django.wsgi
local.cfg

# buildout
.installed.cfg
bin
develop-eggs
downloads
eggs
log
parts
tmp
}}}

== Workflow ==
Pour les développements plus substantiels...

=== Développement ===
 * Travailler localement dans la branche dev du projet (ou une autre branche, ex.: dev.user ou dev.fonctionnalite)
 {{{
$ git checkout dev
$ git branch dev.auth
$ git checkout dev.auth
(edit, commit)
$ git checkout dev
$ git merge dev.auth
}}}

  * Vérifier : lors du clone du projet, seulement la branche master existe localement...
  {{{
$ git clone gitosis@git.auf:projet.git test
$ git branch
* master
$ git branch -r
  origin/HEAD
  origin/dev
  origin/master
}}}

  * ... pour l'instant, créer les branches locales et puller le contenu distant
  {{{
$ git branch dev
$ git checkout dev
$ git pull origin dev
}}}
 * Transmettre au serveur vos modifications dans la branche correspondante
 {{{
$ git push origin dev
}}}
  * Pour éviter de saisir destination :
  {{{
$ git config branch.dev.remote origin
$ git config branch.dev.merge refs/heads/dev
$ git push
$ git pull
}}}

  * ... mais il semblerait que si la branche distante n'existe pas, il faille d'abord la créer avec :
  {{{
$ git push origin dev
}}}
 * Lorsqu'une version est stable, l'étiqueter
 {{{
$ git tag -a v2.4 -m "Commentaire etiquette"
}}}

=== Test ===

 * Promouvoir dans la branche test la dernière version de la branch dev
 {{{
$ git checkout test
$ git merge dev
}}}
 * Déployer dans l'environnement de test (admin système)
 * si les test sont concluants, promouvoir dans la branche master
 {{{
$ git checkout master
$ git merge test
}}}

=== Production ===
 * Déployer dans l'environnement de production (admin système)

== Configuration ==

Voici la configuration type d'un projet AUF avec les branches 'master' (PROD), 'dev' et 'test' : contenu de .git/config

Cette configuration permet de participer à projet (pull, push) dans et hors RPV.

Remplacer 'projet' dans remote.origin.url par le nom du dépôt git du projet en question.

 {{{
[core]
	repositoryformatversion = 0
	filemode = true
	bare = false
	logallrefupdates = true
[remote "origin"]
	url = ssh://gitosis@git.auf/projet
	fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
	remote = origin
	merge = refs/heads/master
[branch "dev"]
	remote = origin
	merge = refs/heads/dev
[branch "test"]
	remote = origin
	merge = refs/heads/test
}}}

----