Après un an de pause, voici le vingt-cinquième volet de la formation Git. Dans mon précédent article, j’ai décrit en détail le pull request, qui est une manière propre à la plateforme GitHub de fusionner des branches. Aujourd’hui nous allons aborder le travail en équipe et voir ce qui se passe lorsque plusieurs personnes partagent l’accès à un dépôt public.
Un peu de poésie
Puisque Git ne gère pas que du code mais tout généralement tout ce qui ressemble à du texte, profitons-en pour mettre un peu de poésie dans notre quotidien. Imaginons trois poètes nommés Charles, Paul et Stéphane qui décident de collaborer sur un projet d’anthologie de poésie symboliste.
Ne vous laissez pas induire en erreur par leur look rétro de poètes maudits. Nos trois poètes ne dédaignent pas l’utilisation d’outils modernes comme Git. Concrètement, Charles se connecte à son compte GitHub et décide de créer un nouveau projet public poesie-symboliste.
Évidemment que ce serait plus drôle si vous pouviez faire cet atelier pratique à trois, en endossant les rôles des trois poètes. Étant donné que la plupart de mes lecteurs sont seuls chez eux, j’ai adapté cet exercice de manière à ce que vous puissiez le faire tout seul.
Créez un répertoire ~/formation-git/atelier-37 et placez-vous dedans :
$ mkdir -v atelier-37 && cd $_ mkdir: created directory 'atelier-37' $ pwd /home/kikinovak/formation-git/atelier-37
Si vous vous demandez ce que veut bien dire le $_, il s’agit là d’une variable spéciale de Bash, qui contient la valeur de l’argument fourni à la dernière commande, en l’occurrence atelier-37.
Notez le lien SSH sur la page GitHub de votre projet et récupérez le dépôt de Charles dans un premier temps :
$ git clone git@github.com:kikinovak/poesie-symboliste.git clone-de-charles $ ls clone-de-charles $ ls -A clone-de-charles/ .git README.md
En temps normal, c’est mieux de garder le nom du répertoire créé par le clonage du dépôt. Or, nous souhaitons créer trois clones distincts ici. Nous renommons donc les dépôts successifs pour éviter les conflits de noms.
Procédez de même pour les dépôts de Paul et de Stéphane :
$ git clone git@github.com:kikinovak/poesie-symboliste.git clone-de-paul $ git clone git@github.com:kikinovak/poesie-symboliste.git clone-de-stephane $ ls -l total 12 drwxrwxr-x. 3 kikinovak kikinovak 4096 Apr 6 15:17 clone-de-charles drwxrwxr-x. 3 kikinovak kikinovak 4096 Apr 6 15:20 clone-de-paul drwxrwxr-x. 3 kikinovak kikinovak 4096 Apr 6 15:20 clone-de-stephane
Connectez-vous au clone local de Charles :
$ cd clone-de-charles/
Faites un état des lieux du dépôt. Affichez son état, son historique, les branches, etc. Une fois que c’est fait, éditez le fichier README.md qui a été créé automatiquement lors de l’initialisation, de manière à ce qu’il ressemble à ceci :
# Anthologie de poésie symboliste - *Charles Baudelaire*
Ajoutez le fichier à l’index et effectuez un commit :
$ git add README.md $ git commit -m "Édition du README."
Publiez ce que vous venez de faire :
$ git push Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Delta compression using up to 8 threads Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 323 bytes | 323.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 To github.com:kikinovak/poesie-symboliste.git e27f7a1..36e2d3d main -> main
À présent, c’est au tour de Paul de se connecter à son clone local :
$ cd ../clone-de-paul/
Une fois qu’il a fait un état des lieux, il a envie d’ajouter son grain de sel au fichier README.md. Mais avant de faire ça, il vient aux nouvelles pour voir si d’autres ont apporté des modifications depuis la création du projet :
$ git pull remote: Enumerating objects: 5, done. remote: Counting objects: 100% (5/5), done. remote: Compressing objects: 100% (2/2), done. remote: Total 3 (delta 0), reused 3 (delta 0), pack-reused 0 Unpacking objects: 100% (3/3), 303 bytes | 303.00 KiB/s, done. From github.com:kikinovak/poesie-symboliste e27f7a1..36e2d3d main -> origin/main Updating e27f7a1..36e2d3d Fast-forward README.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
Paul jette un œil au fichier modifié par Charles. Il décide de l’éditer pour ajouter son nom :
# Anthologie de poésie symboliste
- *Charles Baudelaire*
- *Paul Valéry*
Il ajoute le fichier à l’index et effectue un commit :
$ git add README.md $ git commit -m "README: ajout de Paul."
Et il publie ses modifications à son tour :
$ git push
Nous avons vu au tout début de cette formation que Git pouvait être configuré assez finement, par exemple en sélectionnant l’éditeur de texte préféré pour les messages de commit. Jetons un œil sur le paramètre push.default :
$ git config push.default simple
Ici, push.default est défini à simple, ce qui veut dire que lorsque nous effectuons un git push (ou un git pull), seule la branche sur laquelle nous nous trouvons actuellement est publiée (ou récupérée). C’est la variante qui réserve le moins de surprises, et c’est aussi celle que je vous conseille d’utiliser.
La branche principale (ou branche d’intégration) créée automatiquement avec le projet s’appelle main. Peut-être l’avez-vous remarqué, mais à chaque fois que vous effectuez un git push ou un git pull depuis la branche main, vous voyez passer une référence mystérieuse à une entité appelée origin/main. Essayons de voir de quoi il s’agit.
Vous savez que la commande git branch affiche la liste des branches de votre dépôt. L’option -v est un peu plus bavarde :
$ git branch -v
* main ad65904 README: ajout de Paul.
L’option -vv (encore plus bavard) vous affiche davantage de détails :
$ git branch -vv * main ad65904 [origin/main] README: ajout de Paul.
Nous retrouvons ici notre origin/main qui n’est rien d’autre que la branche de suivi à distance de la branche main. Et c’est aussi ce qui fera l’objet de notre prochain article, dans lequel nous nous intéresserons à la gestion des branches dans un projet géré à plusieurs.
Exercice
- Stéphane ne s’est pas encore mis au travail. Connectez-vous à son clone local et faites un état des lieux.
- Mettez à jour son clone par rapport à ce qui a été publié sur la plateforme GitHub.
- Stéphane voudrait bien que son nom (
Stéphane Mallarmé) figure également dans le fichierREADME.md. Il édite le fichier et publie ses modifications en prenant soin de lire les messages que Git lui affiche. - Maintenant que Stéphane a publié son travail, est-ce que Charles et Paul sont au courant de ce qu’il a ajouté ?
- Faites le nécessaire pour que les trois dépôts soient synchronisés et à jour avec les dernières modifications.
- Affichez les branches de suivi à distance dans les clones de chacun.
Lire la suite : Les branches de suivi à distance
La rédaction de cette documentation demande du temps et des quantités significatives de café espresso. Vous appréciez ce blog ? Offrez un café au rédacteur en cliquant sur la tasse.
0 commentaire