Working Copy e iAWriter per gestire sito statico con Git da iPad

Filippo Strozzi

1. Il problema

In question giorni sto sperimentando per creare un flusso di lavoro (workflow) ottimizzato per scrivere e gestire un sito statico con Hugo.

In particolare mi interessa poter lavorare in modo semplice da iPad. L’iPad (Pro) è uno strumento duttile per scrivere.

2. Il mio attuale flusso di lavoro

Dopo vari tentativi, più o meno riusciti, ad oggi mi sono strutturato per utilizzare Working copy e iAWriter, nel proseguo spiegherò perché li ho scelti.

Dopo aver configurato Working Copy per clonare il repository di questo sito (composto da file scritti in markdown), aver approtato le mie modifiche con iAWriter, ho provato a inviare modifiche fatte da Working Copy al mio repository locale git del sito.

Mi ha dato un errore, come mostrato qui sotto.

Errore di Working Copy quando ho cercato di sincronizzare – in gergo tecnico push – il repository locale sul server del sito

3. La soluzione

Da una rapida ricerca ho trovato questa soluzione su StackOverflow.

Cerco di spiegare il problema come l’ho capito.

Dopo aver configurato con successo Working Copy per accedere al repository Git del sito (sul mio container Docker dove ho creato l’istanza di Hugo) volevo aggiornare il branch principale (ovvero il ramo del repository).

Questa attività tuttavia è sconsigliata (legittimamente) perché potrebbe essere creare problemi. Immagina se più persone lavorano sul ramo principale di un progetto modificandolo contemporaneamente.

Abitualmente, con sistemi di revisione dei file come Git, si dovrebbe lavorare su una branch o ramo collaterale alle modifiche da implementare e poi con un merge, ovvero una riunione dei rami, portare le modifiche al ramo principale.

Nel mio caso, pur essendo una buona prassi, un po’ per pigrizia, un po’ perché sono l’unico a fare le modifiche non ho mai implementato questa best practice.

Come dice l’articolo di cui sopra c’è una soluzione per i temerari ovvero la seguente:

git config receive.denyCurrentBranch updateInstead

Ho quindi implementato la soluzione nella mia istanza di Hugo.

Esecuzione del comando sopra indicato nel mio container docker

Riprovando a fare il push, ovvero invio dei dati al repository remoto, tutto è andato a buon fine.

Risultato di corretto push delle modifiche fatto da Working Copy

Da ultimo ti spiego perché ho deciso di utilizzare su iPad Working Copy e iAWriter.

La prima app è un ottimo client Git che sfrutta appieno tutte le API di Apple per iPadOS. Questo significa che il repository clonato su iPad (in locale) è accessibile come cartella all’interno di File. È quindi possibile senza troppi sforzi creare, copiare e spostare documenti nel repository per poi sincronizzarlo con quello remoto.

iAWriter, oltre ad essere un ottimo software per scrivere in markdown1, ha la possibilità di integrarsi con i document provider come Working Copy. Ciò fa si che possa modificare sul posto i file del repository dall’interno di iAWriter semplificandomi di molto la vita.

Da ultimo, anche se non è super comodo2, Working Copy mi permette di fare modifiche al volo agli articoli.

Come mostrato qui sotto.

Esempio di modifica di un file di testo con Working Copy

In un prossimo articolo spiegherò come ho configurato tutto.

  1. secondo solo a Vim. ↩︎

  2. Almeno dal mio punto di vista. ↩︎