Git - submoduły i aliasy

Post oparty na prawdziwych wydarzeniach i traumach

Submoduły

Zrobili to! Mimo że protestowałem. Do projektu przy którym pracowałem dodali submoduły.

  • Jak mogli to zrobić - zadaje pytanie oburzony.
  • Prosto - pada odpowiedź - za pomocą polecenia o składni:
    git submodule add link-do-repozytorium opcjonalna-nazwa-folderu
    

    A w tym wypadku było to dokładnie:

    git submodule add https://github.com/paulp/sbt-extras.git sbtx
    

    wykonane w folderze projektu.

  • Ale po co? - drążę dalej temat.
  • Żeby współdzielić kod.
  • Przecież do tego służą biblioteki! - moje oburzenie sięga zenitu.
  • Ale nie zawsze jest to łatwe i możliwe:
    1. Biblioteki trzeba wydawać i trzymać je w menedżerze repozytoriów binarnych (ang. Binary Repository Manager), a takiego menedżera trzeba gdzieś zainstalować.
    2. Menedżer repozytorium binarnych może kosztować, np. dla Javy jest za darmo, a dla JavaScriptu już niekoniecznie.
    3. W językach skryptowych biblioteki są często instalowane do interpretera co może utrudniać instalację programu klientowi (przykład z pierwszej wersji Git-Tools-Submodules).
    4. Nie wszystko da się umieścić w bibliotece, w tym wypadku jest to skrypt do budowania projektu.

Dodatkowe komendy

Tak przekonany przestałem marudzić i przejrzałem Git-Tools-Submodules, git-submodule oraz git-clone. Okazało się, że praca z submodułami nie jest taka straszna i sprowadza się głównie do dwóch komend:

git clone --recurse-submodules
git submodule update --init --recursive

Pierwsza komenda ściąga repozytorium ze wszystkimi submodułami. Druga - aktualizuje submoduły po przełączeniu się na inny commit, gałąź lub po aktualizacji gałęzi.

Niestety komendy te wydłużają i tak długie już komendy gita.

Aliasy Basha

Szczęśliwie umiem rozwiązywać problem długich komend, bo znam aliasy basha.

Pierwsza wersja moich aliasów wyglądała następująco:

alias g='git'
alias gcl='git clone'
alias gclr='gcl --recurse-submodules'
alias gupdate='git submodule update --init --recursive'
alias gpr='git pull --rebase'
alias gpru='gpr && gupdate'
alias master='git checkout master && gupdate'
alias develop='git checkout develop && gupdate'

Aliasy Gita

Byłem bardzo zadowolony ze swoich aliasów, więc postanowiłem się nimi pochwalić koledze:

  • To bez sensu - odpowiedział zdziwiony - przecież git ma swój system aliasów.

Po przeczytaniu Git-Basics-Git-Aliases i git-config mój zbiór aliasów zamienił się w zestaw komend gita do wykonania:

git config --global alias.cl 'clone'
git config --global alias.clr 'cl --recurse-submodules'
git config --global alias.update 'submodule update --init --recursive'
git config --global alias.pr 'pull --rebase'
git config --global alias.pru '!git pr && git update'
git config --global alias.master '!git checkout master && git update'
git config --global alias.develop '!git checkout develop && git update'
git config --global alias.tig '!tig'

Widać tutaj, że podkomenda alias ma dwie składnie:

git config --global alias.nowa_komenda_gita 'stara_komenda_gita_z_parametrami'
git config --global alias.nowa_komenda_gita '!dowolna_komenda_basha'

I od teraz:

  • git cl - klonuje repozytorium;
  • git clr - klonuje repozytorium razem z submodułami;
  • git update - aktualizuje submoduły;
  • git pr - pobiera zmiany ze zdalnego repozytorium;
  • git pru - pobiera zmiany ze zdalnego repozytorium i aktualizuje submoduły;
  • git master - przełącza na gałąź master i aktualizuje submoduły;
  • git develop - przełącza na gałąź develop i aktualizuje submoduły;
  • git tig - uruchamia program tig (o ile mamy go zainstalowany).

Komendy te zapisałem w pliku git_config.sh i można je wykonać poleceniem:

curl -s https://raw.githubusercontent.com/writeonly/cli/master/git_config.sh | bash

Docker - usuwanie obrazów

Dziesięć lat pracy na Linuksie nauczyło mnie, że jeśli Linuks zaczyna magicznie i bez ostrzeżenia sam z siebie nie działać to najprawdopodobniej skończyło się miejsce na dysku. Identycznie jest z Dockerem. Jeśli lokalnie stawiamy chmurę mikroserwisów, które często pojawiają się w nowych wersjach, to prędzej czy później zabraknie nam miejsca na dysku. W skrajnym wypadku, na laptopie zastępczym, musiałem dwa razy w tygodniu usuwać obrazy Dockerowe.

Procedura usuwania obrazów Dockerowych

Szczęśliwie procedura usuwania obrazów Dockerowcyh nie jest czynnością skomplikowaną i składa się z trzech kroków. Na początek włączamy terminal i teraz kolejno wykonujemy kroki:

Krok 1. Zatrzymujemy wszystkie kontenery:

docker kill $(docker ps -q)

Krok 2. Usuwamy wszystkie kontenery:

docker rm $(docker ps -a -q)

Krok 3. Usuwamy wszystkie obrazy:

docker rmi $(docker images -q)

Wszystko razem

Można także wykonać wszystko razem jako jedną, połączoną komendę w terminalu:

docker kill $(docker ps -q) && docker rm $(docker ps -a -q) && docker rmi $(docker images -q)

Lepiej jest jednak dodać wpis do pliku ~/.bash_aliases :

alias docker_rmi_all='docker kill $(docker ps -q) && docker rm $(docker ps -a -q) && docker rmi $(docker images -q)'

I wtedy wystarczy z wywołać w terminalu:

docker_rmi_all
Follow