Nella prima parte di questo articolo avevamo chiarito alcune cose: l’obiettivo è quello di liberarsi da legami e legacci di formati e piattaforme, che spesso non funzionano molto bene, possono essere pericolose e soprattutto non è detto che ci siano anche domani. E poi abbiamo identificato una strategia: la via del markdown.
La via del markdown
Con il linguaggio di marcatura leggero creato da John Gruber è possibile aggiungere pochi elementi strutturali al testo semplice (grassetti, corsivi, link, titoli e titoletti) che sono creabili e poi leggibili anche senza bisogno di un editor specializzato. Il vantaggio è poter avere la struttura del testo, che poi potremo arricchire con lo stile che vogliamo esportandola ad esempio come html (pulito da tutte le formattazioni nascoste e spesso senza senso di Word, ad esempio) per inserirla in un blog, per trasformarla in pdf, rtf, docx, per archiviarla in un formato che, grazie a Unicode, resterà leggibile per moltissimo tempo.
Avendo stabilito questo come punto di partenza per la scrittura, ci siamo liberati non solo dei programmi con formati proprietari (MS Word) ma evitiamo anche i programmi che strutturano i dati all’interno di un loro database (Bear e Ulysses) ed evitiamo i sistemi di sincronizzazione proprietari che sono relativamente controllabili (GoogleDrive, OneDrive, iCloud Drive, Dropbox, Box e tutti gli altri). Non perché siano di per sé sbagliati, ma perché sono come dei silos che strutturano i dati (cioè i nostri documenti) in un certo modo e ci vincolano a quel fornitore di servizio e a quella piattaforma. Andiamo incontro alla libertà, invece.
La via di Git
Abbiamo detto che scegliamo Git. La struttura del lavoro è semplice: dobbiamo creare un repository che sia il contenitore dei nostri documenti di testo semplice con i nostri appunti, le nostre note, i nostri articoli, il nostro diario e tutto il resto che finisce con txt, organizzato liberamente in cartelle e sottocartelle secondo il criterio che per noi funziona meglio. Lo creeremo su Mac, lo sincronizzeremo con GitHub, il servizio gratuito diventato da alcuni mesi di proprietà di Microsoft, in un repository online gratuito, e da qui a cascata potremo sincronizzare gli altri nostri computer “clonando” il repository remoto e poi aggiornandoli man mano tutti quanti.
Per occuparci di Git su Mac occorre installarlo. La soluzione “semplice” è usare GitHub Desktop, client a interfaccia grafica gratuito realizzato da quelli di GitHub e che funziona molto bene. Scegliamo invece la via del purista, e per farlo utilizziamo la riga di comando e Homebrew (il gestore di pacchetti che mancava al Mac), ma ricordiamo ancora una volta che è possibile procedere anche con un altro modo, cioè utilizzando client grafici di terze parti che si appoggiano sopra l’installazione fatta sul Terminale oppure procedono direttamente loro all’installazione di Git. Non vogliamo sposare quest’ultimo approccio perché ci renderebbe di nuovo dipendenti da un singolo software. Invece, installiamo Git dalla riga di comando tramite Homebrew. È sufficiente il comando:
brew install git
E il gioco è fatto. Una volta installato Git dobbiamo puntare la directory di lavoro del Terminale sulla cartella dove abbiamo deciso che risiederà il nostro archivio di materiali (da ora in poi o chiamiamo “repository”) nel filesystem del Mac. Lo avremo già popolato dei nostri file di testo pre-esistenti e magari avremo organizzato la gerarchia delle cartelle a seconda di quello che ci serve. Non è fondamentale aver già fatto tutto, si può anche partire con un repository completamente vuoto (basta che ci sia la cartella-contenitore in cui viene creato), ma chi scrive aveva già un bel pregresso di materiale organizzato ed è partito con quello.
Come funziona Git e il nostro repository
Qui brevemente i comandi che dobbiamo dare per creare effettivamente il repository, molti dei quali non serviranno più, e poi procediamo a spiegare come funziona a regime tutto quanto il meccanismo.
Cominciamo a creare il repository. Chi scrive ha messo tutti i suoi materiali (cartelle e file di testo) dentro una cartella chiamata immodestamente “Memex”, e poi ha portato il focus del Terminale su ~/Memex (la cartella è nella root della home dell’utente) e digitato il comando (seguito da invio):
git init
Dopodiché bisogna aggiungere i file presenti nella directory (questa operazione si ripeterà ogni volta che bisogna aggiornare) e fare commit. Dopo ogni riga premere invio. Nella prima riga attenzione al punto, preceduto da uno spazio.
git add . git commit -m “Il mio primo commit!”
A questo punto, prima di fare “git push”, è necessario spostarsi su GitHub e creare il nuovo repository dove si andrà a sincronizzare
Configurare GitHub
Dopo aver creato un nostro account gratuito su GitHub, creiamo un repository (il nome non deve necessariamente essere lo stesso di quello che sincronizzeremo) e lasciamolo vuoto, anche senza file readme.
Per fare la sincronizzazione ci sono due modi, uno meno e uno più sicuro. Potremmo usare username e password creata con il nostro account utilizzando una connessione di tipo https, oppure possiamo generare sul Mac una chiave crittografica per fare la connessione SSH. Seguiamo la seconda strada.
Sul Mac occorre generare una coppia di chiave, pubblica e privata, usando l’algoritmo Rsa. Il comando è semplice:
ssh-keygen -t rsa -b 4096 -C "[email protected]"
Il comando ssh-keygen crea la chiave basata sul nostro indirizzo di email ([email protected], dovete sostituirla con la vostra) e ha tre argomenti. Il primo, -t, permette di selezionare il tipo di algoritmo (in questo caso, rsa); il secondo, -b, permette di selezionare la dimensione della chiave (4096 è un’ottima scelta); infine, -C (attenzione alla maiuscola) permette di aggiungere un commento alla fine del file della chiave che non modifica la chiave stessa ma serve per associarla a github, ad esempio).
La risposta del terminale sarà:
Generating public/private rsa key pair. Enter file in which to save the key ($HOME/.ssh/id_rsa):
Premendo invio viene salvata nella directory di default ($HOME è il modo per indicare la directory home dell’utente attivo, anche non conoscendone il nome).
A questo punto il programma ci chiede anche una password per proteggere la chiave: sceglietene una buona.
Enter passphrase (empty for no passphrase):
All’interno della directory invisibile .ssh ci sono i due file con la chiave rispettivamente privata e pubblica, id_rsa e id_rsa.pub. Per aggiungerla su GitHub e farci riconoscere, basta andare nel menù in alto a destra del sito (una volta loggati) selezionare la voce “Impostazioni”. Al suo interno selezionare “SSH and GPG keys” e da qui selezionare nuova chiave SSH.
C’è a questo punto una schermata con un campo “Title” e un campo “Key” da compilare: il titolo serve per ricordare di quale chiave stiamo parlando. Invece nel campo “key” bisogna incollare il contenuto della chiave. Torniamo un attimo al terminale e digitiamo il comando:
cat /percorso/chiave/id_rsa.pub
L’output è una serie di caratteri che si possono copiare con il mouse e incollare nel browser.
Funziona. A questo punto, per evitare di mettere la password ogni volta che usiamo la chiave SSH, dobbiamo aggiungerla all’SSH Agent. Basta un comando:
ssh-add percorso/chiave/id_rsa
Adesso siamo pronti per sincronizzare il nostro repository locale con GitHub!
Sincronizziamo il master locale con quello remoto
Per procedere alla sincronizzazione dobbiamo semplicemente procedere così.
Assicuriamoci che il terminale punti alla directory dove c’è il repository. Abbiamo già aggiunto tutti i file del repository (“git add .”) e fatto “commit”. Prima di poter fare push (o pull per sincronizzare il contenuto remoto) dobbiamo creare il collegamento. Copiamo dalla pagina web di GitHub l’indirizzo SSH del nostro repository remoto che ora è vuoto.
A questo punto copiamolo al posto dell’indirizzo in questo comando:
git remote add origin
Il comando di git “remote add origin” indica che deve essere aggiunta una origine del progetto anche a un repository remoto. In pratica, siccome tutte le copie dei repository sono uguali e di pari dignità (non c’è un “centro” assoluto), gli stiamo dicendo di aggiungere il repository locale a quello remoto vuoto.
Prepariamo il remoto:
git remote -v
Infine, spostiamo il materiale del repository locale su quello remoto:
git push origin master
Fatto. Adesso abbiamo due repository identici. Se facciamo cambiamenti in uno dei due, basta seguire la sequenza di comandi viste prima: “add-commit-push” per aggiungere il lavoro fatto dall’area di staging locale a quella del repository locale e poi spostarle su quello remoto. Se invece si fanno cambiamenti in quello remoto e si “committano” e “pushano”, bisogna scaricarli in locale, quindi fare “pull” e “merge” (ma solitamente “pull” fa anche questa seconda azione). Oppure risolvere i potenziali conflitti.
Nel prossimo articolo
Nella prossima puntata vedremo come si lavora su iPad con Working Copy e poi vedremo la strategia di lavoro con iA Writer. Entrambe le app sono di livello professionale, e non costano poco. Ma, a parere di chi scrive, valgono la spesa.
iA Writer per Mac si acquista da questo link (qui la versione di prova) e per iOS/iPad a questo. Sono disponibili le versioni per Windows e Android. Invece, Working Copy per iOS/iPadOS si scarica gratuitamente da qui (ma per funzionare in modo completo richiede un acquisto in-app). Qui si può scaricare Homebrew, il gestore a pacchetti che mancava per macOS, mentre da qui si può creare il proprio profilo GitHub (ma la stessa cosa si può fare con GitLab o BitBucket). Un buon client git con interfaccia grafica per Mac, Windows e Linux è GitHub Desktop della stessa azienda e completamente gratuito.
La prima puntata di questo tutorial la trovate su questa pagina di Macitynet.
