nalc-server/doc/Guide/dev-nalc.org

29 KiB
Raw Blame History

Guide de contribution et de développement du serveur NALC

  • Note taken on [2020-10-10 sam. 12:28]
    Les examples de commandes à taper dans le terminal commencent avec le symbole '$'. Le résultat des commandes sera affiché juste en dessous de la commande tapé.
  • Note taken on [2020-10-09 ven. 00:12]
    Pour les exemples donnés dans le guide nous serons l'utilisateur Sam.

Créer son compte gitea

Vous voulez contribuer, proposer vos corrections ou tester de nouvelles fonctionnalités ? Vous êtes au bon endroit. Pour commencer, créez-vous un compte sur le serveur de dépôts git que je met à disposition à cette adresse : https://sys4.fr/gitea Une fois inscrit vous pouvez vous connecter et ainsi commencer votre participation.

Créer des tickets de bugs

Si vous constatez un bug sur le serveur NALC vous pouvez déjà le rapporter directement en jeux avec la commande /report. Cette manière de faire est en général réservée aux joueurs qui n'ont pas de connaissances en développement. Pour ceux voulant contribuer de façon plus pointue, ou pour les personnes déjà contributrices en développement ou voulant le devenir, poster des tickets de bugs directement depuis l'interface de Gitea sera plus approprié et confortable.

Où poster les tickets

Pour des raisons pratiques les tickets concernants un bug du jeux ou qui semble provenir d'un mod en particulier, seront à poster dans le dépôt nalc-server-mods de l'organisation Notre Ami Le Cube. Pour les bugs qui concernent la gestion ou l'administration de serveur en lui-même (exemple : un bug avec le script d'installation) vous devrez les poster dans le dépôt nalc-server de l'organisation Notre Ami Le Cube.

Créer et installer sa version de NALC

Ici sera décrite l'installation du serveur avec l'intention de pouvoir proposer ses modifications (Pull Requests ou PR en abrégé). Donc cela sous-entend que vous devrez travailler sur vos propres bifurcations des dépôts que vous voudrez modifier (forks). Si vous êtes juste curieux et souhaitez tester la version de développement officielle sans vouloir apporter de modifications, reportez-vous au guide d'administration du serveur qui contient un chapitre sur l'installation du serveur.

Bifurquer les dépôts essentiels de NALC

Pour commencer, connectez vous avec votre identifiant sur le serveur de dépôts git. Puis rendez-vous sur le dépôt https://sys4.fr/gitea/nalc/nalc-server. Faites une bifurcation du dépôt : /gitea/nalc/nalc-server/media/commit/e9d363ee378ce61923c5d66c51e1762d4f5ece87/doc/Guide/nalc-dev-001.png Faites la même opération avec les dépôts suivants :

Vos dépôts bifurqués (en tant qu'utilisateur Sam) seront accessibles à ces adresses :

Cloner votre bifurcation du dépot nalc-server

Ouvrez un terminal bash depuis votre ordinateur puis faite un clone du dépôt que vous venez de bifurquer :

$ cd ~
$ git clone https://sys4.fr/gitea/Sam/nalc-server.git

Faire l'installation du serveur avec vos dépôts

Toujours depuis votre terminal, faire l'installation de la branche dev du serveur:

$ cd ~/nalc-server
$ ./install.sh --url https://sys4.fr/gitea/Sam dev

Configuration de fichiers

Après l'installation il faut configurer quelques fichiers.

minetest.conf

Changer la valeur "name = sys4" par "name = Sam" pour définir le joueur qui sera l'administrateur.

start.sh

Dans ce script bash, changer les variables suivantes avec ces valeurs :

  • serverpath="/home/Sam/nalc-server"
  • world="$serverpath/minetest/worlds/nalc-dev"

Plus bas, dans la commande qui lance ./minetestserver changer le port (port …) avec la valeur 30000

shutdown.sh

Dans ce script bash, changer les variables suivantes avec ces valeurs :

  • serverpath="/home/Sam/nalc-server"
  • world="nalc-dev"
  • branch="dev"
backup.sh (optionnel)

À modifier comme souhaité si vous voulez utiliser cette fonctionnalité. Ce script en l'état ne permet de sauvegarder un serveur que si le backend utilisé est postgresql.

Désactiver le mod irc et irc_commands

Je prends cet exemple car c'est celui que vous serez amené à faire le plus souvent et que je recommende fortement d'ailleurs. Bien sûr cela peut s'appliquer à tous les mods que vous souhaitez désactiver. Il faut éditer le fichier upgrade.sh vers la ligne 108 pour y ajouter dans la variable mods la liste des mods à désactiver. Voici un extrait de ce à quoi cela doit ressembler :

    elif [[ $BRANCH == "dev" || $BRANCH == "1.2" || $BRANCH == "1.3" || $BRANCH == "stable" ]]; then
 mods="3d_armor_ip 3d_armor_sfinv 3dmushrooms irc irc_commands"
    fi

Ensuite appliquer le changement qui restera permanent en exécutant le script upgrade de la façon suivante :

$ ./upgrade.sh -w nalc-dev -b dev -f worldmt

Le fichier world.mt a été regénéré pour vous par le script. Plus tard, si le fichier world.mt devait être régénéré pour une autre raison, vous n'aurez pas à vous soucier de la désactivation de ces mods puisque mémorisés dans le script. Pour les réactiver il faudra simplement les supprimer du script puis éxécuter le script de nouveau comme précédemment.

Changer le backend de la map (optionnel)

Le backend de la map est configuré par défaut pour être en leveldb, à moins que vous ayez choisis de faire l'installation avec un backend en potgresql. Libre à vous de changer le backend par ce que vous souhaitez tant que vous n'avez pas encore lancé le serveur. Pour ce faire, éditez le fichier world.mt qui se trouve dans le dossier racine du serveur (là où vous êtes déjà normalement), puis changer le backend par une autre valeur comme sqlite3 par exemple. Quand vous aurez modifié ce fichier, il faut l'appliquer à votre world. Pour cela il faut lancer le script upgrade.sh de nouveau de la même manière que précédemment :

$ ./upgrade.sh -w nalc-dev -b dev -f worldmt

Lancer le serveur

Vous êtes prêt pour le démarrage du serveur. Vous pouvez le faire de deux manières. Soit de manière classique soit à l'aide du script shutdown.sh

Manière classique

$ cd minetest/bin
$ ./minetestserver --gameid nalc_game --port 30000 --worldname nalc-dev

Pour arrêter le serveur il vous suffira de faire les touches [CTRL+C] du clavier.

Avec shutdown.sh

Oui ça peut paraître bizarre mais de lancer le serveur avec ce script permettra de le lancer en arrière plan et il vous rendra la main sur votre terminal. De plus, si le serveur lancé de cette façon venait à crasher plus tard, il sera relancé automatiquement au bout de 25 secondes. Le rôle premier de ce script est d'éteindre proprement le serveur, mais permet aussi de le relancer. C'est ce que nous allons faire, même si le serveur n'a pas encore démarré. Ce script est pratique pour être lancé en tâche cron au démarrage de votre ordinateur.

$ ./shutdown.sh -r

Au bout de quelques secondes, vous vous retrouverez à nouveau sur le prompt de votre terminal pendant que le serveur est entrain de se lancer en arrière plan. Dans ce contexte pour voir les logs du serveur en temps réèl vous pouvez lancer la commande suivante depuis n'importe quel terminal :

$ tail -f ~/nalc-server/logs/moredebug.log

Pour arrêter le serveur :

$ ./shutdown.sh

Développer le serveur

Vous avez réussi à lancer votre propre fork du serveur, mais celui-ci est identique à l'original pour le moment et n'intègre pas encore vos corrections ou les changements qui vous tiennent tant à coeur. Au travers de l'exemple suivant, voici une méthode pour modifier un mod que vous aurez bifurqué (fork) et que vous intégrerez à votre serveur. Puis vous demanderez à ce que cette modification soit fusionnée dans le dépôt officiel de NALC avec la fonction demande d'ajout proposé par gitea. C'est l'équivalent des Pull Requests de GitHub.

Modifier un mod

  • Note taken on [2020-10-10 sam. 10:04]
    Pour illustrer les exemples suivants, nous modifierons le mod riesenpilz toujours en tant qu'utilisateur Sam.
Déterminer le dépôt d'origine du mod

Cette étape est importante car vous devez travailler sur une bifurcation du dépôt d'origine. La commande suivante permet de connaître l'url du dépôt d'origine.

$ cd ~/nalc-server/nalc-server-mods/riesenpilz
$ git remote get-url origin
https://sys4.fr/gitea/nalc/riesenpilz.git
Bifurcation du mod

Maintenant que vous connaissez l'url du mod à bifurquer, connectez-vous sur votre compte gitea puis rendez-vous sur la page du dépôt en question. Pour l'exemple il s'agira donc du dépôt https://sys4.fr/gitea/nalc/riesenpilz Faites la bifurcation du mod pour créer votre propre copie : /gitea/nalc/nalc-server/media/commit/e9d363ee378ce61923c5d66c51e1762d4f5ece87/doc/Guide/nalc-dev-001.png Si nous reprenons l'exemple avec le mod riesenpilz et l'utilisateur Sam, vous devriez obtenir votre propre mod bifurqué accessible à l'adresse suivante : https://sys4.fr/gitea/Sam/riesenpilz.git

Intégrer le mod bifurqué dans votre copie de NALC

Actuellement le submodule git riesenpilz de dépôt nalc-server-mods pointe toujours vers le dépôt d'origine. Il faut changer cela afin que le submodule puisse être synchronisé avec votre propre bifurcation. Voici comment faire :

$ cd ~/nalc-server/nalc-server-mods
$ git submodule set-url riesenpilz https://sys4.fr/gitea/Sam/riesenpilz.git
Synchronisation de l'URL sous-module pour 'riesenpilz'

Cette commande a permit de modifier le fichier .gitmodules présent à la racine du dépôt nalc-server-mods. Pour voir comment il a été modifié vous pouvez faire la commande suivante :

$ git diff
diff --git a/.gitmodules b/.gitmodules
index 91c5a9e..3971c3d 100644
--- a/.gitmodules
+++ b/.gitmodules
@@ -354,7 +354,7 @@
        url = https://sys4.fr/gitea/nalc/random_messages.git
 [submodule "riesenpilz"]
        path = riesenpilz
-       url = https://sys4.fr/gitea/nalc/riesenpilz.git
+       url = https://sys4.fr/gitea/Sam/riesenpilz.git
 [submodule "signs_lib"]
        path = signs_lib
        url = https://sys4.fr/gitea/mtcontrib/signs_lib.git
lines 1-13/13 (END)

On voit bien le changement d'url pour le submodule riesenpilz.

Le fichier .gitmodules étant modifié il est temps de faire un premier commit pour refléter ce changement dans le dépôt git nalc-server-mods :

$ git status
Sur la branche dev
Votre branche est à jour avec 'origin/dev'.

Modifications qui ne seront pas validées :
  (utilisez "git add <fichier>..." pour mettre à jour ce qui sera validé)
  (utilisez "git restore <fichier>..." pour annuler les modifications dans le répertoire de travail)
	modifié :         .gitmodules

aucune modification n'a été ajoutée à la validation (utilisez "git add" ou "git commit -a")

$ git commit -a -m "[riesenpilz] Fork du dépôt"
[dev 6582c8f] [riesenpilz] Fork du dépôt
 1 file changed, 1 insertion(+), 1 deletion(-)

$ git log
commit 6582c8f90f2f2dafe083b5ef4b414aed0a3d73c5 (HEAD -> dev)
Author: Sam <samedi@monemail.fr>
Date:   Sat Oct 10 12:21:39 2020 +0200

    [riesenpilz] Fork du dépôt

commit 2e46254d4fe739d9f4d340d4ff916da1eeccb395 (grafted, origin/dev)
Author: sys4 <pouet@sys4.fr>
Date:   Mon Sep 28 20:58:00 2020 +0200

    Maj de plusieurs mods
    
    gauges, item_drop, maptools, nether
lines 1-13/13 (END)

Et enfin pousser le commit (push) pour synchroniser le serveur.

$ git push
Modifier le mod

Ça y est, votre environnement est presque prêt pour que vous puissiez commencer à modifier le code de votre mod bifurqué. Avant d'éditer son code, mettez vous sur sa branche principale ou créez-en une nouvelle car actuellement vous êtes certainement sur une branche détachée (HEAD détachée) du dépôt qui n'a aucun lien avec la branche distante. Dans cet exemple nous nous mettons sur la branche master :

$ cd ~/nalc-server/nalc-server-mods/riesenpilz
$ git status
HEAD détachée sur 2a8d3aa
rien à valider, la copie de travail est propre

$ git checkout master
Basculement sur la branche 'master'
Votre branche est à jour avec 'origin/master'.

Maintenant vous pouvez éditer le code avec votre éditeur favoris puis enregistrez vos modifications. Puis vous relancez le serveur pour tester vos modifications.

$ cd ~/nalc-server
$ ./shutdown.sh -r

Si tout va bien et que vous êtes satisfait de votre test, vous voudrez sûrement commiter vos changements :

$ cd ~/nalc-server/nalc-server-mods/riesenpilz
$ git status
Sur la branche master
Votre branche est à jour avec 'origin/master'.

Modifications qui ne seront pas validées :
  (utilisez "git add <fichier>..." pour mettre à jour ce qui sera validé)
  (utilisez "git restore <fichier>..." pour annuler les modifications dans le répertoire de travail)
	modifié :         init.lua

aucune modification n'a été ajoutée à la validation (utilisez "git add" ou "git commit -a")

$ git commit -a -m "Ma modif blablabla..."
[master 7a5df83] Ma modif blablabla...
 1 file changed, 1 insertion(+), 2 deletions(-)

$ git log
commit 7a5df839c98ff7e0d95961aae97bec040a04d144 (HEAD -> master)
Author: Sam <samedi@monemail.fr>
Date:   Sat Oct 10 15:44:25 2020 +0200

    Ma modif blablabla...

commit 2a8d3aafcff0d372fd1fee541261a0d707d6a914 (origin/master, origin/HEAD)
Author: sys4 <pouet@sys4.fr>
Date:   Wed Jul 22 13:07:00 2020 +0200

    Tidy code

commit 06525f43eb34e1d68b1952be5fa2ce1d2ae0eb15 (tag: nalc-1.2.0)
Author: sys4 <pouet@sys4.fr>
Date:   Fri May 8 20:25:49 2020 +0200

    Désactive les pommes en 3D
Poussez vos commits (Push)

Vous avez fait vos modifs, les avez testées et avez commité votre code. Mais cela n'a été fait qu'au niveau de vos dépôts locaux. Vous avez besoin de pousser (push) vos commits pour qu'ils soient publiés sur le serveur git :

$ git push
Username for 'https://sys4.fr': Sam
Password for 'https://samedi@monemail.fr': 
Énumération des objets: 5, fait.
Décompte des objets: 100% (5/5), fait.
Compression par delta en utilisant jusqu'à 12 fils d'exécution
Compression des objets: 100% (3/3), fait.
Écriture des objets: 100% (3/3), 302 octets | 302.00 Kio/s, fait.
Total 3 (delta 2), réutilisés 0 (delta 0), réutilisés du pack 0
remote: 
remote: Create a new pull request for 'Sam:master':
remote:   https://sys4.fr/gitea/nalc/riesenpilz/compare/master...Sam:master
remote: 
remote: . Processing 1 references
remote: Processed 1 references in total
To https://sys4.fr/gitea/Sam/riesenpilz.git
   2a8d3aa..7a5df83  master -> master

Comme nous avons fait la modification du sous-module riesenpilz et que celui-ci pointe vers une nouvelle référence, il faut également mettre à jour le dépôt git parent, soit le dépôt nalc-server-mods :

$ cd ~/nalc-server/nalc-server-mods
$ git status
Sur la branche dev
Votre branche est en avance sur 'origin/dev' de 1 commit.
  (utilisez "git push" pour publier vos commits locaux)

Modifications qui ne seront pas validées :
  (utilisez "git add <fichier>..." pour mettre à jour ce qui sera validé)
  (utilisez "git restore <fichier>..." pour annuler les modifications dans le répertoire de travail)
	modifié :         riesenpilz (nouveaux commits)

aucune modification n'a été ajoutée à la validation (utilisez "git add" ou "git commit -a")

$ git diff
diff --git a/riesenpilz b/riesenpilz
index 2a8d3aa..7a5df83 160000
--- a/riesenpilz
+++ b/riesenpilz
@@ -1 +1 @@
-Subproject commit 2a8d3aafcff0d372fd1fee541261a0d707d6a914
+Subproject commit 7a5df839c98ff7e0d95961aae97bec040a04d144
lines 1-7/7 (END)

$ git commit -a -m "[riesenpilz] Ma modif blablabla..."
[dev 6c82718] [riesenpilz] Ma modif blablabla..."
 1 file changed, 1 insertion(+), 1 deletion(-)

$ git push
Username for 'https://sys4.fr': Sam
Password for 'https://samedi@monemail.fr': 
Énumération des objets: 7, fait.
Décompte des objets: 100% (7/7), fait.
Compression par delta en utilisant jusqu'à 12 fils d'exécution
Compression des objets: 100% (5/5), fait.
Écriture des objets: 100% (5/5), 597 octets | 597.00 Kio/s, fait.
Total 5 (delta 3), réutilisés 0 (delta 0), réutilisés du pack 0
remote: 
remote: Create a new pull request for 'Sam:dev':
remote:   https://sys4.fr/gitea/nalc/nalc-server-mods/compare/master...Sam:dev
remote: 
remote: . Processing 1 references
remote: Processed 1 references in total
To https://sys4.fr/gitea/Sam/nalc-server-mods.git
   2e46254..6c82718  dev -> dev

Voilà vos modifications sont bel et bien publiées et de façon correcte sur le serveur git.

Proposer une demande d'ajout (Pull Request)

Maintenant vous vous dites que votre contribution vaudrait le coup d'être proposée au mainteneur du serveur NALC officiel pour qu'elle soit appréciée par le plus grand nombre.

Voici comment proposer vos modifications en créant une demande d'ajout au mainteneur du dépôt officiel pour qu'il puisse les fusionner s'il est d'accord.

Les demandes d'ajouts que vous proposerez ne doivent pas concerner le dépôt nalc-server-mods mais bien ses sous-modules, donc les mods eux-mêmes directement. Il serait trop compliqué d'expliquer exactement pourquoi ici mais c'est un sujet qui peut être discuté sur le salon irc #NALC-DEV du serveur par exemple.

Prenons l'exemple du mod riesenpilz que vous avez modifié précedement. Lors de son push vous aurez peut-être remarqué le message suivant :

remote: Create a new pull request for 'Sam:master':
remote:   https://sys4.fr/gitea/nalc/riesenpilz/compare/master...Sam:master

En fait, une demande d'ajout a été créé automatiquement pour fusionner vos modifications au dépôt d'origine de votre fork. Mais vous devez valider ce PR pour qu'il soit actif et que le mainteneur du dépôt d'origine soit prévenue. Pour cela, à l'aide de votre navigateur web, vous devez vous rendre à l'url indiqué soit : https://sys4.fr/gitea/nalc/riesenpilz/compare/master...Sam:master

Vous pouvez vous y rendre également en allant sur la page du dépôt d'origine (pas le vôtre, c'est important) puis aller à l'onglet demande d'ajouts.

Normalement la demande d'ajout devrait indiquer la fusion de la branche master de votre dépôt vers la branche master du dépôt d'origine.

Pour confirmer cette demande d'ajout, cliquer sur le bouton "Nouvelle demande d'ajout" puis remplissez le formulaire qui s'affiche pour rajouter une description à votre PR. Une discussion avec le mainteneur du dépôt cible pourra alors s'engager si il souhaite avoir des précisions ou faire des commentaires.

Ensuite libre à lui de fusionner votre PR ou non. En tout cas de votre côté vous avez finalisé votre demande d'ajout.

Rester à jour avec la version officielle

Si votre but est de proposer vos contributions pour la version officielle du serveur alors vous devrez merger les nouvelles mises à jour dans vos propres dépôts. Cette étape est importante car vous devez proposer vos modifications basées sur du code à jour.

La règle est qu'avant d'entâmer une modification dans un dépôt, assurez-vous avant, de le mettre à jour avec la version officielle.

Mettre à jour nalc-server

Rendez-vous avec votre terminal dans le dépôt de votre version de nalc-server :

$ cd ~/nalc-server

Ajoutez le dépôt distant officiel de nalc comme dépôt distant secondaire (à faire qu'une seule fois) puis synchronisez votre dépôt local :

$ git remote add nalc https://sys4.fr/gitea/nalc/nalc-server.git # À faire une seule fois
$ git fetch nalc # À faire à chaque fois que vous voulez vérifier la présence de mises à jours.
Récupération de nalc
remote: Décompte des objets: 8, fait.
remote: Compression des objets: 100% (8/8), fait.
remote: Total 8 (delta 5), reused 0 (delta 0)
Dépaquetage des objets: 100% (8/8), 982 octets | 491.00 Kio/s, fait.
Depuis https://sys4.fr/gitea/nalc/nalc-server
* [nouvelle branche] master     -> nalc/master

Pour voir si de nouveaux commits ont été posté sur le dépôt officiel :

$ git log --all
commit 8af9d443e1feb9a112088aa7f16ffcea4e8ed995 (nalc/master)
Author: sys4 <pouet@sys4.fr>
Date:   Sat Oct 10 21:58:04 2020 +0200

    [dev] Active le spawn des mobs en zones protégées

commit 7aabf3af4d8114ed093c6f76f687b1ba575bc752
Author: sys4 <pouet@sys4.fr>
Date:   Sat Oct 10 21:33:02 2020 +0200

    [dev] Maj des news

commit 919e88a1ade3533db9b68cdfe9f81decf4bc8e9b
Merge: 6270382 306fc03
Author: sys4 <sys4@noreply.sys4.fr>
Date:   Sat Oct 10 21:29:03 2020 +0200

    Merge pull request 'Ajoute guide de contribution et de développement du serveur NALC' (#3) from posco/nalc-server:master into master
    
    Reviewed-on: https://sys4.fr/gitea/nalc/nalc-server/pulls/3

commit 306fc03691de767fbf7f9246daffec87d9ee8d9f (HEAD -> master, origin/master, origin/HEAD)
Author: sys4 <samedi@monemail.fr>
Date:   Sat Oct 10 21:21:13 2020 +0200

    Ajoute guide de contribution et de développement du serveur NALC

lines 1-27

Nous pouvons voir que notre branche master actuelle (origin/master) est en retard par rapport à la branche master du dépôt officiel (nalc/master).

Nous allons fusionner ces nouveaux commits dans notre propre dépôt puis les pousser vers le serveur.

$ git merge nalc/master
Mise à jour 306fc03..8af9d44
Fast-forward
 minetest-dev.conf  | 2 +-
 world/news-dev.txt | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

$ git push origin master
Username for 'https://sys4.fr': Sam
Password for 'https://samedi@monemail.fr': 
Énumération des objets: 16, fait.
Décompte des objets: 100% (13/13), fait.
Compression par delta en utilisant jusqu'à 12 fils d'exécution
Compression des objets: 100% (8/8), fait.
Écriture des objets: 100% (8/8), 1002 octets | 1002.00 Kio/s, fait.
Total 8 (delta 5), réutilisés 0 (delta 0), réutilisés du pack 0
remote: 
remote: Create a new pull request for 'Sam:master':
remote:   https://sys4.fr/gitea/nalc/nalc-server/compare/master...Sam:master
remote: 
remote: . Processing 1 references
remote: Processed 1 references in total
To https://sys4.fr/gitea/Sam/nalc-server.git
   306fc03..8af9d44  master -> master

Si un éventuel conflit est détecté pendant la fusion, git vous en avertira en mentionnant quels fichiers sont en conflits. Une fois que vous aurez résolu le conflit, vous pourrez finaliser la fusion avec la commande :

$ git merge --continue

La fusion est terminée pour ce dépôt et le serveur est synchronisé. Faites la commande git log pour le vérifier.

Mettre à jour nalc-server-mods

Le début est à peu près la même chose. Voici la liste des commandes à faire. Cette fois je ne met pas le résultat des commandes pour simplifier la lecture.

$ cd nalc-server-mods
$ git remote add nalc https://sys4.fr/gitea/nalc/nalc-server-mods.git # Si première fois
$ git fetch nalc
$ git log --all

En revanche, les choses vont se compliquer à partir de maintenant. Quand vous allez fusionner la branche dev du dépôt officiel avec votre branche dev, les sous-modules de votre dépôt ne se mettrons pas à jour automatiquement et il faudra le faire manuellement.

$ git merge nalc/dev
Échec de fusion du sous-module riesenpilz (commits non présents)
Fusion automatique de riesenpilz
CONFLIT (sous-module) : Conflit de fusion dans riesenpilz
La fusion automatique a échoué ; réglez les conflits et validez le résultat.

$ git status
Sur la branche dev
Votre branche est à jour avec 'origin/dev'.

Vous avez des chemins non fusionnés.
  (réglez les conflits puis lancez "git commit")
  (utilisez "git merge --abort" pour annuler la fusion)

Modifications qui seront validées :
	modifié :         WorldEdit
	modifié :         homedecor_modpack
	modifié :         mesecons
	modifié :         mobs
	modifié :         moreblocks

Chemins non fusionnés :
  (utilisez "git add <fichier>..." pour marquer comme résolu)
	modifié des deux côtés :  riesenpilz

Modifications qui ne seront pas validées :
  (utilisez "git add <fichier>..." pour mettre à jour ce qui sera validé)
  (utilisez "git restore <fichier>..." pour annuler les modifications dans le répertoire de travail)
	modifié :         WorldEdit (nouveaux commits)
	modifié :         homedecor_modpack (nouveaux commits)
	modifié :         mesecons (nouveaux commits)
	modifié :         mobs (nouveaux commits)
	modifié :         moreblocks (nouveaux commits)

De plus, et c'est notre cas ici aussi, vous aurez très certainement des conflits avec les sous-modules que vous aurez bifurqués auparavant et qui ont bénéficié de nouveaux commits dans les dépôts officiels. Peu importe que ces nouveaux commits soient issus de vos PR ou non.

Mais Pourquoi ? Les sous-modules que vous avez modifiés, donc que vous avez bifurqués ne sont pas référencés à la même URL que les sous-modules officiels. L'historique de la branche dev de votre dépôt nalc-server-mods a dévié par rapport à la branche officielle qui elle ne connaît pas l'historique de votre dépôt puisqu'il n'a pas été fusionné. Du coup git considère que c'est un conflit et ne fera pas le merge automatiquement car il n'a pas moyen de savoir quoi faire. C'est à vous de décider. Dans notre cas que faire concrètement ? Pour nous sortir de ce mauvais pas nous allons pour chaque sous-module en conflit faire une fusion de la branche master du dépôt d'origine du sous-module puis nous ajouterons notre sous-module modifié à la fusion du dépôt nalc-server-mods.

$ cd riesenpilz
$ git remore add nalc https://sys4.fr/gitea/nalc/riesenpilz.git # Si première fois
$ git fetch nalc
$ git log --all
$ git merge nalc/master
# Réglez les éventuels conflits
$ git push origin master
$ cd ..
$ git add riesenpilz
$ git status
Sur la branche dev
Votre branche est à jour avec 'origin/dev'.

Tous les conflits sont réglés mais la fusion n'est pas terminée.
  (utilisez "git commit" pour terminer la fusion)

Modifications qui seront validées :
	modifié :         WorldEdit
	modifié :         homedecor_modpack
	modifié :         mesecons
	modifié :         mobs
	modifié :         moreblocks
	modifié :         riesenpilz

Modifications qui ne seront pas validées :
  (utilisez "git add <fichier>..." pour mettre à jour ce qui sera validé)
  (utilisez "git restore <fichier>..." pour annuler les modifications dans le répertoire de travail)
	modifié :         WorldEdit (nouveaux commits)
	modifié :         homedecor_modpack (nouveaux commits)
	modifié :         mesecons (nouveaux commits)
	modifié :         mobs (nouveaux commits)
	modifié :         moreblocks (nouveaux commits)

Le sous-module riesenpilz corrigé apparaît maintenant dans les modifications qui seront validés pour la fusion en attente que nous pouvons maintenant terminer.

$ git merge --continue
$ git status
Sur la branche dev
Votre branche est en avance sur 'origin/dev' de 2 commits.
  (utilisez "git push" pour publier vos commits locaux)

Modifications qui ne seront pas validées :
  (utilisez "git add <fichier>..." pour mettre à jour ce qui sera validé)
  (utilisez "git restore <fichier>..." pour annuler les modifications dans le répertoire de travail)
	modifié :         WorldEdit (nouveaux commits)
	modifié :         homedecor_modpack (nouveaux commits)
	modifié :         mesecons (nouveaux commits)
	modifié :         mobs (nouveaux commits)
	modifié :         moreblocks (nouveaux commits)

aucune modification n'a été ajoutée à la validation (utilisez "git add" ou "git commit -a")

Il ne nous reste plus qu'à mettre à jour les sous-modules bénéficiants de nouveaux commits puis on pousse notre branche dev sur le serveur :

$ git submodule update
Chemin de sous-module 'WorldEdit' : '418a30c89e426f769365dd2955fcde1c0f35adb7' extrait
Chemin de sous-module 'homedecor_modpack' : 'b6ecc0b95f322a391b87341d4321cb1c67da30c2' extrait
Chemin de sous-module 'mesecons' : 'd356f901a3c26f2cce28ce0be64d26fff996e110' extrait
Chemin de sous-module 'mobs' : '7f4d473feef7ab6df20d00e5ceaba8335efd463a' extrait
Chemin de sous-module 'moreblocks' : 'b93949c26629489f586df9bdda5a9eb9fc977d34' extrait

$ git status
Sur la branche dev
Votre branche est en avance sur 'origin/dev' de 2 commits.
  (utilisez "git push" pour publier vos commits locaux)

rien à valider, la copie de travail est propre

$ git push origin dev
$ git status
Sur la branche dev
Votre branche est à jour avec 'origin/dev'.

rien à valider, la copie de travail est propre