Skip to main content

Gestire le GitHub Pages con Mercurial e TortoiseHG

Abbiamo già visto in un precedente articolo come sia possibile creare, pubblicare e gestire un repository su github.com senza bisogno di installare Git, avvalendosi unicamente di MercurialTortoiseHG. In questo articolo spiegheremo come sia possibile utilizzare lo stesso metodo per impostare branch aggiuntivi, come ad esempio il branch gh-pages mediante il quale GitHub consente di pubblicare le cosiddette project pages.

GitHub Pages: cosa sono e a cosa servono

Come spiega il sito, le GitHub pages non sono altro che pagine web ospitate sui server di GitHub. Si dividono in due tipologie:

  • User & Organization Pages: si tratta di pagine legate al nostro account GitHub. Per crearle è sufficiente creare un repository con un nome particolare legato al nostro account. La sintassi da seguire è la seguente:  <username>.github.io  , dove al posto di <username> andrà inserito il nome corrispondente al proprio account GitHub. Una volta creato sarà possibile aggiungere una o più pagine web (e relativi css, js, immagini etc.) che diventeranno immediatamente accessibili all’indirizzo:  http(s)://<username>.github.io .  Queste pagine sono solitamente utilizzate per creare un mini sito web relativo al proprio account GitHub: presentazione e informazioni sullo sviluppatore, portfolio, mission del team di sviluppo, etc.
  • Project Pages: si tratta di pagine legate a un progetto specifico pubblicato su GitHub. Possono essere create manualmente utilizzando gli appositi comandi Git oppure automaticamente utilizzando il software di generazione automatico messo a disposizione da GitHub. In entrambi i casi verrà aggiunto un branch apposito, denominato gh-pages, dove sarà possibile aggiungere una o più pagine web alle quali si potrà accedere mediante l’indirizzo: http(s)://<username>.github.io/<projectname> . Queste pagine sono solitamente utilizzate per creare un sito web relativo al proprio progetto: descrizione, istruzioni per l’uso, esempi, demo, documentazione, API, etc.

Poiché le User & Organization Pages utilizzano il branch master del repository a loro dedicato, per gestirle è sufficiente fare riferimento all’articolo pubblicato in precedenza, che illustra appunto come gestire un repository Git tramite Mercurial. Nel caso delle Project Pages la questione è resa leggermente più complicata dal fatto che dobbiamo creare un branch apposito: vediamo come.

Approfondisci

Utilizzare GitHub con Mercurial e TortoiseHG

Introduzione

Non esiste sviluppatore degno di questo nome che non conosca GitHub, il popolare servizio di hosting di progetti software basato su tecnologia Git. Nel remoto caso in cui non ne abbiate mai sentito parlare vi consigliamo di recuperare le apposite voci di wikipedia relative rispettivamente a GitHub e a Git e i relativi siti ufficiali github.comgit-scm.com.

In caso contrario, continuate a leggere: saprete infatti fin troppo bene che l’utilizzo del servizio GitHub è convenzionalmente vincolato all’adozione di Git, un sistema di controllo di versione (source-control manager o SCM) particolarmente innovativo che in questi ultimi anni ha avuto – anche grazie alla popolarità dello stesso GitHub – una grandissima affermazione, soppiantando gli antichi e gloriosi standard open-source come CVS e SVN grazie ad un’architettura più moderna e basata su un sistema di versioning distribuito piuttosto che centralizzato.

Grazie a queste caratteristiche innovative oggi Git è senza ombra di dubbio il SCM più utilizzato da tutta la comunità Linux – non per niente è stato ideato da un certo Linus Torvalds. Ha avuto però certamente minore fortuna in ambiente Windows, per via di due principali motivi:

  • una tardiva diffusione delle principali interfacce grafiche di gestione – msysgit e TortoiseGit su tutte – particolarmente care agli utenti Windows, per loro natura meno avvezzi all’uso della command-line.
  • la quasi-contemporanea diffusione di Mercurial (noto anche come HG), un SCM distribuito dalle caratteristiche innovative simili a quelle di Git e caratterizzato da un maggiore supporto a livello applicativo per il sistema operativo di casa Microsoft.

Ad influire notevolmente sulla diffusione di Mercurial in ambiente windows è stato, nel 2008, il lancio del sito bitbucket.org, interamente basato su Mercurial (fino al 2011, anno in cui è stato integrato anche Git) e avente caratteristiche in tutto e per tutto simili a quelle offerte da GitHub.

Non è mia intenzione addentrarmi ulteriormente sull’argomento, né dire la mia su quale sia effettivamente il SCM e/o il sito migliore: personalmente, da affezionato utilizzatore di entrambi, ritengo che siano due ottimi prodotti e che – al di là della diversa filosofia di approccio – garantiscano allo sviluppatore funzionalità grossomodo analoghe per la quasi totalità degli utilizzi comuni.

Per una analisi approfondita delle somiglianze e differenze tra Git e Mercurial consiglio di leggere questi due ottimi (seppur datati) articoli. Il primo ha un approccio più tecnico e schematico, il secondo adotta invece un registro più ironico e discorsivo: scegliete quello che più vi ispira, allo stesso modo con cui spesso si finisce per scegliere l’SCM da utilizzare.

Approfondisci

VMware 10 e Windows Update KB2995388: Not enough physical memory available

Gli utenti che utilizzano la versione 10 di VMware Player o Workstation sotto Windows e tengono aggiornato il proprio sistema incontreranno molto probabilmente un problema di questo tipo:

Error_msg

L’errore è dovuto a una incompatibilità tra la versione di VMWare in oggetto e l’aggiornamento KB2995388 rilasciato da Microsoft tra ottobre e novembre 2014. Il problema è stato subito segnalato dal team di sviluppo di VMware, che annuncia la prossima pubblicazione di un fix per risolvere il problema. Nel frattempo, l’unica soluzione percorribile è quella di disinstallare l’aggiornamento dal proprio sistema (Pannello di Controllo -> Programmi e Funzionalità -> Visualizza Aggiornamenti Installati):

Control_panel_2

Per ulteriori informazioni sull’errore “Not enough physical memory” si consiglia di fare riferimento all’articolo pubblicato sul blog di sviluppo di VMware.

 

Close