Travailler en équipe
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.
Un pour tous, tous pour un
É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 atelier-37 et placez-vous dedans :
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
Modifier le nom du dépôt local
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 :
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 :
Ajoutez le fichier à l'index et effectuez un commit :
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 :
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 :
Il ajoute le fichier à l'index et effectue un commit :
Et il publie ses modifications à son tour :
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 :
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 :
L'option -vv (encore plus bavard) vous affiche davantage de détails :
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 atelier pratique, dans lequel nous nous intéresserons à la
gestion des branches dans un projet géré à plusieurs.
À vous de jouer !
-
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 fichier
README.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.
La rédaction de cette documentation demande du temps et des quantités significatives de café espresso. Vous appréciez ce site ? Offrez un café au rédacteur en cliquant sur la tasse.
