Organizzazione progetto con Git

[ali-benny]

Premessa: il main è il branch principale collegata al sito https://site212204.tw.cs.unibo.it
Per ogni "aggiornamento" o nuova implementazione da inserire nel sito creiamo un branch.
In locale lavori sul nuovo branch: committa appena hai una versione funzionante di ciò che stai sviluppando, in modo da poter tornare indietro in caso di bug o problemi.
Quando hai finito di implementare una nuova funzionalità, fai un merge del branch al main.
Appena hai finito di pushare al main, controlla che sia tutto funzionante e nel caso cerca di fixare alcune sovrapposizioni.

Come funziona col server?

Ti chiederai: la macchina unibo su cui ho il sito come la aggiorno?
Tu lavorerai in locale (con un clone del branch su cui stai lavorando), dunque non visualizzerai il sito dal link ufficiale ma aprendo i file nel browser.

Quando avviene un push al server, creiamo una git hooks che "auto aggiorna" i file sulla macchina: in pratica fa pull quando vede un push sul branch del main.
Questo ci permette di avere il sito "ufficiale" (quello dal link) sempre al top e con le nuove funzionalità fixate.

Io credo che questa sia un buon workflow di sviluppo e credo che in questo modo non ci pesteremo i piedi a vicenda. Ovviamente quando ci serve aiuto dagli altri ci sentiamo e vediamo come fare... Magari un Live Share condiviso da chi è il "proprietario" del branch su cui ci sono dubbi.
In questo modo evitiamo di usare SFTP e dunque niente più duplicati di file, file in cartelle sbagliate e gran casino. In teoria ecco... 🤣

Come creare un git hooks?

è un file bash (ik, roba brutta proprio) che runna robe nel terminale.

1. crea un file nella directory degli hooks: nano .git/hooks/post-commit
2. . . . vedi reference

Reference

• workflow: https://www.bitmat.it/blog/news/git-plesk-rocketweb-hosting-un-metodo-vincente-sviluppo-siti-web/
• git hooks: https://medium.com/@f3igao/get-started-with-git-hooks-5a489725c639

[Iaco1]

Git hooks:
Si, ma non subito. E forse mai. Vediamo quanto è noioso non averli prima di aggiungerli.
Comunque se ci servissero sappiamo che esistono.

Proposta di Workflow dettagliata:
Un workflow classico:
premessa: Ognuno lavora solo certi file e riduciamo al minimo i file su cui possono lavorare più di una persona.

1. implementiamo la feature sul nostro branch
2. test
3. commit
4. merge settimanale del nostro branch con master (ognuno in giorni diversi prestabiliti)

con dei caveat per aumentare la prevedibilità di ciò che ci aspettiamo ci sia sulle macchine unibo:

• se non state lavorando in quel momento: sulle macchine unibo deve sempre essere checked out il branch master.
• Se state lavorando in quel momento: potete fare checkout sul vostro branch sulla macchina unibo.
• I commit li facciamo solo da locale, dalle macchine unibo facciamo solo pull.
  • Quindi se in qualsiasi modo modifichiamo la working directory della macchina unibo la dobbiamo riportare allo stato in cui era prima di modificarla.

Per controllare se abbiamo modificato la directory: git status
Per scartare tutti i cambiamenti git restore .

Quindi per quanto riguarda come lavorare in locale, libertà assoluta, quello che volete voi è la scelta giusta.