Utiliser un dépôt existant avec Git

De Ensiwiki
Aller à : navigation, rechercher

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 ssh://login@machine/chemin/vers/depot/), 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 ~/.gitconfig contenant au minimum les lignes :

[user]
	name = Votre Nom
	email = Votre.Email@server.com

Je recommande également les lignes

[color]
	ui = auto

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 <<<<<< et >>>>>>>), 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 git pull avant de relancer git push.

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 « git mv ancien nouveau », mais « git rm ancien; git add nouveau » marche aussi : Git a une bonne heuristique de detection des renommages.

Faire des commits partiels

Pour l'instant, on a utilisé git commit -a et git status -a (avec -a), ce qui veut dire qu'on a inclu toutes les modifications dans le commit. C'est la commande git add, qui fait en fait quelque chose de très différent de ce dont certains ont l'habitude avec svn add 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