Documentation pour utiliser le (futur) dépôt Git de SPIP, qu’on soit dev core, dev sur la zone, ou utilisateurice. (Pour l’instant c’est de l’aide que sur la ligne de commande mais il faudrait d’autres contributions)
- Documentation plus à jour : https://core.spip.net/projects/spip/wiki#SPIP-sous-Git-comment-%C3%A7a-marche-
- Voir aussi Proposer un patch via git.spip.net pour le noyau ou la dist (pull request)
- Voir aussi https://arkhi.org/misc/projects/spip-workflow-github
Accès HTTP :
- Log de modifications : https://core.spip.net/projects/spip/repository/revisions
- Browser de sources : https://core.spip.net/projects/spip/repository
Nota Bene : depuis les redactions initiales, core.spip.org/trac
est devenu git.spip.net
!
En tant que dev core
Préliminaire : cloner le dépôt chez soi :
La première fois qu’on veut récupérer le dépôt de SPIP, il faut le cloner sur sa machine. En ligne de commande, ça donne :
cd repertoire/de/travail/
git clone https://git.spip.net/spip/spip.git
Attention, ça prend un certain temps (de 5 minutes à ½ heure suivant la rapidité de votre machine et de votre connexion), mais c’est juste la première fois.
Astuces : configuration utile
git config --global user.name "Bob Dylan"
git config --global user.email "bob@dylan.com"
git config --global color.ui true
Pour committer dans la branche dev :
Dans git, il faut savoir que la branche de dev s’appelle traditionnellement master.
D’abord donc, s’assurer qu’on est dans la branche master (vérifier avec git branch
). Si c’est pas le cas :
git checkout master
Ensuite, committer. Deux manières possibles :
git commit -a
git commit <fichier1> <fichier2> ...
(-a
sert à tout committer)
Pour revenir sur un commit précédent (c’est la mort du oups, ça), rajouter --amend
.
Avec git, on est pas obligé de publier sur internet le fruit de son travail à chaque commit. On peut faire une série de commits en local, et publier avec git push
vers le dépôt origin (core.spip.org) quand on a un résultat cohérent, ou même à la fin de sa journée de travail si on se dit que ce n’est pas urgent. Les commits individuels, les heures, etc. seront préservés.
Attention : après avoir fait un git push
, on ne peut quasiment pas faire de git commit --amend
(alias oups © b_b). Autant ne pas se précipiter, donc.
Pour committer dans une branche de maintenance :
Tout d’abord, pour lister toutes les branches y compris celles du dépôt distant, c’est git branch -a
.
Ensuite, pour récupérer par exemple la branche 2.1 :
git checkout --track -b spip-2.1 remotes/origin/spip-2.1
Ceci va créer une branche locale nommée spip-2.1 à partir de la branche distante. Le nom de la branche locale est libre, mais on s’en fiche, spip-2.1 c’est bien. À partir de là, tous les git push
faits depuis cette branche locale se feront automatiquement vers la branche distante correspondante. Idem pour git pull
(équivalent de svn update
).
Pour passer d’une branche locale à une autre :
git checkout nom_de_la_branche
Scénario fréquent : reporter un certain commit d’une branche vers une autre
On vient de faire un commit dans la branche de dev, on veut le reporter sur une branche de maintenance, par exemple spip-2.1. Mettons que le commit s’appelle abcde. L’opération dans git s’appelle cherry-pick (picorer).
git checkout spip-2.1
git cherry-pick -x abcde
L’option -x a pour effet de mentionner automatiquement le commit d’origine.
En tant que dev sur la zone
Voir git to svn to git
Les plugins de la zone ne sont pas encore disponibles en git, mais ça va venir. Si quelqu’un veut aider...
En tant qu’utilisateur/rice
Pour cloner le dépôt en lecture seule :
cd repertoire/de/travail/
git clone http://git.spip.net/spip/spip.git
[1] exemple :
mkdir squelettes-dist && cd ./squelettes-dist
git clone http://git.spip.net/spip/dist/ && cd ..
Puis pour récupérer les plugins-dist, ce pourrait être qq.chose comme :
mkdir plugins-dist && cd ./plugins-dist
for %P in (plan , jquety.ui , svp ,breves , revisions , porte-plume ... ) DO (
mkdir %P && cd ./%P
git clone http://git.spip.net/spip/%P && cd ..
)
Voir aussi : https://git.spip.net/spip-contrib-outils/git_loader (shell Linux)
Pour récupérer une certaine release (tag) :
...
Pour récupérer l’état actuel d’une branche de maintenance :
...
Pour récupérer l’etat actuel de la branche principale (dev) :
...
Interfaces graphiques pour GIT
Voir la liste et le tableau comparatif des différentes solutions graphiques disponibles.
Sous Ubuntu
D’après le comparatif ci-dessus les trois solutions suivantes sont les plus fonctionnelles :
- http://trac.novowork.com/gitg/ : bof
- http://cola.tuxfamily.org/ : super complet mais peut être un peu trop compliqué à première vue
- http://live.gnome.org/giggle : simple mais semble plus lent à charger un repo que les deux précédents
Sous Mac OS X
Il en existe plusieurs, mais la plus complète et adoptée de tous (et gratuite) est SourceTree
Sous Windows
On signalera pour l’instant les deux principaux outils (mais il y en a d’autres..) :
- https://tortoisegit.org/ : analogue à TortoiseSVN (pour une migration facile)
- https://www.sourcetreeapp.com/ : une version Windows co-existe avec laversion Mac ci-dessus
Documentation complète sur Git
http://progit.org/book/fr/ puis https://git-scm.com/book/fr/v2
voir aussi : https://delicious-insights.com/fr/articles/apprendre-git/
Pour mettre à jour tous les plugins
SVN :
find ./plugins -type d -name ".svn" -exec svn up {}/.. \;
Git [2] :
find ./plugins -type d -name ".git" -exec git --git-dir={} --work-tree=$PWD/{}/.. pull \;
[1] Ne récupère pas les squelettes de base et les (25+ sous-dossiers de) plugins-dist !