Modifications entre les versions 12 et 14 (s'étendant sur 2 versions)
⇤ ← Version 12 à la date du 2008-11-24 21:35:34 →
Taille: 2242
Éditeur: JeanChristopheAndré
Commentaire: le pull est inutile juste après un push, mais il est à faire avant de commencer le travail
← Version 14 à la date du 2008-12-04 20:39:37 → ⇥
Taille: 3145
Éditeur: DavinBaragiotta
Commentaire:
Texte supprimé. Texte ajouté.
Ligne 3: Ligne 3:
||<#FFFF50> '''Page est en cours de rédaction.''' Ne pas la considérer comme une documentation valide !|| ||<#FFFF50> '''Page en cours de rédaction.''' Ne pas la considérer comme une documentation valide !||
Ligne 46: Ligne 46:
 * Ajouter au git local vos modifications (important car sinon git ignore certaines modifications telles que l'ajout de fichier)  * Vérifier le statut des fichiers par rapport au dernier commit
 {{{
$ git status
}}}
 * 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
}}}
 . mais aussi
Ligne 50: Ligne 62:
 . 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)
Ligne 52: Ligne 65:
$ git commit -a -m "Ma contribution de ce jour." $ git commit -a -m "Ma contribution du moment."
Ligne 54: Ligne 67:
 * 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.
Ligne 68: Ligne 86:
 . ''Dans `.git/info/exclude`. -- ProgFou''

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

Page en cours de rédaction. Ne pas la considérer comme une documentation valide !

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é ou ThomasNoël).

Installer le paquet git-core.

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
  • 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 remote add origin gitosis@git.auf:projet.git
$ git push origin master
  • Supprimer (sauvegarder) la copie locale du projet (incluant le répertoire racine)
  • Participer au développement du projet

Participer à un projet

  • Importer localement la version du serveur une première fois 
    $ git clone gitosis@git.auf:projet.git

  • Pour les fois suivante, récupérer localement la dernière version sur le serveur avant de commencer à éditer les fichiers 

    $ git pull
  • Éditer localement les fichiers
  • Vérifier le statut des fichiers par rapport au dernier commit 
    $ git status
  • 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
  • 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."
  • 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]

Expérimenter plusieurs voies grâce aux branches

À vérifier

Quand et où déclarer les exceptions à git (répertoires ou fichiers à ne pas suivre)?

ex.: cache/

  • Dans .git/info/exclude. -- ProgFou

Git/Développeur (dernière édition le 2015-07-21 00:00:23 par JeanChristopheAndré)