Tous les scripts se trouvent dans le dossier ‘bin’ de l’environnement virtuel.

On y trouve:

• activate: appelé quand vous activez l’env
• postactivate: appelé après l’activation de l’env
• postdeactivate: appelé après la désactivation de l’env
• preactivate: appelé avant d’activer l’env
• predeactivate: appelé avant la désactivation de l’env

Ce sont des scripts bash vides, il suffit de les remplir avec ce qu’on veut qu’il arrive : lancer un service, logger dans un dossier, setter une variable…

Par exemple, j’ai un fichier de settings django qui n’est pas détecté automatiquement par ./manage.py, du coup je met ce code dans “~/.virtualenv/monenv/postactivate” :

echo 'Set DJANGO_SETTINGS_MODULE="settings.unsettingsparticulier"'
export DJANGO_SETTINGS_MODULE="settings.unsettingsparticulier"

Ça me set ma variable d’environnement et du coup ./manage.py trouve mon fichier de settings.

Mettez le code suivant du le fichier .git/hooks/post-merge de votre repo en local :

#!/bin/bash

# On met ici tous les fichiers (ou pattern de nom) qu'on veut surveiller
# changez les pour les adapter à votre projet
files=('settings.py' 'migrations');

# on récupère tous les noms de fichiers modifiés depuis le dernier merge
modified_files=`git diff "HEAD@{1}" --name-only`

# on boucle sur chaque nom de fichier surveillé
for watched_file in "${files[@]}"; do

    # on liste tous les fichiers modifiés qui correspondent à ce nom de
    # fichier surveillé
    modified_watched_files=(`echo "$modified_files" | grep $watched_file`)

    # si le nombre de fichiers correspondant est plus grand que 0
    if [ ${#modified_watched_files[@]} ]; then

        # pour chaque fichier qui correspond, on affiche un avertissement
        # en rouge
        for modified_watched_file in "${modified_watched_files[@]}"; do

            echo -e "\e[41m "$modified_watched_file" has changed \033[0m"

        done


    fi

done

Le hook post-merge est exécute après git pull (et seulement si il n’y a pas eu de conflit). Il va afficher une bonne grosse alerte en rouge pour chaque fichier surveillé qui a été modifié entre avant et après le pull.

Notez au passage la syntaxe intuitive de bash pour utiliser des tableaux. On dirait presque que le mec qui a codé bash était un pote du gars qui a codé git.