12 straordinarie funzionalità di GitHub

Per quanto mi riguarda, non riesco a pensare a nessuna introduzione, quindi...

#1 Modifica del codice su GitHub.com

Inizierò con quello che penso che tutti già sappiano (anche se personalmente non ne avevo idea una settimana fa). Quando visualizzi un qualsiasi file di testo su GitHub, in qualsiasi repository, puoi vedere una piccola matita in alto a destra. Se fai clic su di esso, puoi modificare questo file. Una volta completato, fai clic su Proponi modifica file e GitHub creerà un fork e una richiesta pull. Incredibile, non è vero? Crea lui stesso la forchetta! Non è necessario eseguire il fork e caricare il codice su te stesso, apportare modifiche localmente e inviarlo nuovamente a GitHub con una richiesta pull. Molto comodo se è necessario apportare modifiche minime. non proprio una vera richiesta di pull

#2 Inserimento di immagini

Le descrizioni dei problemi non si limitano ai soli commenti di testo. Sapevi che puoi incollare le immagini direttamente dagli appunti? Una volta incollato, lo vedrai caricato (sul cloud, senza dubbio) e trasformato in markup per visualizzare l'immagine. Grazioso!

#3 Formattazione del codice

Se devi scrivere un blocco di codice, inizia con tre backtick e GitHub proverà a indovinare in quale linguaggio di programmazione stai scrivendo. Ma se stai pubblicando una porzione di codice in un linguaggio di programmazione come Vue, Typescript o JSX, puoi specificare esplicitamente la lingua in modo che l'evidenziazione della sintassi sia corretta. Notare ```jsx sulla prima riga: ...garantendo la corretta visualizzazione dello snippet di codice: (Questo vale anche per Gist, tra l'altro. Se specifichi l'estensione .jsf per un gist, la sintassi JSF verrà evidenziata). Di seguito è riportato un elenco di tutte le sintassi supportate .

#4 Chiudere i problemi utilizzando le “parole magiche” nelle Pull Request

Supponiamo che tu crei una richiesta pull che risolve il problema n. 234. Puoi inserire il testo "corregge il problema n. 234" nella descrizione della richiesta (o in qualsiasi punto di qualsiasi commento sulla richiesta di modifica). Successivamente, l’unione della Pull Request chiuderà “automaticamente” il problema. Fantastico, non è vero? Ulteriori informazioni a riguardo sono disponibili nella documentazione .

#5 Collegamento ai commenti

Ti è mai capitato di dover creare un collegamento a un commento specifico e di non sapere come fare? Quei giorni sono ormai lontani perché ti svelerò un segreto: per creare un collegamento a un commento, fai semplicemente clic sulla data/ora accanto al titolo. Guarda, Gaearon ora ha una foto!

#6 Collegamento al codice

Quindi vuoi creare un collegamento a una riga di codice specifica. In questo caso, prova questo: fai clic sul numero di riga accanto al codice desiderato nel file aperto. Wow, vedi? L'URL è cambiato, il numero di riga ora è visibile al suo interno! Se tieni premuto il tasto MAIUSC e fai clic su un altro numero di riga, allora voilà! – L'URL cambierà nuovamente e l'intervallo di righe verrà evidenziato. Questo URL ora punterà a questo file e a questo intervallo di righe. Ma aspetta, punta al thread corrente. Cosa succede se il file cambia? Probabilmente avrai bisogno, in questo caso, di un collegamento permanente al file nel suo stato attuale. Sono molto pigro, quindi ho preso uno screenshot di tutto quanto sopra: A proposito, riguardo agli URL...

#7 Utilizzo dell'URL di GitHub come riga di comando

La navigazione in GitHub utilizzando l'interfaccia utente è organizzata in modo molto conveniente. Ma a volte, per raggiungere una posizione specifica, è più veloce semplicemente digitarla nell'URL. Ad esempio, se voglio andare su un ramo su cui sto lavorando e vedere come si confronta con master, posso semplicemente digitare /compare/branchname dopo il nome del repository. Questo mi porterà alla pagina delle differenze per quel ramo: Ma queste sono differenze rispetto al ramo master, ma se prima ho lavorato con il ramo di integrazione, posso inserire /compare/integration-branch...my-branch nell'URL Per gli amanti dei tasti di scelta rapida: CTRL+L o CMD+L sposta il cursore sulla barra degli URL (almeno nei browser Chrome e Firefox). Questo, combinato con il completamento automatico del browser, rende molto più semplice la navigazione tra i rami. Suggerimento da professionista: utilizza le frecce per navigare tra i suggerimenti di completamento automatico di Chrome e premi MAIUSC+CANC per rimuovere elementi dalla cronologia (ad esempio, dopo aver unito un ramo). (Non so se sarebbe più facile leggere questi tasti di scelta rapida se ci mettessi uno spazio, come MAIUSC + CANC. Ma tecnicamente "+" non ne fa parte, quindi non mi piace questa opzione. È a causa di cose del genere non dormo la notte, Rhonda.)

# 8 Crea elenchi per problemi

Vuoi una casella di controllo nella descrizione del problema? E vuoi che venga visualizzata una barra elegante come "2 su 5" quando visualizzi un problema dall'elenco? Nessun problema! Puoi creare caselle di controllo interattive utilizzando la seguente sintassi:

• [ ] Larghezza dello schermo (numero intero)
• [x] Supporto del lavoratore del servizio
• [x] Ottieni supporto
• [] Supporto per Flexbox CSS
• [ ] Elementi personalizzati

Sintassi: spazio, trattino, spazio, parentesi quadra aperta, spazio (o x), parentesi quadra chiusa, spazio e alcune parole. Successivamente, puoi effettivamente selezionare/deselezionare questi pulsanti! Per qualche ragione, mi sembra una sorta di magia tecnica. Puoi spuntare le caselle! E allo stesso tempo cambia il testo sorgente! È spaventoso pensare a cosa inventeranno dopo. Oh, e se questo problema si trova nel pannello del progetto, lo stato di avanzamento verrà visualizzato anche lì: Se non capisci cosa intendo per "pannello di progetto", leggi sotto. Solo un paio di centimetri più in basso in questa pagina.

#9 Pannelli di progetto in GitHub

Per progetti di grandi dimensioni ho sempre utilizzato Jira. E per i miei progetti personali ho sempre utilizzato Trello. Mi piacciono molto entrambi questi strumenti. Quando qualche settimana fa ho saputo che GitHub offriva la propria opzione, direttamente nella scheda Progetti del repository, ho pensato che avrebbe avuto senso duplicare l'insieme di attività con cui già lavoro in Trello. Non c'è niente di divertente qui. E ora la stessa cosa nel progetto GitHub: A poco a poco i tuoi occhi si abitueranno all'immagine a basso contrasto Per motivi di velocità, ho aggiunto tutto quanto sopra come note, il che significa che non sono problemi "reali" di GitHub. Ma il potere della gestione dei problemi in GitHub risiede nella sua integrazione con il resto del repository, quindi probabilmente è meglio aggiungere i problemi esistenti dal repository alla dashboard. Fai clic su Aggiungi carte nell'angolo in alto a destra e trova ciò che desideri aggiungere. È qui che torna utile una sintassi di ricerca speciale : ad esempio, digita is:pr is:open e puoi trascinare qualsiasi Pull Request aperta sul pannello, oppure label:bug se devi correggere eventuali errori. Puoi anche convertire le note esistenti in questioni. E infine, dal modulo del problema esistente, aggiungilo al progetto nel pannello di destra. Verrà inserito nell'elenco di valutazione del pannello del progetto, quindi potrai scegliere in quale colonna inserirlo Quando la descrizione di una “attività” si trova nello stesso repository del codice che implementa tale attività, è molto (molto) conveniente. Ciò significa che tra molti anni sarai in grado di eseguire git colpa su una riga di codice e capire l'intero problema che ha portato a quella riga, senza dover rintracciare tutto in Jira/Trello/altrove.

Screpolatura

Nelle ultime tre settimane ho sperimentato facendo tutto in GitHub invece che in Jira (su un piccolo progetto, una specie di stile Kanban) e l'ho adorato. Ma non riesco a immaginarlo per un progetto Scrum in cui la velocità di sviluppo e simili devono essere valutate e calcolate correttamente. La buona notizia è che i progetti GitHub hanno così poche "funzionalità speciali" che il passaggio a un altro sistema non richiederà molto tempo. Quindi provalo e vedi quanto ti piace. Non so quanto sia importante, ma ho sentito parlare di ZenHub e l'ho aperto per la prima volta 10 minuti fa. È essenzialmente un'estensione di GitHub in cui puoi valutare i problemi e creare "epic" e dipendenze. Sono presenti grafici della velocità di sviluppo e del burnout; Sembra che sia semplicemente una cosa straordinaria. Ulteriori letture: documentazione GitHub sui progetti.

#10 Wiki

Per un insieme di pagine non strutturate, come Wikipedia, GitHub Wiki (che d'ora in poi chiamerò semplicemente Gwiki) è fantastico. Per un insieme strutturato di pagine, ad esempio come la documentazione, non così tanto. Non c’è modo di indicare che “questa pagina è figlia di quella”; non ci sono cose utili come i pulsanti “Sezione successiva” e “Sezione precedente”. Hansel e Gretel si perderebbero sicuramente qui, perché anche qui non ci sono "breadcrumb" (operatori speciali di debug - ca. trans.). (Nota dell'autore: hai letto questa storia? È semplicemente disumana. Due giovani delinquenti uccidono una povera vecchia signora affamata, bruciandola viva nel suo stesso forno . E, naturalmente, lasciando un disastro completo che nessuno possa capire. Penso che sia questo il motivo i giovani di oggi sono così sensibili da morire: le storie lette ai bambini prima di andare a dormire di questi tempi non sono abbastanza crudeli!) Andando avanti: per provare Gwiki sul serio, ho inserito alcune pagine da NodeJS come pagine wiki, quindi ho creato una pagina personalizzata barra laterale per simulare la struttura reale del sito. Questa barra laterale è sempre presente, anche se la pagina corrente non è evidenziata. I collegamenti dovranno essere mantenuti manualmente, ma nel complesso tutto funziona bene. Se vuoi puoi dare un'occhiata : Questo difficilmente può competere con qualcosa come GitBook (che viene utilizzato nella documentazione di Redux ) o un sito Web su misura. Ma questo è già un buon 80% e tutto è a posto nel tuo repository. Sono solo un fan di questo. Suggerisco che se sei diventato troppo grande per il singolo file README.md e hai bisogno di diverse pagine per manuali utente o documentazione più dettagliata, ha senso restare con Gwiki. Se la mancanza di struttura/navigazione ti dà fastidio, passa a qualcos'altro.

#11 Pagine GitHub

Potresti già sapere che GitHub Pages può essere utilizzato per ospitare un sito Web statico. E se non lo sapevi, allora lo sai adesso. Questa sezione è però dedicata a un argomento più specifico: utilizzare Jekyll per creare un sito web. Nella sua forma più semplice, GitHub Pages + Jekyll può eseguire il rendering del file README.md utilizzando un tema gradevole. Ad esempio, dai un'occhiata alla mia pagina Leggimi da about-github : Se fai clic sulla scheda delle impostazioni per questo sito GitHub, abilita GitHub Pages e seleziona il tema Jekyll... Quindi otterremo una pagina nello stile del tema Jekyll : È quindi possibile creare un intero sito statico basato principalmente su file di markup facilmente modificabili, trasformando essenzialmente GitHub in un CMS. Anche se in realtà non l'ho usato, questo è il modo in cui i siti Web vengono creati utilizzando il framework Bootstrap utilizzando React, quindi non c'è niente di terribile in questo. Noto che Ruby deve essere in esecuzione sulla macchina locale (gli utenti Windows qui si scambieranno sguardi comprensivi e andranno dall'altra parte, gli utenti macOS diranno: “Qual è il problema, dove vai? Ruby è una piattaforma universale! C'è anche un GEMS sistema di gestione dei pacchetti!”) (Vale anche la pena notare che "contenuti o comportamenti aggressivi o minacciosi" non sono consentiti sulle pagine GitHub, quindi non sarai in grado di pubblicare lì la tua versione della storia di Hansel e Gretel).

La mia opinione

Più esaminavo la combinazione GitHub Pages + Jekyll (per questo articolo), più pensavo che l'intera idea avesse un odore strano. L'idea di "creare il proprio sito web con il minimo sforzo" è fantastica. Ma per lavorarci hai ancora bisogno della versione corrente sul computer locale. E per qualcosa di così "semplice" ci sono troppi comandi da riga di comando. Ho dato un'occhiata alle sette pagine della sezione Per iniziare e mi sono sentito come se l'unica cosa semplice fossi io . E non ho nemmeno capito la semplice sintassi per la pagina principale o le basi di un semplice "meccanismo di template basato sul linguaggio Liquid". Preferirei scrivere un sito web da solo! Ad essere onesti, sono un po' sorpreso che Facebook lo utilizzi per la documentazione di React quando probabilmente potrebbero creare le pagine del loro sistema di aiuto utilizzando React e pre-renderizzare come file HTML statici ogni giorno . Tutto quello che devono fare è trovare un modo per ricevere i file di markup esistenti come se provenissero dal CMS. Cosa succede se...

#12 Utilizzo di GitHub come CMS

Supponiamo di avere un sito Web con del testo, ma non vogliamo archiviare quel testo come markup HTML. Vorremmo invece archiviare porzioni di testo da qualche parte che possano essere facilmente modificate da utenti non sviluppatori. Preferibilmente con qualche opzione di controllo delle versioni. Magari anche con una sorta di processo di peer review. Ecco cosa suggerisco: utilizzare i file di markup archiviati nel repository per archiviare il testo. E utilizza un componente lato client che recuperi queste parti di testo e le visualizzi sulla pagina. Sono un fan di React, quindi ecco un esempio di un componente <Markdown> corretto che, dato un percorso a un file markdown, lo estrarrà, lo analizzerà e lo renderà come HTML.

class Markdown extends React.Component {
    constructor(props) {
      super(props);

      // Конечно, вам нужно заменить это на свой URL
      this.baseUrl = 'https://raw.githubusercontent.com/davidgilbertson/about-github/master/text-snippets';

      this.state = {
        markdown: '',
      };
    }

    componentDidMount() {
      fetch(`${this.baseUrl}/${this.props.url}`)
        .then(response => response.text())
        .then((markdown) => {
          this.setState({markdown});
        });
    }

    render() {
      return (
        <div dangerouslySetInnerHTML={{__html: marked(this.state.markdown)}} />
      );
    }
}

(Uso il pacchetto contrassegnato con npm qui per analizzare il markup in HTML) L'URL punta al mio repository di esempio, che contiene file di markup nella directory /text-snippets . (Puoi anche utilizzare l'API GitHub per recuperare i contenuti , ma dubito che ne avrai bisogno.) Potresti utilizzare un componente come questo in questo modo:

const Page = () => (
  <div className="page">
    <div className="about-us">
      <Markdown url="about-us.md" />
    </div>

    <div className="disclaimer">
      <p>A very important disclaimer:</p>

      <Markdown url="disclaimers/home-page-disclaimer.md" />
    </div>
  </div>
);

Quindi ora GitHub funge, in un certo senso, dal tuo CMS per quei pezzi di testo che vorresti ospitare. L'esempio precedente recupera il markup solo dopo che il componente è stato caricato nel browser. Se hai bisogno di un sito statico, dovrai renderizzarlo sul server. Buone notizie! Non c'è nulla che ti impedisca di recuperare tutti i file di markup sul server (usando qualunque strategia di memorizzazione nella cache preferisci). Se decidi di seguire questa strada, ha senso utilizzare l'API GitHub per ottenere un elenco di tutti i file di markup in una directory. Bonus: utilità GitHub! Utilizzo l'estensione Octotree per Chrome ormai da un po' di tempo e te la consiglio. Non senza riserve, ma lo consiglio comunque. Visualizza un pannello a sinistra con una visualizzazione ad albero del repository che stai esplorando. E da questo video ho scoperto octobox , che finora mi sembra un'ottima utilità. Questa è la posta in arrivo per i tuoi problemi su GitHub. Questo è tutto quello che devi sapere su di lui. A proposito di colori, ho scattato tutti gli screenshot qui sopra con un tema chiaro per non spaventarvi. Ma se preferisco i colori scuri in tutto il resto, allora perché sopportare GitHub mortalmente pallido? Qui ho utilizzato una combinazione dell'estensione Stylish per il browser Chrome (che può applicare temi a qualsiasi sito Web) e dello stile GitHub Dark . E per cominciare, il tema scuro degli strumenti per sviluppatori GitHub (integrato, devi solo abilitarlo) e il tema Atom One Dark per Chrome.

Bitbucket

A rigor di termini, non è del tutto appropriato qui, ma non posso fare a meno di menzionare Bitbucket. Due anni fa ho iniziato un progetto e ho trascorso mezza giornata a scegliere il miglior hosting Git. Quindi, Bitbucket ha vinto con un margine significativo. La loro pipeline di revisione del codice è molto più avanti rispetto alla concorrenza (questo accadeva molto prima che GitHub avesse anche il concetto di revisore). Da allora GitHub ha acquisito anche recensioni. Sfortunatamente, non ho avuto la possibilità di utilizzare Bitbucket nell'ultimo anno: forse hanno fatto ancora dei passi avanti in qualcosa. Quindi consiglio a chi è responsabile della scelta di un servizio di hosting git di prestare attenzione anche a Bitbucket.

Conclusione

È tutto! Spero di essere riuscito a dirti almeno tre cose che prima ti erano sconosciute. E spero anche che tu ti sia divertito a leggere il mio articolo.