Avete provato i database di progetto… forse ne avete creato uno o forse avete convertito un’applicazione binaria esistente. Ora è il momento di mostrarvi come utilizzare Git (il sistema di controllo delle revisioni) e Github come servizio di hosting per la vostra applicazione 4D.
Database del progetto 4D
Prima di proseguire, per seguire questo post, è necessario disporre di 4D v17 R5 o più recente. Si presuppone inoltre che sappiate come creare un database di progetto o convertire un’applicazione esistente in un progetto. Tutto quello che c’è da sapere su questi due argomenti è spiegato nella documentazione e nel blog di 4D.
Git contro Github
È importante ricordare che esiste una differenza tra Git e Github:
Git
Vi siete mai chiesti come vengono realizzati i grandi progetti con team distribuiti? Per esempio, un progetto Linux con centinaia di migliaia di persone che ci lavorano contemporaneamente? La risposta breve è che si usa Git. Che è fondamentalmente un sistema di controllo delle versioni(alias VCS) che consente di gestire e tenere traccia della storia del codice sorgente.
Github
Github è un servizio di hosting basato su cloud, dove è possibile condividere il codice con altri e gestire i repository Git.
Installazione di Git
Se avete già Git sul vostro computer, potete passare alla sezione successiva. Altrimenti, scaricatelo da qui.
Strumenti Git
Se non vi sentite a vostro agio a lavorare con Git dall’interfaccia della riga di comando, sono disponibili diversi client GUI che velocizzeranno il vostro flusso di lavoro (soprattutto se siete nuovi alla piattaforma). Uno di questi strumenti è Github Desktop, sviluppato da Github per le piattaforme macOS e Windows. La scelta è vostra, potete usare uno strumento con interfaccia grafica o a riga di comando. In questo post utilizzeremo l’interfaccia a riga di comando per vedere cosa succede dietro le quinte.
Configurare Github
Successivamente, è necessario configurare Github. Innanzitutto, è necessario avere un account su Github. Seguite questo link per creare un profilo, scegliere un piano e specificare un’esperienza utente. Il processo è estremamente facile e intuitivo.
Terminologia importante
Prima di sporcarci le mani, ci sono alcuni termini ricorrenti che useremo quando lavoreremo con Git:
- Repository (repo): un repository Git è una directory che memorizza tutti i file, le cartelle e i contenuti necessari per il progetto.
- Remoto: Una copia del ramo originale. Quando si clona un ramo, il nuovo ramo è un ramo remoto, o clone.
- Locale: Il repository locale sul computer e contiene tutti i file e la loro cronologia di commit.
- Ramo: Una versione del repository che si discosta dal progetto di lavoro principale (ramo master). I rami possono essere una nuova versione di un repository, modifiche sperimentali o fork personali di un repository per consentire agli utenti di modificare e testare le modifiche.
- Commit: Una modifica individuale a un file o a un insieme di file.
- Push: Aggiorna i commit effettuati sul ramo locale a un ramo remoto. In pratica, si “spingono” le modifiche nel ramo remoto.
- Pull: aggiorna i commit effettuati in un ramo remoto sul ramo locale. Se qualcuno ha modificato il codice su un ramo separato di un progetto e vuole che sia rivisto per poterlo aggiungere al ramo master, può creare una richiesta di pull per chiedere ai manutentori del repository di rivedere i commit apportati e, se accettabili, unire le modifiche a monte. Un pull avviene quando si aggiungono le modifiche al ramo master.
- Staging: Si tratta di una cache dei file che si desidera impegnare.
Se siete interessati a saperne di più, consultate il glossario.
Impostazione del progetto
Ecco la vostra applicazione 4D in attesa di essere ospitata:
Aprite il terminale e navigate nella directory del vostro progetto 4D:
Successivamente, è necessario inizializzare un repository locale. Basta digitare il comando git init:
Poiché git init è stato eseguito in una cartella del progetto 4D, Git ha già adisposizioneun elenco di filenon tracciati . Il comando git status elenca tutti i file modificati (o nuovi) che possono essere aggiunti al repository locale:
Il risultato mostra che tre elementi non sono ancora stati inclusi nell’indice, il che significa che il commit delle modifiche con questi elementi non può essere fatto per ora. Il comando git add . ispezionerà l’intera directory di lavoro alla ricerca di eventuali file nuovi, cancellati o modificati e li aggiungerà all’indice.
L’esecuzione di git status mostra ancora una volta che i file sono pronti per il commit.
Ora è il momento di inviare i file nell’area di staging al repository locale. Questo può essere fatto con il comando git commit -m “message” . Imessaggi di commit dovrebbero essere chiari ed espliciti per scopi dibackup .
Nota: a volte, nella directory del progetto, ci sono alcuni file o directory che non vogliamo siano tracciati. Per questo motivo è necessario creare un file .gitignore in cui si indica a Git quali file, directory o modelli devono essere ignorati nel repository. Nel nostro caso, file come il journal, le preferenze, .4dd e la cartella DerivedData. In un prossimo post del blog, vi mostreremo come procedere.
Bene. Ora che i file della cartella di lavoro sono stati impegnati con successo nel repository locale , il passo successivo consiste nel trasferire le modifiche al repository remoto per condividerle con il resto del team. Ora andiamo sul nostro account GitHub e creiamo un repository:
Clicchiamo sul pulsante Clona o scarica e vedremo un link. Questo è l’URL del repository Github, assicuratevi di copiarlo.
Ora torniamo al nostro terminale e digitiamo: git remote add origin seguito dal link al repository Github precedentemente copiato. Fare clic su Invio.
È il momento di inviare la nostra applicazione a Github usando git push origin master. Se viene richiesto il nome utente e/o la password, inserire le credenziali GitHub utilizzate per creare l’account.
È possibile controllare rapidamente su Github che tutti i file siano stati inviati al repository remoto.
Congratulazioni, il vostro codice è ora nel cloud!
In questo blog post abbiamo imparato la differenza tra Git e Github, la terminologia Git più utilizzata, abbiamo creato il nostro primo repository e abbiamo aggiunto la nostra applicazione 4D su Github. In un prossimo post, esamineremo l’architettura di Git e vedremo alcuni esempi delle azioni più utilizzate per lavorare con Git e la vostra applicazione 4D.