Banche dati del progetto: Git. Impegno. Pull. Spingi e altro ancora

Marzo 10, 2020 5 min read

In un precedente post sul blog, vi abbiamo presentato Git (un sistema di controllo delle versioni) e Github (un servizio di hosting basato su cloud) e come potete condividere il vostro codice 4D con altri sviluppatori. In questo post ci spingeremo oltre, esplorando alcuni scenari che uno sviluppatore può incontrare, come la clonazione di un repository remoto, l’ignoranza dei file già impegnati e la risoluzione dei conflitti di fusione.

Prerequisiti

Prima di proseguire, partiamo dal presupposto che sappiate come creare un database di progetto o convertire un database binario in un progetto. È obbligatorio avere Git installato sul proprio computer e un account su Github. Se non li avete ancora, fate riferimento a questo post del blog per sapere come procedere.

Clonare un repository remoto

È ora di riprendere il lavoro sulla nostra applicazione. Ma per qualche motivo, non avete sul vostro computer il progetto su cui abbiamo lavorato l’ultima volta. Cosa fare?

Poiché abbiamo creato un repository su GitHub(post precedente), esso esiste come repository remoto. Ora dobbiamo creare una copia locale sul nostro computer e sincronizzare le due posizioni. Come procedere?

Collegatevi al vostro account Github,
Andare alla pagina principale del repository,
fare clic sul pulsante“Clona o scarica“, quindi sull’icona degli appunti (come mostrato nell’immagine seguente):
Aprire un terminale e indicare la posizione in cui si desidera clonare la directory.
Digitare git clone e incollare l’URL copiato al punto 3.

Congratulazioni! Avete creato una copia locale sul vostro computer.

gitignore

Non voglio che git tenga traccia di un particolare file o cartella

A volte, nel nostro progetto ci sono file o cartelle che non vogliamo siano tracciati. È qui che un file .gitignore si rivela utile. Come indica il nome, indica a Git quali file, directory o modelli ignorare nel repository.

Nel nostro caso, vogliamo che Git ignori la cartella Data (che contiene il journal, le preferenze, .4dd e la cartella DerivedData ).

Creare .gitignore

Configurare i file/cartelle ignorati

.gitignore utilizza modelli di globbing per confrontare i nomi dei file. È possibile costruire gli schemi utilizzando vari simboli. Ad esempio, per ignorare una cartella, si aggiunge una barra alla fine del nome della cartella. Si può fare riferimento a questo articolo per saperne di più sugli schemi .gitignore.

Ignorare i file che sono già stati inseriti nel repository

Si tenga presente che quando si crea un nuovo repository, si dovrebbe anche creare un file .gitignore per tutti i modelli di file che si desidera ignorare. Tuttavia, a volte capita che sfuggano dei file che poi si vogliono ignorare.

Niente panico! Con pochi e semplici passaggi è possibile ripulire il repository e fare in modo che questi elementi vengano ignorati:

Preparare i file per la rimozione, ma lasciarli in locale: git rm -r –cached
Ispezionare l’intera directory di lavoro alla ricerca di qualsiasi file nuovo, cancellato o modificato e aggiungerlo all’indice: git add
Inviare i file nell’area di staging al repository locale: git commit -m “Pulire i file ignorati”.
Inviare le modifiche al repository remoto: git push

Voilà! È possibile verificare nel repository remoto che i file non ci sono!

Nota importante: i file ignorati rimangono nella cronologia del repository. Per questo motivo, quando si creano nuovi repository, è necessario creare anche dei file .gitignore che indichino tutti i file, le cartelle o i modelli che si desidera ignorare. In caso contrario, se non si desidera che alcuni file vengano mantenuti nella cronologia, è necessario cancellare il repository da Github e inviarlo di nuovo.

Come risolvere i conflitti di fusione

Prima di tutto, RIMANETE CALMI!

Quando più sviluppatori lavorano nello stesso sistema di controllo di versione, la gestione di eventuali conflitti diventa un compito quotidiano. Ci sono diverse opzioni disponibili. Il conflitto può essere facilmente risolto con l’editor 4D, ma poiché tutti i file sono ora basati su testo, si può anche usare un editor di testo per risolvere manualmente i conflitti. Inoltre, sono disponibili molti strumenti di fusione che possono essere integrati in GIT. Nell’esempio qui sotto, stiamo usando l’editor 4D per risolvere i conflitti.

Diamo un’occhiata a un conflitto usando un metodo 4D. Per farlo, è necessario simulare un utente secondario / repository git locale, duplicando la cartella del database e assicurandosi che abbia almeno un metodo di progetto. Ora ci sono due cartelle di database: my4DApplication e my4DApplication2. Quindi, aprire entrambe le applicazioni.

1. Aprire il metodo di progetto nella prima applicazione e aggiungere del contenuto (un commento, per esempio).
2. Se si esegue git status, verranno rilevate le modifiche nel metodo. Eseguire il commit e il push delle nuove modifiche.
3. Scenario: qualcun altro modifica lo stesso metodo, nello stesso momento. Simuliamo questa situazione aprendo lo stesso metodo nella seconda applicazione e modificandolo con un commento diverso.
4. Eseguire il commit e il push delle nuove modifiche. Come si può vedere, il push viene rifiutato e al suo posto viene suggerito un pull:
5. L’esecuzione del pull git suggerito non è di aiuto:

E adesso?

Aprire il metodo con il conflitto. La riga con l’intestazione indica le modifiche locali e quella in rosso il numero del commit effettuato dall’altro utente.

Risolvere il conflitto è facile, basta selezionare le parti corrette del codice e fare il push delle modifiche. In questo caso, mantengo entrambi i messaggi di ALERT con commenti diversi:

Una volta fatto questo, l’altro utente può eseguire git pull per ottenere le nuove modifiche. Entrambi gli utenti hanno ora lo stesso contenuto nel metodo.

Per evitare conflitti in primo luogo

Non c’è un modo sicuro per evitare sempre i conflitti, ma l’esecuzione di git fetch può risparmiare un sacco di grattacapi di fusione. Controlla se il repository remoto ha dei nuovi commit. Non farlo prima di provare a fare il push ha causato l’errore [Rejected].

Per concludere

In questo post abbiamo discusso diversi scenari che uno sviluppatore può incontrare quando lavora con Git. In un prossimo post, ci allontaneremo dalla riga di comando e mostreremo come utilizzare un client GUI per lavorare con Git.