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 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.
Sommaire
- 1 Récupération d'une copie du dépôt
- 2 Configuration de base
- 3 Enregistrer ses modifications : Commit (en local)
- 4 Où en est-on ?
- 5 Récupérer les modifications du serveur
- 6 Publier ses modifications
- 7 Manipulations de fichiers (déplacement, ajout, suppression)
- 8 Faire des commits partiels
- 9 Plus d'informations
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
- Sur ce wiki : la page Git
- Sur le web : http://git-scm.com