logo telecom ipp
logo cc by nc sa
Jean-Claude Dufourd
ue_outils_git_fusion

GIT: Exemple pratique de fusion

Clonez le dépôt: git@gitlab.enst.fr:jean-claude.dufourd/learning-merge.git

Il y a plusieurs branches à merger dans main, avec tous les cas entre merge auto, merge simple et merge qui force l’édition à la main.

Les branches sont:

  • initial: la branche de départ, ne pas toucher
  • initial_ignore: la branche dans laquelle j’ai ajouté un fichier .gitignore
  • main: une copie de initial_ignore avec laquelle vous allez travailler
  • pretty: initial avec une fonction pretty en plus et un peu de test de pretty
  • comment_test: initial avec des commentaires et plus de test
  • refac_no_comma: initial refactorée pour enlever les virgules qui pourraient troubler un débutant en python

GIT: Exemple pratique de fusion (suite)

Si vous executez test.py, ça doit toujours marcher. C’est donc le test pour vous assurer que les fusions se sont bien passées.

Les fusions à tester sont :

  • git checkout main puis git merge pretty : ça devrait être automatique, le commit est souvent automatique
  • sur cette branche main modifiée, git merge comment_test: avec un outil graphique de fusion (celui que vous préférez) choisissez les modifs à appliquer (à droite ou à gauche), et là, il faut faire commit une fois que c’est fini.
  • sur cette branche main modifiée, git merge refac_no_comma: avec un outil graphique de fusion, vous pouvez faire une partie de la fusion automatiquement, et vous devez editer la partie centrale si vous voulez vraiment conserver les changements des deux versions.

L’opération complète est montrée dans la prochaine vidéo.

GIT: TP Merge

GIT: TP Merge (suite)

Il est important que vous vous fassiez la main en faisant, avec les outils que vous choisissez, ces fusions sur ce dépot exemple.

GIT: Merge request ou pull request

Merge request et pull request sont des synonymes.

Ca ne marche pas pareil selon que c’est au sein d’un même projet ou si vous proposez une correction sur un projet dont vous n’êtes pas un des gérants.

Parfois, les dépôts sont initialisés avec la branche main “protégée”. Cela veut dire que seuls les intégrateurs, qui ont des droits supplémentaires (maintainer), peuvent faire commit sur la branche main. Si c’est le cas et que vous n’êtes pas intégrateurs (juste developer), alors vous devez passer par une merge request pour publier votre travail sur main. Par contre, vous pouvez commit sur toutes les branches non protégées.

GIT: Merge Request au sein d’un projet

Vous êtes plusieurs à travailler sur un projet. Vous travaillez chacun sur votre branche. A la fin du projet, l’un de vous est chargé de l’intégration du projet, c’est-à-dire de vérifier que tous les bouts du logiciel développés séparément fonctionnent ensemble.

Vous avez fini votre travail sur la branche X. Il ne reste plus qu’à fusionner la branche X avec la branche main pour intégrer votre partie. La bonne façon de faire est de créer une merge request.

Sur gitlab, dans votre projet, barre de gauche, “Merge Requests”, et dans cette page, New Merge Request

La video sur le transparent suivant vous montre ce processus en pratique.

GIT: Merge Request au sein d’un projet (video)

GIT: Fork et Merge Request

Je vous propose d’expérimenter en pratique une merge request, ou pull request. C’est une façon de dire au développeur d’un dépôt que vous avez fait une modification que vous pensez utile dans votre dépôt qui est une copie du sien, et vous lui dites où aller chercher la modification.

Faire une copie d’un dépôt s’appelle faire un fork. Le dépôt copie a le même nom que le dépôt de départ, donc il doit être dans un autre espace de nom. Suite à diverses limitations, nous devons faire cette expérimentation sur github et pas notre gitlab de Télécom.

Le scénario est :

  1. vous allez vous créer un compte sur github.com si vous n’en avez pas déjà un
  2. sur github, j’ai un dépot ueo_mergereq, https://github.com/jcdufourd/ueo_mergereq
  3. vous allez faire une copie de ce dépôt sur votre compte par fork, que j’appellerai D1 et il va être à l’URL https://github.com/votrelogingithub/ueo_mergereq
  4. vous allez créer une autre organisation avec vous seul.e comme participant.e, par exemple votrelogingithuborg, ceci pour créer un second espace de nommage
  5. vous allez faire un fork de votre fork de mon dépôt, que j’appelerai D2 et il va être à l’URL https://github.com/orgs/votrelogingithuborg/ueo_mergereq

GIT: Fork et Merge Request 2

Vous allez d’abord créer une merge request :

  1. cloner D2
  2. faire des modifications
  3. commit
  4. push
  5. aller dans l’interface github de D2 pour générer une merge request pour ce commit

Puis vous allez gérer la merge request :

  1. aller dans l’interface github de D1 pour voir et traiter cette merge request

Maintenant, vous comprenez sans doute pourquoi je vous ai fait faire 2 forks : il faut que vous ayez des droits sur D1 pour pouvoir gérer la merge request, et je ne peux pas vous donner les droits d’accès au dépôt d’origine.

Note: vous pourriez faire tout ceci avec un autre dépôt que le mien comme origine.

GIT: Fork et Merge Request