Come eseguire ricerche nella cronologia del repository e organizzarla usando GitHub
Verrà qui descritto come usare filtri, il comando blame e collegamenti incrociati per eseguire ricerche nella cronologia del repository e organizzarla.
Si supponga di essere uno sviluppatore che è appena entrato a far parte di un progetto di grandi dimensioni. Qualcuno ha appena pubblicato la segnalazione di un nuovo problema correlato alla barra laterale dell'app Web e si è stati assegnati alla sua correzione. Il report è già stato letto alcune volte e si è compreso il problema descritto ed è ora necessario determinare come iniziare a correggerlo.
Come nuovo membro del team, non si ha ancora familiarità con la codebase. Inoltre, non si è ancora preso parte alle conversazioni sulla pianificazione, alle revisioni del codice o ad altre attività che fornirebbero il contesto necessario per avviare l'implementazione. Sarà prima di tutto necessario acquisire le informazioni di base per determinare meglio la correzione appropriata.
Ricerca in GitHub
Anche se non si è partecipato agli eventi che hanno portato all'implementazione della barra laterale, molti di questi sono inclusi nella cronologia del progetto. La ricerca nel repository del progetto del termine "sidebar" fornirà un ottimo punto di partenza.
In GitHub sono disponibili due metodi di ricerca: la ricerca globale nella parte superiore della pagina e la ricerca per ambito disponibile in determinate schede del repository. I due metodi supportano la stessa sintassi e funzionano allo stesso modo, ma con alcune differenze importanti.
Ricerca globale
La ricerca globale consente di usare la sintassi di ricerca completa per eseguire la ricerca in tutto GitHub.
I risultati della ricerca sono completi e includono tutti gli elementi, dal codice ai problemi, dal Marketplace fino addirittura agli utenti. Questo è il modo migliore per trovare le citazioni dei termini principali in più tipi di risultati e repository.
Nota
La clausola di filtro is:pr esclude i problemi restituiti dall'archivio di problemi/richieste pull. Alcune clausole di filtro, ad esempio is:pr, sono supportate solo da determinati provider di ricerca, mentre sono ignorate da altri. Ad esempio, il provider di ricerca del codice non supporta questa clausola e di conseguenza la ignora e restituisce gli stessi risultati del codice in entrambi i casi.
In questo scenario l'uso della ricerca globale per ambito nell'archivio corrente è un metodo efficace per trovare codice e commit che citano il termine "sidebar". Probabilmente verranno restituiti problemi e richieste pull, anche se non sono facili da filtrare ulteriormente nella visualizzazione dei risultati della ricerca globale.
Per creare una ricerca globale complessa, provare la ricerca avanzata.
Ricerca di contesto
Le ricerche di contesto sono disponibili in determinate schede, ad esempio Issues (Problemi) e Pull requests (Richieste pull). Queste ricerche hanno come ambito il repository corrente e restituiscono solo risultati di questo tipo. Il vantaggio della definizione di un ambito è che consente all'interfaccia utente di esporre filtri specifici di tipi noti, ad esempio autori, etichette, progetti e altri.
L'uso della ricerca di contesto è l'opzione consigliata quando si cerca qualcosa nel repository corrente. In questo scenario è un buon metodo per trovare risultati della ricerca che citano "sidebar", che possono essere affinati usando gli elenchi a discesa dei filtri.
Uso dei filtri di ricerca
Esiste un numero infinito di modi per eseguire ricerche usando la sintassi di ricerca completa. Tuttavia, la maggior parte delle ricerche si avvale solo di alcuni filtri comuni. Sebbene questi siano spesso disponibili da elenchi a discesa per la ricerca di contesto, a volte è più pratico digitarli direttamente.
Ecco alcune query di filtro di esempio:
| Query | Spiegazione |
|---|---|
is:open is:issue assignee:@me |
Problemi aperti assegnati all'utente corrente (@me) |
is:closed is:pr author:contoso |
Richieste pull chiuse create da @contoso |
is:pr sidebar in:comments |
Richieste pull in cui è citato "sidebar" nei commenti |
is:open is:issue label:bug -linked:pr |
Problemi aperti contrassegnati come bug senza una richiesta pull collegata |
Altre informazioni sulla sintassi di ricerca
Che cos'è git blame?
Nonostante il nome negativo, git blame è un comando che visualizza la cronologia dei commit per un file. Semplifica l'individuazione di chi ha apportato modifiche e quando. In questo modo, è molto più semplice tenere traccia degli altri utenti che hanno lavorato a un file per individuarne l'input o la partecipazione.
Nota
In alcuni sistemi Git git praise sostituisce git blame per evitare le implicazioni negative di questo termine.
Comando blame in GitHub
GitHub estende le funzionalità di base di git blame con un'interfaccia utente più affidabile.
In questo scenario è possibile passare a questa visualizzazione in diversi modi. Si potrebbe aver trovato del codice nella barra laterale dalla ricerca globale e selezionato l'opzione Blame per vedere chi ci ha lavorato per ultimo, oppure si potrebbe aver trovato una richiesta pull e averla rintracciata fino all'ultimo commit che sembra correlato alla descrizione del bug. In ogni caso, la visualizzazione tramite blame è un metodo efficace per trovare un esperto in materia per l'attività.
Collegamento incrociato di problemi, commit e altro
Una parte di ciò che rende GitHub ideale per progetti software basati sulla collaborazione è il supporto per il collegamento di informazioni separate. Questo avviene in parte automaticamente, ad esempio quando si crea una richiesta pull da una serie di commit in un ramo. In altri casi, è possibile usare l'interfaccia per collegare manualmente richieste pull o progetti a problemi usando le opzioni degli elenchi a discesa.
Riferimenti collegati automaticamente
Per semplificare ulteriormente il collegamento incrociato di diversi elementi nel progetto, GitHub offre una sintassi abbreviata. Ad esempio, se si lascia un commento come Duplicate of #8, GitHub riconoscerà che #8 è un problema e creerà il collegamento appropriato.
GitHub collega automaticamente anche i commit se si incollano i primi sette o più caratteri del relativo ID.
In questo scenario questi collegamenti possono rivelarsi molto preziosi per accelerare i tempi se qualcuno in precedenza ha pensato di lasciare il contesto. Ad esempio, lo stato corrente della barra laterale potrebbe essere associato ad alcuni problemi noti relativi a una dipendenza da JavaScript. Se il problema relativo alla dipendenza è stato discusso in un altro problema in cui non viene citato esplicitamente il termine "sidebar", sarà difficile trovarlo. Tuttavia, se qualcuno in passato ha pensato di collegare il problema nella discussione, è possibile risparmiare molto tempo. Tenere presente questo aspetto la prossima volta che si documenteranno problemi e richieste pull.
Altre informazioni su riferimenti e URL collegati automaticamente.
Inclusione di utenti nel ciclo con @mention
Oltre a collegare problemi e commit, è spesso utile associare altre persone alle discussioni. Il modo più semplice a questo scopo è tramite l'uso di @mention. Questo tipo di menzione informa l'utente citato in modo che possa partecipare alla discussione. È anche un metodo efficace per identificare le persone associate a problemi anche molto tempo dopo che questi sono stati chiusi.
