Git/Conseils
Une liste de conseils et d'astuces pour Git
Gérer les anciennes branches
Si vous avez travaillé avec git durant un certain temps vous avez probablement de nombreuses branches anciennes qui ne vous servent plus. Celles dont vous n'avez définitivement plus besoin sont celles qui ont déjà été fusionnées sur le master. Vous pouvez les identifier avec :
$ git branch --merged
De même, après avoir soumis une modification à la relecture, vous pouvez faire que votre branche soit automatiquement supprimée après que Gerrit l'ait fusionnée :
$ git review -f
Vérifications pré-commit
Git vous permet de définir via des accroches, les contrôles qu'un commit doit passer (voir githooks(5) pour plus de détails).
Vous devez garder à l'esprit qu'il faut définir les accroches séparément pour chaque référentiel (par exemple, pour l'extension) et qu'ils ne sont pas copiés par git clone, donc vous devez créer une procédure adaptée à vos modèles de travail personnels pour les garder organisées.
Commencez par activer l'exemple de pré-commit installé par Git. Il interdit les noms de fichier non-ASCII et les espaces de fin.
Interdire les commits vers le master
Faire le commit dans master sur votre dépôt local n'est pas habituellement ce que vous souhaitez.
Pour désactiver, mettez cet extrait au début :
# Interdire les commit sur le master
if [ "$(git symbolic-ref HEAD)" = "refs/heads/master" ]; then
echo "Error: Attempt to commit to master."
echo
exit 1
fi
Vous pouvez aussi interdire les commit sur d'autres branches (REL1_20, etc.), mais protéger master est suffisant dans la plupart des cas.
Exécuter php -l sur des fichiers PHP
C'est probablement une bonne idée que de vérifier si les fichiers PHP que vous avez ajoutés ou modifiés passent un simple test php -l.
Pour l'activer, placez cet extrait avant la dernière ligne de exec git diff-index :
# Exécuter lints sur les fichiers ajoutés ou modifiés.
git diff --cached --name-only --diff-filter=ACM -z $against |
while read -d '' -r FILENAME; do
case "$FILENAME" in
*.php)
if [ "x$MW_GITPHPLINT" != "xfalse" ]; then
if ! git show :"$FILENAME" | php -l; then
echo " in '$FILENAME'"
exit 1
fi
fi
;;
esac
done
STATUS=$?
if [ $STATUS -ne 0 ]; then
exit $STATUS
fi
Exécuter des suites de tests
Comme le suggère la liste des contrôles pré-commit, vous devez exécuter les tests avant de soumettre une modification.
Dans un monde rationnel, cette tâche fastidieuse est laissée à un robot, dans le monde réel où, malgré de fréquents tests a/b sur les tidbits de l'interface utilisateur, cela n'est même pas sur le radar, et vous devez construire le robot vous-même.
Heureusement, Git offre tout ce qu'il faut sous la forme d'accroches de post-commit.
L'exemple suivant teste d'une certaine manière l'analyseur syntaxique et le serveur SQLite (voir the Dépôt des tâches Jenkins pour d'autres idées) :
#!/bin/sh
at now <<EOF
WWWDIR=~/public_html/w-sqlite &&
rm -Rf "\$WWWDIR" &&
git clone ~/public_html/w "\$WWWDIR" &&
cd "\$WWWDIR" &&
mkdir data &&
nice php ./maintenance/install.php --confpath . --dbtype=sqlite --dbpath=./data --showexceptions=true --pass testpass --server http://localhost/ sqlitetest WikiAdmin &&
nice php ./tests/parserTests.php &&
nice composer phpunit:entrypoint -- --group Parser --exclude-group Broken,ParserFuzz,Stub --
EOF
Il est évident qu'il est particulièrement nécessaire d'adapter cette accroche à votre espace de travail personnel et aussi de ne pas utiliser le même noyau que pour les extensions.
En gérant la suite de tests comme une tâche at cela vous permet de continuer à travailler pendant que les tests s'exécutent en arrière-plan et vous recevez un courriel avec les résultats une fois terminé.
Ces paramètres supposent que vous exécutez une suite de tests à la fois; si vous voulez en exécuter plus en parallèle, vous pouvez faire référence au SHA1 de HEAD dans WWWDIR ou même essayer git describe --tags mais rappelez-vous que chaque clone consommera plus de 200 Mo d'espace disque.
La liste des tests que vous devez exécuter dépend de votre domaine de travail.
Si vous travaillez sur les bits de l'analyseur syntaxique, exécuter ces tests pourrait suffire.
Si vous envisagez des modifications complexes sur le schéma de la base de données, vous pouvez tester de nouvelles installations et exécuter update.php à partir des installations plus anciennes.
Si vous travaillez sur les extensions, vous pouvez cloner master et les balises (pas les branches, car ces dernières sont des cibles en mouvement) 1.18.4 et 1.19.2 et voir si votre code est toujours compatible avec eux.
Si vous développez sur une boîte avec peu de ressources, mais que vous avez accès à des machines plus puissantes sur le réseau, vous pouvez créer des dépôts nus sur ces dernières et utiliser l'accroche post-update de la même manière sur eux (le commit est passé comme $1).
Ensuite vous avez juste à git push $POWERFULMACHINE pour démarrer la suite de test.
Voir le code source
Nous utilisons le greffon Gerrit Gitiles pour explorer le dépôt dans sa totalité :
Il existe aussi des alternatives :