Poprawne praktyki przy programowaniu serwisu, git, npm, gulp, composer itp Opcje

[nyfko]

Witam. Od jakiegoś czasu piszę mniejsze i większe stronki główne hobbystycznie zarówno front-end (html/css/js) jak i back-end (php). Do tej pory działałem bardzo chałupniczo, tzn całe kodowanie odbywało się bezpośrednio na FTP na zwykłym hostingu www. Gdy potrzebne były jakieś bilblioteki np. bootstrap czy coś z PHP to po prostu to pobierałem, wgrywałem na serwer i dołączałem do projektu - tyle. Uczę się teraz lepszych praktyk bo wiem że to złe.

Tak więc przez ostatnie dni zmieniłem to:
1. Przeniosłem się z pracy na serwerze na lokalny (xampp).
2. Wprowadziłem narzędzie npm i od teraz nim instaluję pakiety potrzebne przy frontendzie (bootstrap, jquery itp) zamiast ręcznie. W katalogu projektu mam teraz folder node_modules i package.json z używanymi pakietami.
3. Do npm wprowadziłem gulp który od teraz łączy mi wszystkie pliki js i css w pojedyncze wraz z tymi z node_modules, minifikuje itp, na stronie mam załadowane tylko te wynikowe. Do projektu dołączył plik gulp.js.
4. Wprowadziłem composer który instaluje mi zewnętrzne bilblioteki PHP. Do projektu dołączył folder vendor i composer.json


Pytanie co dalej?

Moim kolejnym krokiem powinno być chyba GIT. Gdy o nim czytam to wszędzie mówi się o nim w kontekście pracy zespołowej. Ja jednak obecnie piszę dane rzeczy w pojedynkę, i nie jako publiczne projekty tylko własne stronki.
Chcę go jednak wykorzystać jako jedyne poprawne rozwiązanie na sposób pracy nad serwisem - nie wiem czy słusznie. Chodzi o to by nie edytować wszystkiego przez FTP, tylko by to szło jakoś przez GIT - pytanie jak?

Czy dobrze rozumiem że to powinno wyglądać tak:
1. Piszę sobie jakąś stronę w PHP i testuję jej działanie na lokalnym serwerze.
2. To co zrobiłem działa i chcę by znalazło się na serwerze WWW.
3. Robię więc commita do jakiegoś prywatnego repozytorium np. na github mojego kodu, ale z pominięciem plików wygenerowanych przez gulp, bez pakietów npm i composera.
4. Na serwerze www przez zainstalowane na nim wszystkie narzędzie najpierw pobieram całą obecną zawartość z gita, potem instaluje zależności pakietów npm i composera a na koniec odpalam gulpa by wykonał wszystkie operacje na plikach js i css. I strona działa.
5. Dodając w przyszłości jakąś nową funkcjonalność znowu wgrywam wszystko z komputera na githuba, z githuba na serwer i odpalam npm, composera by sprawdził czy nie doszły jakieś nowe pakiety wymagane i odpalam gulpa.


1. Czy tak to powinno wyglądać? Czy jeszcze jakiegoś podstawowego narzędzia brakuje?
2. Czy powinienem te wszystkie operacje z npm, composerem itp wykonać na serwerze, czy na gita wgrać jednak już komplet plików razem z tymi skompresowanymi przez gulp?
3. Co jeżeli ja mam zwykły hosting www? Da się to wszystko jakoś ogarnąć, czy git i inne narzędzia wtedy tracą sens? Czy do każdego serwisu wtedy potrzebuję vps by to mogło działać?



Ogólnie proszę o podzielenie się tym jak to wygląda u Was, jak ta praca (głównie w pojedynkę jeśli tak też zdarza Wam się pracować) jest zorganizowana by to miało ręce i nogi?

Pozdrawiam

[Pyton_000]

Generalnie to...
- Pakiety Composer instaluje się ju na serwerze na podstawie composer.lock (composer install). Robi się to dla tego że zależności potrafią swoje ważyć. Oczywiście można by było wpakować cały `vendor` do repozytorium ale nie widzę sensu.

- Kompilacje assetów wykonuje się już na etapie przygotowania Release lub Hotfix i do repozytorium lecą już skompilowane wersje JS i CSS a dodatkowo zminimalizowane itd. Nie wrzuca się katalogu `npm_modules` bo on zawiera w sobie 98257823745698237698346 plików. Nie ma sensu bo to w sumie tylko na etapie projektowania jest potrzebne.

- GIT - Wpierw konsola, potem GUI. Niestety ale ucząc się GUI nie zawsze wszystko da się zrobić. Ja np. z GUI używam tylko Merge w PHPStorm. Wcześniej Meld. Ale to jest jedyny przypadek gdzie to faktycznie ułatwia. Oczywiście jeśli jesteś sam lub nawet 2-3 osoby to GUI styknie w zupełności.

- Deployment. Jest zasada w świecie DevOps że jeśli podczas Deploymentu musisz wykonać więcej niż 1 krok - zautomatyzuj to. Może być to cokolwiek począwszy od prostego skryptu w Bash, Envoy po Ansible, aż do CD. Release przez FTP to chyba najgorszy możliwy przypadek (no chyba że jest shared hosting i nic innego nie zadziała to wtedy przykro mi, lepiej zmienić serwer (IMG:style_emoticons/default/wink.gif) )