Version 2 — Janvier 2020 — JLuc
? Faut il s’inscrire pour accéder à un repo ?
...
? Faut il s’inscrire pour pouvoir commiter et comment fait-on ?
...
? Qu’est-ce qu’une organisation gitea ?
...
? Quelles sont les différentes « organisations » de spip et à quoi servent elles ?
...
? Comment trouver l’adresse git d’un plugin, d’un squelette, d’un thème, d’un fichier de spip-dist, ou d’un fichier de la galaxie ?
...
? Comment installer et utiliser localement un plugin en le récupérant par git (par par SVP)
...
? Comment importer sur git.spip.net un plugin développé sur github ou gitlab ?
Il y a 2 manières de faire : en cliquant un bouton (simple et automatique) ou en ligne de commande (personnalisable au besoin).
- Automatiquement : sur git.spip.net, chacun peut trouver, à coté de son avatar, une opération appelée « Nouvelle migration ». Elle permet en un seul formulaire de transférer un repo github ou autre vers son organisation personnelle sur la forge ou dans une des organisation spip-contrib.
- En ligne de commande : Chaque repo git, qu’il soit distant ou local, possède un historique, et qu’on peut synchroniser les historiques entre les repos
Pour importer un repo github ou gitlab sur git.spip.net,
git remote add <unnomdetonchoix> <lurldureposdistant>. <unnomdetonchoix> est le nom qui permet de référencer (depuis ton repos local) le repos distant nouvellement créé. Mais si en fait tu souhaites ne garder qu’un seul dépot distant comme dépot de référence, plutôt qu’ajouter la nouvelle url à l’url existante, tu peux aussi simplement la remplacer : git remote set-url origin <lurl du repos distant> .git push <unnomdetonchoix>Rq : Par convention, lorsqu’on clone une depot distant, il est référencé avec le nom origin comme dépot local. Mais tu peux en référencer plusieurs.
Une pratique courante est
- upstream pour désigner le repos communautaire officiel du projet
- origin pour designer le repos distant « personnel »
? Comment pousser sur le repo une modification apportée localement à un plugin ?
...
? Sur quelles organisations puis-je commiter directement ?
...
? Quand faut il créer une nouvelle branche ?
...
? Sur quelles organisations dois-je faire un PR pour proposer une modification ?
...
? Comment faire une PR ?
...
? Comment synchroniser localement mon plugin avec le repo ?
...
? Comment éviter les conflits de version ?
...
? Comment bien gérer un conflit de version ?
...
? Comment mettre à jour localement les repos git de tout un ensemble de plugins que j’utilise ou sur lesquels je travaille ?
...
? Tous les plugins de la zone SVN étaient dans un même et unique repo svn, alors qu’avec git, chaque plugin a son propre repo. Quels changements cela entraîne t il sur la manière de travailler ?
...
? Est-ce une bonne pratique de récupérer le code de tous les plugins de la zone ?
Idéalement, non. Il ne faut cloner localement que les plugins dont on a besoin ou qui nous intéressent. Mais en pratique, ça semble nécessaire, par exemple pour faire des recherches globalement sur tout le code.