Git - zarządzanie aliasami

Poznając Gita prędzej, czy później zaczynamy tworzyć własne aliasy. Z racji tego, że Git jest rozproszonym systemem kontroli wersji, to każdy może mieć lokalnie dowolny zestaw aliasów. W momencie kiedy spójność aliasów zaczyna mieć krytyczne znaczenie dla procesu continuous delivery w danej firmie, pojawia się problem jak tymi aliasami zarządzać, tak aby „zmusić” programistów do używania tych najbardziej aktualnych. Jednak zanim o tym, to może przykład jakiś aliasów, które muszą być takie same u każdego z programistów.
Używając Gita, bardzo często korzystamy (a jeśli nie, to nie wykorzystujemy w pełni jego potencjału) z modelu branchowania podobnego do tego. W modelu tym zależy nam, żeby jakoś wyróżnić gałęzie releasowe od rozwojowych. Ustalamy, że gałąź releasowa jest odbijana zawsze od mastera i jej nazwa ma następujący format:

release/<numer_wersji>_yyyyMMdd 

natomiast gałąź rozwojowa może być odbijana od dowolnej innej gałęzi i jej nazwa musi pasować do:

develop/<opis>_yyyyMMdd

Tworzymy odpowiednie aliasy, żeby nie tworzyć tych gałęzi ręcznie (i pamiętać o ustalonych zasadach):

new-release = !sh -c 'DATE=$(date +%Y%m%d) && VERSION=$0 && RELEASE_BRANCH_NAME=\"release/\"$VERSION\"_\"$DATE && git checkout master && git pull && git checkout -b $RELEASE_BRANCH_NAME && git push-upstream' 

new-develop = !sh -c 'DATE=$(date +%Y%m%d) && BRANCH_NAME=\"develop/\"$0\"_\"$DATE && git checkout -b $BRANCH_NAME && git push-upstream'

I samo wywołanie:

$ git new-relase 1.0.1
$ git new-develop refaktor_super_klasy_x

Wracając do głównego problemu, to jak te aliasy rozpropagować? Albo jak rozpropagować ewentualnie ich modyfikacje? Instrukcja na wiki jest dobra tylko przy pierwszej instalacji Gita, potem nikt tam nie zagląda. Maile czyta 80%, a stosuje 50% osób. Na szczęście jest pewien sposób:

1. Tworzymy repozytorium Gita (git-config-common) gdzie trzymamy aliasy i wspólną konfigurację Gita (plik common-configuration). 
2. Klonujemy to repo na naszą maszynę. 
3. Konfigurujemy Git’a żeby korzystał z dodatkowego pliku z ustawieniami: 

   git config --global include.path "~/git-config-common/common-configuration"
   

4. W pliku common-configuration dodajemy alias do aktualizacji aliasów (:)):

   update-config-common = !sh -c 'OLDPWD=. cd ~/git-config-common && git pull && cd $OLDPWD' 
   

I teraz wystarczy z konsoli wywołać alias żeby wygodnie pobrać najnowszy zestaw aliasów i konfiguracji Gita. Pozostaje tylko kwestia zmuszenia do zaktualizowania istniejących stanowisk. Tutaj z pomocą przychodzą Git hooks, dzięki którym możemy walidować nazwy nowo utworzonych gałęzi, prosty skrypt z walidacją (origin_repo_folder/hooks/pre_recevive):

#!/bin/sh

release="release"
develop="develop"
release_regexp="^(release/[0-9_]+_[0-9]{8})$"
develop_regexp="^(develop/[a-zA-Z0-9_]+_[0-9]{8})$"

wrong_branch_name_message(){
  echo ""
  echo "!!! Nazwa galezi nie jest poprawna !!!"
  echo "1. Upewnij sie czy przestrzegasz konwencji nazewniczych."
  echo "2. Sprawdz czy masz aktualne aliasy"
  echo ""
}

while  read old new ref; do
#       echo $old"-"$new"-"$ref
  if [[ $old == "0000000000000000000000000000000000000000" ]] ;
  then
    if [[ ("$ref" == *"$release"*) ]] ;
    then
      branch_name=${ref#*refs/heads/}
      echo "Wykryto nowa galaz release, sprawdzam czy nazwa \"$branch_name\" jest poprawna..."
      if [[ "$branch_name" =~ "$release_regexp" ]] ;
      then
        echo "Nazwa galezi jest poprawna"
      else
        wrong_branch_name_message
        exit 1
      fi
    fi;
    if [[ ("$ref" == *"$develop"*) ]] ;
    then
      branch_name=${ref#*refs/heads/}
      echo "Wykryto nowa galaz develop, sprawdzam czy nazwa \"$branch_name\" jest poprawna..."
      if [[ "$branch_name" =~ "$develop_regexp" ]] ;
      then
        echo "Nazwa galezi jest poprawna"
      else
        wrong_branch_name_message
        exit 1
      fi
    fi;
  fi;
done