Dal 15 ottobre GitHub non invia più notifiche email per gli eventi di push nei repository. L’azienda ha ritirato la funzione per contrastare spam e abusi, perché i destinatari potevano ricevere questi messaggi senza aver dato il consenso.

Chi utilizzava queste email per seguire gli aggiornamenti di un repository deve quindi predisporre un altro sistema di invio. GitHub indica come alternativa un workflow di GitHub Actions attivato dagli eventi di push.

Per continuare a ricevere i messaggi occorre configurare il workflow e collegarlo a un proprio server SMTP o a un fornitore email. L’invio passa così attraverso l’infrastruttura scelta dall’utente.

GitHub consente ora ai manutentori di includere anche le pull request in bozza nei limiti configurati per il repository. La novità è stata annunciata nel changelog dell’8 ottobre 2026.

Prima della modifica, un utente poteva aprire un numero qualsiasi di bozze anche nei repository che limitavano le altre pull request. Secondo GitHub, includerle nel conteggio aiuta a contenere contributi di bassa qualità, notifiche e cicli CI legati allo spam.

Restano da chiarire: Il changelog non specifica i piani interessati né i passaggi dell’interfaccia per configurare l’opzione.

Dalla versione 1.0.94-0, GitHub Copilot CLI può individuare con il comando /model i modelli supportati da un’istanza locale di Ollama già in esecuzione. Questi compaiono insieme ai modelli configurati e a quelli cloud di GitHub Copilot.

La scoperta non aggiunge automaticamente i modelli: occorre sceglierne uno e confermare l’aggiunta, dopodiché è possibile usarlo nella sessione corrente senza riavviare la CLI. La funzione non scarica né installa Ollama o i modelli, che devono essere già presenti e supportare tool calling e streaming.

La scelta di un modello locale non attiva la modalità offline e non disabilita la telemetria GitHub. Quando viene usato un provider remoto, questo può ricevere i prompt e il contesto del codice.

GitHub presenta un modello ottimizzato per rilevare segreti, che analizza il codice circostante per riconoscere credenziali probabili, comprese password non riconoscibili dal formato del token, senza generare codice o prosa.

Il modello usa il contesto del codice per individuare credenziali probabili anche quando il formato del token non basta. Il passaggio degli avvisi AI esistenti per password è distinto dalle integrazioni ancora in preview.

Il rilevamento in push protection resta in private preview; per l'integrazione con Copilot /security-review occorre attendere la futura private preview annunciata.

Il progetto Git ha pubblicato la versione 2.56.0 con contributi di oltre 104 persone, 39 delle quali nuove al progetto.

Le novità riducono il rischio di includere modifiche estranee durante la risoluzione dei conflitti e migliorano operazioni costose sui repository di grandi dimensioni.

Consultare le note di rilascio complete e verificare la compatibilità di hook, strumenti e workflow prima dell'aggiornamento negli ambienti di produzione.

GitHub ha introdotto una policy globale per le funzionalità Copilot generalmente disponibili e per le capacità supportate dai client nelle impostazioni enterprise e organizzazione.

La modifica rende esplicito il controllo amministrativo sulle future funzioni Copilot e riduce il rischio che capacità enterprise restino in uno stato non governato quando diventano generalmente disponibili.

Gli amministratori dovrebbero verificare la nuova impostazione in AI Controls e definire il comportamento desiderato prima del 22 ottobre 2026.

GitHub ha introdotto il sandbox locale nell’app GitHub Copilot in anteprima pubblica.

Il controllo locale riduce l’impatto potenziale di comandi involontari e consente ai team di definire confini espliciti per file, rete e credenziali.

Verificare i requisiti del sistema operativo e provare le policy su un progetto non critico prima di abilitarle sui repository di produzione.

GitHub ha ricostruito la vista delle pull request nell’app GitHub Copilot per sostenere diff e conversazioni molto grandi.

La nuova architettura rende più praticabile la revisione di refactoring e migrazioni che non possono essere suddivisi in pull request più piccole.

Verificare il comportamento su pull request reali di grandi dimensioni e gli eventuali requisiti della versione desktop.

Un’indagine di GitHub e dello Yale Program on Climate Change Communication su 1.039 utenti GitHub negli Stati Uniti rileva che otto intervistati su dieci sono interessati a strumenti per scrivere codice più efficiente dal punto di vista energetico.

Il rapporto indica una domanda concreta di strumenti, benchmark e flussi di revisione che trasformino l’efficienza del software in un requisito verificabile, non in una dichiarazione generica.

GitHub invita i team a misurare sprechi di calcolo, dati, rete e rendering e a verificare ogni proposta con benchmark e test riproducibili.

La nuova pagina Pull Requests a livello di repository è ora generalmente disponibile per tutti gli utenti GitHub.

La ricerca e la gestione delle pull request diventano più strutturate direttamente nel contesto del repository, con strumenti utili soprattutto ai team che lavorano su code review numerose.

Provare i nuovi filtri e le azioni in blocco nei repository interessati, verificando i permessi disponibili per il team.

GitHub annuncia il rollout graduale di Grok 4.7, modello di ragionamento di xAI, in GitHub Copilot.

L'arrivo di Grok 4.7 amplia i modelli disponibili nei flussi di sviluppo assistiti da Copilot, ma l'accesso effettivo dipende dal piano e dalla fase di rollout.

Controllare il model picker e, per gli ambienti Business o Enterprise, la policy dei modelli per verificare quando Grok 4.7 diventa selezionabile.

GitHub ha reso generalmente disponibili aggiornamenti per Copilot code review.

Le code review assistite diventano più leggibili e tracciabili, mentre l'accettazione in batch riduce il lavoro manuale nella gestione dei suggerimenti già verificati.

Verificare nel proprio piano GitHub la disponibilità generale della funzione e controllare il riepilogo e i messaggi generati prima di applicare batch di suggerimenti in repository di produzione.

GitHub annuncia il ritiro il 19 ottobre 2026 dei modelli Gemini 3.7 Flash, GPT-5.5, GPT-5.4, GPT-5.4 mini, GPT-5 mini e Grok 4.5 nelle esperienze Copilot.

I workflow Copilot con modello fissato rischiano una modifica operativa dopo il 19 ottobre se non vengono aggiornati.

Inventariare i workflow che selezionano i modelli ritirati e provare le alternative consigliate prima della scadenza.

GitHub indica miglioramenti alla code review di Copilot e la selezione automatica dei modelli in base al tier dell'utente.

Le nuove funzioni incidono su code review, osservabilità degli agenti e gestione del contesto nei flussi Copilot.

Controllare la disponibilità delle funzioni nel proprio piano e aggiornare le policy interne prima di abilitarle nei repository.

GitHub ha reso generalmente disponibile l'API REST per creare, aggiornare e leggere la condizione Restrict code coverage nelle ruleset dei repository.

Il controllo della copertura può entrare nei flussi infrastrutturali e di qualità del codice senza gestione manuale della ruleset.

Verificare il piano GitHub e predisporre la condizione nella configurazione del repository solo dopo aver attivato Code Quality e gli upload di coverage.

GitHub aggiunge ai token granulari npm l'opzione Read and write (stage only), che consente di preparare una versione senza pubblicarla direttamente nel registry.

La separazione tra staging e pubblicazione riduce il rischio che un workflow automatizzato immetta direttamente una versione npm senza una revisione umana.

Verificare i requisiti del proprio account e aggiornare i workflow compatibili con npm stage publish prima della scadenza indicata da GitHub.

GitHub ha pubblicato un nuovo episodio del GitHub Podcast dedicato a cinque luoghi comuni sull'uso dell'intelligenza artificiale nello sviluppo software.

Il contenuto offre un orientamento ufficiale sul modo in cui GitHub interpreta revisione del codice, retrieval e strumenti per agenti, con attenzione a responsabilità, rischio e manutenibilità.

Valutare il livello di revisione e il contesto documentale necessari prima di adottare questi strumenti in un progetto reale.

Le workflow execution protections di GitHub Actions sono generalmente disponibili.

Le protezioni offrono un controllo operativo piu stretto sui workflow che possono essere eseguiti e sugli eventi che li attivano.

I responsabili CI/CD dovrebbero valutare le regole in modalita evaluate e verificare l'impatto sui repository pubblici prima dell'enforcement.

L'immagine Ubuntu 26.04 e generalmente disponibile per i runner GitHub Actions x64 e arm64.

La migrazione automatica dell'etichetta ubuntu-latest puo cambiare l'ambiente di build e richiede una verifica preventiva dei workflow.

I maintainer dovrebbero testare i workflow con Ubuntu 26.04 e usare un'etichetta fissata se serve controllare la finestra di migrazione.

La Usage Metrics API di GitHub include metriche sulle skills e sui custom agents della CLI agentica.

Le organizzazioni possono misurare con maggiore precisione quali estensioni della CLI agentica vengono adottate.

I responsabili della piattaforma dovrebbero verificare i nuovi campi disponibili e adeguare i report interni sull'uso degli strumenti agentici.