Voir la source de Utiliser un dépôt existant avec Git

Cette page suppose qu'un dépôt Git a déjà été inilialisé pour vous à l'adresse $REPO (qui est une URL du type <code>ssh://login@machine/chemin/vers/depot/</code>), et que vous avez les droits en lecture et écriture sur $REPO (pour mettre en place un tel dépôt, cf. la page [[Créer une archive partagée avec Git]]). Dans les exemples, on suppose aussi que le dépôt contient un fichier README.

== Récupération d'une copie du dépôt ==

Avec Git, on fait la plupart des opérations localement. On va donc commencer par récupérer une copie du dépôt :

 git clone $REPO copie-locale
 cd copie-locale

== Configuration de base ==

Pour travailler correctement, il faut se présenter à Git. Créer un fichier <code>~/.gitconfig</code> contenant au minimum les lignes :

<pre>
[user]
	name = Votre Nom
	email = Votre.Email@server.com
</pre>

Je recommande également les lignes

<pre>
[color]
	ui = auto
</pre>

Ce qui mettra de la couleur un peu partout dans l'interface en ligne de commande.

== Enregistrer ses modifications : Commit (en local) ==

On va maintenant faire quelques modifications.

 emacs README

Pour vérifier ce qu'on a fait :

 git status

et pour plus de détails :

 git diff HEAD

Si on est content avec ça, on peut enregistrer l'état courant dans l'historique :

 git commit -a

Ceci va lancer un éditeur de texte ($EDITOR), on entre un message descriptif du commit, on sauve et on ferme l'éditeur.

On peut recommencer, et faire autant de commits qu'on le souhaite.

== Où en est-on ? ==

Pour voir quels commits on vient de faire, on peut lancer par exemple :

 gitk --all

On voit les commits qu'on vient de faire en local (avec l'étiquette "master"), et le reste de l'historique (l'étiquette "remotes/origin/master" nous dit où en était l'historique au moment du clone).

Si on n'aime pas les interfaces graphiques, on peut aussi lancer :

 git log

== Récupérer les modifications du serveur ==

Si les autres utilisateurs ont continué à travailler dans $REPO, il est peut-être temps d'intégrer leurs modifications dans les notres.

Avant tout, on s'assure qu'on n'a pas de modifications non-commitées :

 git status

et si besoin, on fait un commit. Avec Git, on fait toujours un commit avant de tenter une fusion.

Maintenant, on peut récupérer les modifications de $REPO :

 git pull

S'il n'y a pas de conflit, c'est tout ce qu'il faut faire. Si il y a des conflits, alors il faut les résoudre (avec un éditeur de texte, chercher les <code><<<<<<</code> et <code>>>>>>>></code>), puis faire

 git commit -a

pour terminer la fusion.

== Publier ses modifications ==

Pour que les autres utilisateurs puissent voir nos modifications, il faut les envoyer au serveur :

 git push

Si il y a des révisions dans $REPO qui n'ont pas encore été fusionnées avec les votres (git pull), alors Git va refuser de les écraser, il faudra faire un <code>git pull</code> avant de relancer <code>git push</code>.

== Manipulations de fichiers (déplacement, ajout, suppression) ==

Lorsqu'on ajoute ou qu'on supprime un fichier, il faut informer Git :

 git add nouveau-fichier.txt
 git rm fichier-a-effacer.txt

Si on déplace un fichier, on peut utiliser « <code>git mv ancien nouveau</code> », mais « <code>git rm ancien; git add nouveau</code> » marche aussi : Git a une bonne heuristique de detection des renommages.

== Faire des commits partiels ==

Pour l'instant, on a utilisé <code>git commit -a</code> et <code>git status -a</code> (avec <code>-a</code>), ce qui veut dire qu'on a inclu toutes les modifications dans le commit. C'est la commande <code>git add</code>, qui fait en fait quelque chose de très différent de ce dont certains ont l'habitude avec <code>svn add</code> qui permet de dire quels fichier inclure dans le prochain commit. Les détails par ici : http://book.git-scm.com/3_normal_workflow.html

== Plus d'informations ==

* Sur ce wiki : la page [[Git]]
* Sur le web : http://git-scm.com

[[Catégorie:Git]]