Version 13 — Décembre 2017 — raptor
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)
Accès HTTP :
- Log de modifications : http://core.spip.org/trac/spip/timeline
- Browser de sources : http://core.spip.org/trac/spip/browser
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 :
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
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 :
Ensuite, committer. Deux manières possibles :
(-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 :
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 :
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).
L’option -x a pour effet de mentionner automatiquement le commit d’origine.
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...
Pour cloner le dépôt en lecture seule :
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) :
...
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 :
Sous Mac OS X
Il en existe plusieurs, mais la plus complète et adoptée de tous (et gratuite) est SourceTree