envoi et rapatriement
Aujourd’hui, nous allons voir un autre concept simple mais puissant, commun à plusieurs systèmes de contrôle de version, que Git implémente : la distribution ! Comme vous le savez peux-être, les commits sont locaux et les dépôts sont simplement des copies les uns des autres. Cela veut dire que le véritable travail de distribution de vos projets est dans la synchronization des changements par des envois (git push) et des rapatriements (git pull).
Si vous découvrer Git, vous pouvez penser que tout cela est trop compliqué et qu’on contrôle moins ce qu’on fait. Une manière de voir les choses serait de se dire que si votre serveur central était défaillant, vous êtes mal et vous ne pouvez ni travailler ni collaborer avec les autres. Comme tout le travail de gestion des versions est fait sur votre machine, vous pouvez continuer à travailler même si le réseau ne fonctionne pas, sans nécessiter la permission de personnes tierces ou avec un réseau instable. Vous ai-je dit que cette organisation était plus rapide pour la plupart des opérations courantes ? Voici une list des avantages et inconvénients des SGVD sur Wikipedia.
Oliver Steele nous a préparé un dessin du fonctionnement de l’envoi et du rapatriement:
La partie supérieure du schéma est facile à comprendre, il s’agit d’ajouter des changements à la zone de transit. Après cette opération, la gestion des version est en place, mais il vous faut maintenant synchroniser vos données avec votre dépôt distant. Ce dernier peut se trouver sur un serveur d’hébergement comme GitHub, le serveur git de votre entreprise, une machine de production, ou bien le dépôt d’un de vos collègues. Une fois que vos changement ont été envoyés, d’autres personnes peuvent rapatrier (pull) ces données et travailler avec. Pour chaque opération dans Git, il y a plusieurs options, mais aujourd’hui nous ne considérerons que la commande pull.
Regardons ensemble un exemple concret. Je viens d’ajouter un lien Twitter au bas de la page de ce blog. Je veux envoyer (push) mes modifications dans le projet dépôt GitHub pour pouvoir mettre à jour le serveur. La syntaxe de cette commande est généralement la suivante git push <remote> <branch>. l’argument remote est simplement l’adresse d’une copie du dépôt. Celle ci contient les même données et le même historique, il ne reste plus qu’à le mettre à jour. La plupart des projets ont une branche distante origin, et une branche master par défaut.
$ git commit -am "Adding twitter link"
Created commit f2cd831: Adding twitter link
1 files changed, 1 insertions(+), 0 deletions(-)
$ git push origin master
Counting objects: 7, done.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 407 bytes, done.
Total 4 (delta 2), reused 0 (delta 0)
To git@github.com:qrush/gitready.git
361303d..f2cd831 master -> master
Maitenant notre dépôt distant est mis à jour, si vous vous rendez sur la page suivante de Github vous verrez les commits. La sortie de cette commande nous indique la manière utilisée par Git pour transférer les blobs de données qui ont changé, et nous informe que le dépôt a été mis à jour en précisant la nouvelle valeur du SHA1.
Qu’en est-il de la commande pull ? On peut utilsier cett commande pour mettre à jour n’importe quel dépôt avec les commits qui viennent d’être synchronisés. C’est exactement ce que fait le script minable de déploiement de notre projet :
$ git pull origin master
remote: Counting objects: 7, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 4 (delta 2), reused 0 (delta 0)
Updating 361303d..f2cd831
Fast forward
_layouts/default.html | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
Cette sortie nous montre que le dépôt du serveur a des changements à importer d’un dépôt distant, et il les importe. L’opération serait exactement la même si vous vouliez importer des changements qu’une autre personne aurait ajouté à votre dépôt.
Ceux qui ont forké le dépôt gitready sur GitHub peuvent également voir les changements que j’ai fait. D’autre didacticiels couvrerons cet aspect en profondeur.
Si vous avez d’autres idées ou concepts que nous aurions oubliés (nous parlerons des refspecs dans un prochain didacticiel), merci de nous le faire savoir.
