Hosting e pull request

Creare

Crea una pull request (o merge request) senza uscire dall'app: menu a tendina per i branch, titolo e corpo precompilati dai commit del branch, un interruttore per la bozza e — su GitHub — revisori, etichette e assegnatari applicati alla creazione.

Funziona su GitHub, GitLab, Bitbucket e Azure DevOps. Le PR/MR aperte di tutti e quattro sono elencate nella barra laterale.

Puoi partire dal confronto fra branch, dal grafo, dal + nel pannello delle PR, oppure da una issue (che compila Closes #N).

Le pile nell’elenco

Le pull request appoggiate una sull’altra si richiudono in una sola riga con un’icona di pila, il ramo su cui atterra la catena e quante sono. Espandila per vedere la catena in ordine di lettura — dalla foglia giù fino alla base — con una freccetta sotto ognuna che dice in cosa confluisce: la direzione è a schermo, non da dedurre da quattro rami base.

Due cose formano quel gruppo: il numero di pila di GitHub, quando le PR appartengono a una pila nativa, altrimenti le ref stesse: una pull request la cui base è la testa di un’altra si appoggia su di essa. La seconda regola è ciò che lo fa funzionare anche su GitLab, Bitbucket e Azure DevOps.

Ogni riga porta lo stato dei check della sua testa — passa sopra per i conteggi — e, su GitHub, anche i livelli già chiusi o uniti, che un elenco di PR aperte nasconderebbe. Un livello sopra uno chiuso viene segnato come bloccato: i suoi check possono essere verdi, ma il ramo a cui punta non atterrerà mai. Le azioni della riga compaiono al passaggio del mouse, così il titolo tiene la larghezza.

Leggere i check costa una richiesta per pull request, e solo quando l’elenco viene aggiornato.

Revisione — GitHub e GitLab

Se qualcuno fa un force push a metà revisione, cos'è cambiato da ti mostra esattamente cosa si è spostato.

Le differenze di GitLab, dette chiaramente: GitLab non ha una singola chiamata "invia revisione", quindi approva usa il suo endpoint di approvazione e richiedi modifiche rimuove la tua approvazione e pubblica il tuo commento. Il rebase-merge non è offerto — GitLab decide tra merge-commit e fast-forward in base alle impostazioni del progetto, quindi il menu di merge mostra solo merge e squash. I thread inline mostrano file e riga, ma non l'hunk di diff circostante, che l'API di GitLab non restituisce. Revisione e merge funzionano per i progetti su gitlab.com; le istanze self-hosted non sono ancora supportate. Bitbucket e Azure DevOps si aprono ancora nel browser per la revisione.

Issue, milestone, release — GitHub

Sfoglia le issue e apri una scheda completa per una di esse: corpo, commenti, etichette, assegnatari, milestone, campi dei Projects v2, chiusura e riapertura, e crea un branch per questa issue (con la denominazione affidata all'AI). Le milestone mostrano l'avanzamento e le proprie issue. Le release sono sfogliabili con una pagina di changelog.

Notifiche — GitHub

Tutta la tua posta in arrivo — richieste di revisione, menzioni, attività della CI — su ogni repository, con i filtri non letti/tutte e la marcatura come letto. La campanella nella barra degli strumenti porta un badge dei non letti, e notifiche desktop opzionali scattano quando ti viene chiesta una revisione o la CI finisce.

Token

Token per profilo per più account o organizzazioni, conservati nel portachiavi del tuo sistema operativo. Gitcito può anche prendere in prestito quello che il tuo credential helper di git già custodisce, quindi un'organizzazione per cui ti sei già autenticato spesso non richiede alcuna configurazione. Vedi Sicurezza e segreti.

Vedi anche: Branch impilate · Funzioni AI