corrections on french translation for clone.

[gitmagic.git] / fr / clone.txt

== Clônons gaiement ==

Avec les anciens systèmes de gestion de version, l'opération standard pour obtenir un fichier est le checkout xxx. Vous obtenez un ensemble de fichiers correspondant à un état particulier précédement enregistré.

Avec Git et d'autres systèmes distribués de gestion de version, le clônage est l'opération standard. Pour obtenir des fichiers, on crée un 'clone' du dépôt entier. En d'autres termes, il s'agit de faire un http://fr.wikipedia.org/wiki/Site_miroir[miroir] du serveur central. Tout ce qui peut se faire sur le dépôt central peut être fait sur le vôtre.

=== Machines Synchros ===

Je peux imaginer faire des archives *tar* ou utiliser *rsync* pour des sauvegardes ou une synchronisation simple. Mais parfois j'édite sur mon portable, d'autres fois sur mon fixe, et les deux peuvent ne pas avoir communiqué entre temps.

Initialisez un dépôt Git et faites-le *commit* de vos fichiers sur une machine. Ensuite sur l'autre :

 $ git clone autre.ordinateur:/chemin/vers/les/fichiers

pour créer une deuxième copie de ces fichiers et dépôt Git.

À partir de ce moment,

 $ git commit -a
 $ git pull autre.ordinateur:/chemin/vers/les/fichiers HEAD

ira chercher l'état des fichiers sur l'autre ordinateur pour mettre à jour celui sur lequel vous travaillez. Si vous avez fait récemment des modifications en conflit dans le même fichiers, Git vous le signalera et vous devrez répéter à nouveau le commit après avoir résolu ces conflits.

=== gestion classique des sources ===

Initialisez le dépôt Git de vos fichiers :
 $ git init
 $ git add .
 $ git commit -m "Commit initial"

Sur le serveur central, initialisez un 'dépôt nu' (*bare* dans la terminologie G) dans un dossier quelconque :

 $ mkdir proj.git
 $ cd proj.git
 $ git init --bare
 $  # variante en une ligne : GIT_DIR=proj.git git init

Si besoin démarrez le démon (service) :

 $ git daemon --detach  # peut être tourne-t-il déjà

Pour les services d'hébergement en ligne, suivez les instructions fournies pour mettre en place le dépôt Git initialement vide. En général il s'agit de remplir un formulaire sur une page web.

'Poussez' votre projet au serveur central en utilisant :

 $ git push git://serveur.central/chemin/du/proj.git HEAD

Pour obtenir les sources, un développeur saisit :

 $ git clone git://serveur.central/chemin/du/proj.git

Après avoir fait des modifications, le développeur enregistre ses modifications en local :

 $ git commit -a

Met à jour à la dernière version :

 $ git pull

Tout conflit lors de la fusion doit être résolu puis validé :

 $ git commit -a

Pour envoyer vos modifications locales au dépôt central :

 $ git push

Si le serveur principal a des nouvelles modifications dûes à d'autres développeurs, l'envoi échoue et le développeur doit se mettre à jour de la dernière version, résoudre les éventuels conflits de fusion, puis essayer à nouveau.

=== Dépots nus ===

Un dépôt nu (*bare repository*) est nommé ainsi car il n'a pas de dossier de travail : il ne contient que des fichiers qui sont normalement cachés dans le sous dossier `.git`. En d'autres mots, il conserve l'historique d'un projet, et ne contient jamais le rendu d'une version donnée.

Un dépot nu joue un rôle similaire à celui du serveur principal dans un système de gestion de version centralisé : le receptacle de vos projets. Les développeurs clônent vos projets à partir de celui-ci et y poussent les dernières modifications officielles. En général il est placé sur un serveur qui ne fait quasiment que ce travail de distribution de l'information. Le développement s'opère sur les clônes de sorte que le dépôt principal peut se passer d'un dossier de travail.

Beaucoup des commandes de Git échouent sur un dépôt nu tant que la variable d'environnement `GIT_DIR` n'est pas renseignée avec le chemin vers le dépôt ou que l'option `--bare` n'est pas utilisée.

=== envoi contre rapatriement ( push contre pull ) ===

Pourquoi a-t-on introduit la commande `push` ( envoi ) au lieu de se contenter de la commande `pull` ( rapatriement ) plus familière ? Premièrement, la commande `pull` échoue sur un dépôt nu : il faut y utiliser la commande `fetch` dont nous parlerons plus tard. Mais même si nous conservions un dépôt standard sur le serveur central, y rapatrier les modifications serait peu pratique. Nous devrions d'abord nous connecter au serveur et donner en argument à la commande `pull` l'adresse de la machine de laquelle nous avons à rapatrier des modifications. Des pare-feu peuvent éventuellement nous embêter, et que faire si nous n'avons déjà pas d'accès `shell` au serveur ?

Quoiqu'il en soit, ce cas mis à part, nous décourageons l'envoi ( en comparaison du rapatriement ) parce que cela peut entrainer des confusions lorsque la destination possède un dossier de travail.

En condensé, pendant la phase d'apprentissage de Git, utilisez l'envoi ( push ) uniquement si la destination est un dépôt nu ; sinon rapatriez ( pull ).

=== Forker un projet ===

Vous en avez marre de la manière dont est géré un projet ? Vous pensez pouvoir faire mieux ? Dans ce cas, sur votre serveur :

 $ git clone git://serveur.principal/chemin/vers/les/fichiers

Ensuite, informez tout le monde de votre fork du projet sur votre serveur.

Par la suite, vous pouvez fusionner les modifications du projet originel avec :

 $ git pull

=== Ultime système de sauvegarde ===

Vous voulez des archives redondantes et géographiquement distribuées, permettant de faire face à un désastre XXX ? Si votre projet a beaucoup de développeurs, vous n'avez rien à faire ! Chaque clone de votre code est de fait une sauvegarde. Non seulement de l'état actuel, mais de l'historique complet. Grâce aux empreintes cryptographiques, si le clône de quelqu'un est corrompu, il sera repéré dès qu'il tentera de communiquer avec d'autres.

Si votre projet n'est pas si populaire, trouvez autant de serveurs que possible afin d'héberger vos clônes.

Le vrai paranoïac devrait toujours noter la dernière empreinte SHA1 de 20 octets du HEAD dans un endroit sûr. Ce doit être sûr, pas privé. Par exemple, le publier dans un quotidien marcherait bien, parce qu'il est difficile d'attaquer l'ensemble des copies d'un journal.

=== Le multi-tâche à la vitesse de la lumière ===

Imaginons que vous travailliez sur plusieurs fonctionnalités en parallèle. Dans ce cas validez ( commit ) votre projet et lancez :

 $ git clone . /un/nouveau/dossier

Git exploite les http://fr.wikipedia.org/wiki/Lien_mat%C3%A9riel[liens matériels] et le partage des fichiers de la manière la plus sûre possible pour créer ce clone, il est donc très rapidement disponible, et vous pouvez maintenant travailler simultanément sur deux fonctionnalités indépendantes. Par exemple vous pouvez modifier l'un des clones pendant que l'autre est en train de compiler.

À n'importe quel moment vous pouvez valider ( `commit` ) et rapatrier ( `pull` ) les modifications de l'autre clone.

 $ git pull /mon/autre/clone HEAD

=== Guerilla du contrôle de version ===

Alors que vous travaillez sur un projet qui utilise un autre système de gestion de versions, Git vous manque ? Dans ce cas, initialisez un dépôt Git dans votre dossier de travail.

 $ git init
 $ git add .
 $ git commit -m "Commit initial"

puis clonez-le :

 $ git clone . /un/nouveau/dossier

Allez ensuite dans le nouveau dossier et travaillez plutôt là, utilisant Git comme vous le voulez. De temps en temps, quand vous voulez vous synchroniser avec les autres, rendez-vous dans le dossier de départ, synchronisez en utilisant l'autre système de gestion de version, puis en saisissant :

 $ git add .
 $ git commit -m "Synchro avec les autres"

Puis allez dans le nouveau dossier et lancez :

 $ git commit -a -m "Description de mes modifications"
 $ git pull

La procédure pour partager vos modifications aux autres dépend de l'autre système de gestion de versions. Le nouveau dossier contient les fichiers avec vos modifications. Lancez toute commande de l'autre système de gestion de versions nécessaire pour les envoyer au dépôt central.

Subversion, qui est peut être le meilleur système de gestion de version centralisé est utilisé par d'innombrables projets. La commande *git svn* automatise la procédure ci-dessus pour les dépôts Subversion, et peut aussi être utilisée pour exporter un projet Git vers un dépôt Subversion.

=== Mercurial ===

Mercurial est un système de gestion de version similaire qui peut travailler quasiment sans heurt avec Git. Avec le plugin `hg-git` un utilisateur de Mercurial peut, sans rien perdre, envoyer ( push ) et rapatrier ( pull ) avec un dossier Git.

Téléchargez le plugin `hg-git` avec Git :

 $ git clone git://github.com/schacon/hg-git.git

ou Mercurial:

 $ hg clone http://bitbucket.org/durin42/hg-git/

Malheureusement, il ne semble pas y avoir un plugin analogue pour Git. Pour cette raison, il semble préférable d'utiliser Git plutôt que Mercurial pour le dépôt principal. Avec un projet Mercurial, il faut généralement un volontaire qui maintienne un dépôt Git en parallèle alors que, grâce au plugin `hg-git`, un projet Git fait l'affaire même pour les utilisateurs de Mercurial.

Bien que ce plugin puisse convertir un dépôt Mercurial en un dépôt Git en le poussant dans un dépôt vide, cette tâche est plus simple avec le script `hg-fast-export-git`, disponible via :

 $ git clone git://repo.or.cz/fast-export.git

Pour faire une conversion, dans un nouveau dossier :

 $ git init
 $ hg-fast-export.sh -r /depot/hg

ceci après avoir ajouté le script à votre `$PATH`.

=== Bazaar ===

Nous allons rapidement évoquer Bazaar parce que c'est le système de gestion de versions distribué libre le plus populaire après Git et Mercurial.

Bazaar à l'avantage d'avoir plus de recul, étant donné qu'il est relativement jeune ; ses concepteurs ont pu tirer les leçons du passé et éviter des petits écueils historiques. De plus ses développeurs ont le souci de la portabilité et de l'interopérabilité avec les autres systèmes de gestion de versions.

Un plugin `bzr-git` permet aux utilisateurs de Bazaar de travailler avec les dépôts Git dans une certaine mesure, et permet de le faire de manière incrémentale, tandis que `bzr-fast-export` est fait pous les conversions uniques.

=== Pourquoi j'utilise Git ===

Au départ j'ai choisi Git parce que j'ai entendu qu'il gérait l'inimaginablement ingérable source du noyaux Linux. Je n'ai jamais ressenti le besoin d'en changer. Git m'a rendu de fiers services et je ne me suis pour le moment pas heurté à ses limites. Comme j'utilise surtout Linux, les éventuels problèmes sur d'autres plateformes n'entrent pas en ligne de compte.

De plus je préfère les programmes C et les scripts bash aux exécutables comme les scripts Pythons : il y a moins de dépendances et je suis accro aux temps d'execution rapides.

J'ai réfléchi à la manière d'améliorer Git, allant suffisament loin pour écrire mes propres outils de type Git, mais uniquement à des fins de recherche. Même si j'avais terminé ce projet j'aurais tout de même continué avec Git vu que les avantages sont trop peu significatifs pour justifier l'utilisation d'un système farfelu.

Bien sur, vos besoins et envies diffèrent sûrement, et vous pouvez très bien vous trouver mieux avec un autre système. Quoiqu'il en soit vous ne pouvez pas faire une grosse erreur en choisissant Git.