WikiTeki /  Modifications de « Git/Développeur »

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 : .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