Voici le vingt-deuxième volet de la formation Git. Dans mon précédent article, nous avons fait nos premiers pas avec un dépôt public. Nous avons effectué une petite modification sur notre clone local, et nous avons publié cette modification sur le dépôt publiquement accessible.
Avant d’aller plus loin et de voir en détail toutes les possibilités offertes par l’utilisation d’un tel dépôt public en termes de workflow et de travail en équipe, il n’est peut-être pas inutile de faire une petite mise en garde.
Certes, le travail avec un dépôt public ressemble à peu de choses près à ce que nous avons vu lorsque nous avons travaillé en local. Nous pouvons créer et éditer des fichiers et les ajouter à l’index de Git, créer des branches et basculer vers celles-ci, afficher la différence entre deux commits, etc.
Or, ce n’est pas par hasard que j’ai précisé « à peu de choses près ». Voyons aujourd’hui ce qui peut faire la différence lorsque vous travaillez avec un dépôt public. Suivez le guide.
Où est-ce que ça pousse ?
Pour commencer, ouvrez un terminal et rendez-vous à la racine du dépôt Git que nous avons récupéré dans notre précédent atelier pratique :
$ cd ~/formation-git/atelier-31/ $ ls the-art-of-command-line $ cd the-art-of-command-line/
Nous avons vu que la commande git push nous sert à publier un ou plusieurs commits. On pourrait se poser la question naïve : publier, mais où ? C’est la commande git remote qui va nous permettre de répondre à cette question :
$ git remote origin
Dans sa configuration par défaut, git remote affiche l’alias du dépôt public, en l’occurrence origin. Si nous voulons en savoir un peu plus, il suffit d’utiliser la commande avec l’option -v pour qu’elle soit un peu plus bavarde :
$ git remote -v
origin git@github.com:kikinovak/the-art-of-command-line.git (fetch)
origin git@github.com:kikinovak/the-art-of-command-line.git (push)
La deuxième ligne permet à Git de savoir ce qu’il faut faire lorsque nous invoquons git push. En effet, la commande git push est un raccourci pour git push origin. Lorsqu’on invoque git push, Git publie les modifications à l’URL qui s’affiche à la ligne correspondante affichée par git remote -v.
Lorsque nous travaillons en local, nous pouvons nous permettre de faire toutes sortes de choses :
- rectifier le tir et corriger le message du dernier commit avec
git commit --amend -m - supprimer le dernier commit avec un
git reset HEAD~1bien senti - attendre encore un peu avant de le publier
- etc.
Mais une fois que nous publions le ou les derniers commits avec git push, les choses se présentent un tout petit peu différemment. Au lieu d’un long discours théorique ennuyeux, je préfère vous fournir un exemple parlant.
Changer le cours de l’histoire
Voici l’historique récent de mon dépôt local :
$ git log --oneline --graph --all | head * be260d8 aimer -> aimez * 4d9f5b9 Merge pull request #810 from LLyaudet/patch-1 |\ | * edadec3 typos "intér" -> "inter" (2xactive, 1xagir) | * c257560 correction typo "intéractive" -> "interactive" * | 883ffc8 Merge pull request #811 from LLyaudet/patch-2 |\ \ | * | d46913c correction typo "aliases" -> "alias" | |/ * | 9e22e3a Merge pull request #816 from LLyaudet/patch-7
Et voici l’historique correspondant de mon dépôt public sur GitHub :
Lorsque j’ai publié mon dernier commit avec git push, Git a synchronisé la branche master de mon dépôt local avec la branche master correspondante du dépôt public. Regardez l’historique récent, et vous voyez que le dernier commit be260d8 est un descendant direct du commit parent 4d9f5b9.
Vous vous doutez bien que si maintenant je me mets à tripatouiller l’ID de mon dernier commit, je risque de semer la pagaille. Vous ne voyez pas trop ce que je veux dire ? Regardez bien :
$ git log --oneline | head -n 2 be260d8 aimer -> aimez 4d9f5b9 Merge pull request #810 from LLyaudet/patch-1 $ git commit --amend -m "Conjugaison correcte du verbe aimer." [master 3c073be] Conjugaison correcte du verbe aimer. Date: Wed Mar 1 10:35:21 2023 +0100 1 file changed, 1 insertion(+), 1 deletion(-)
Rappelez-vous que git commit --amend remplace le dernier commit avec un commit au contenu identique, mais avec un message de commit différent. Le hic, c’est que l’ID de ce commit a également changé, et je me retrouve avec un commit 3c073be qui descend du commit parent 4d9f5b9.
$ git log --oneline | head -n 2 3c073be Conjugaison correcte du verbe aimer. 4d9f5b9 Merge pull request #810 from LLyaudet/patch-1
En d’autres termes, j’ai réécrit l’histoire… et je me retrouve maintenant avec des historiques qui divergent dans mon dépôt local et dans mon dépôt public. Qu’est-ce qui va se passer maintenant si j’essaie de publier cette dernière modification ? Voyons voir :
$ git push To github.com:kikinovak/the-art-of-command-line.git ! [rejected] master -> master (non-fast-forward) error: failed to push some refs to 'github.com:kikinovak/the-art-of-command-line.git' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Integrate the remote changes (e.g. hint: 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.
Argh. Ça sent le roussi. Est-ce que j’ai tout cassé dans mon dépôt ?
Non, bien sûr. D’ailleurs, nous commençons à être rodés au fonctionnement de Git, et nous nous disons que ce n’est peut-être pas une mauvaise idée de jeter un œil sur ce qu’il nous suggère de faire :
$ git pull
Merge branch 'master' of github.com:kikinovak/the-art-of-command-line
...
$ git push
Enumerating objects: 2, done.
Counting objects: 100% (2/2), done.
Delta compression using up to 8 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 441 bytes | 441.00 KiB/s, done.
Total 2 (delta 0), reused 0 (delta 0), pack-reused 0
To github.com:kikinovak/the-art-of-command-line.git
be260d8..5bb5b57 master -> master
$ git status
On branch master
Your branch is up to date with 'origin/master'.
nothing to commit, working tree clean
Si la commande git pull ci-dessus vous retourne une erreur fatal: Not possible to fast-forward, aborting, tentez un coup de git pull --rebase qui permet de réconcilier deux branches divergentes. N’oubliez pas que le but de cet atelier pratique, c’est avant tout de vous faire prendre conscience des choses à ne pas faire lorsque vous travaillez en interaction avec un dépôt public.
J’ai réussi à remettre de l’ordre dans tout cela. Voici mon historique à jour :
$ git log --oneline --graph --all | head -n 6 * 5bb5b57 Merge branch 'master' of github.com:kikinovak/the-art-of-command-line |\ | * be260d8 aimer -> aimez * | 3c073be Conjugaison correcte du verbe aimer. |/ * 4d9f5b9 Merge pull request #810 from LLyaudet/patch-1
La conclusion que je retire de cette petite expérience, c’est que les commits publics ne se font pas n’importe comment.
Exercice
Essayez de répéter le petit atelier pratique ci-dessus avec votre dépôt GitLab rangé dans le répertoire atelier-32 :
- Affichez l’historique récent du dépôt en local et dans l’interface web de GitLab.
- Comparez ces deux historiques et notez le lien de parenté entre les deux derniers commits.
- Modifiez le message du dernier commit.
- Essayer de publier cette dernière modification.
- Essayez de comprendre les dégâts auxquels vous êtes confronté.
- Suivez les instructions de Git pour sauver les meubles.
Lire la suite : La fusion revisitée
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