Graydon Hoare, autore di Bors, ha scritto un post nel suo blog intitolato "technicalities: ‘not rocket science’ (the story of monotone and bors)" poco più di dieci anni fa, dove parla della lotta per evitare di introdurre bug nel sistema di controllo delle versioni all'inizio degli anni 2000. Hoare lavorava su un progetto con Ben Elliston e altri colleghi, e per mantenere il controllo del progetto, idearono un sistema di cron job, rsync, repository CVS e un piccolo database Postgres per monitorare i risultati dei test. Lo scopo era semplice: mantenere un repository di codice che passasse sempre tutti i test.

Questo sistema automatizzato non solo garantiva che i clienti non incontrassero bug, ma permetteva anche agli ingegneri di lavorare su revisioni sicure, evitando di dover risolvere i bug introdotti da altri. Il principio base era chiaro: mantenere automaticamente un repository di codice che passi tutti i test. Questo principio, definito da Hoare come "non rocket science", si è dimostrato valido nel tempo e molti repository moderni praticano una qualche forma di test di integrazione continua prima di effettuare il merge del codice.

Il problema, però, è che mantenere il trunk verde e superare tutti i test è più complicato di quanto sembri. Un concetto chiave è il merge skew, che si verifica quando il codice viene testato e passato su una vecchia revisione del trunk e poi fallisce quando viene unito alla revisione più recente. Questo problema può portare a frequenti conflitti semantici, soprattutto in codebase altamente interconnessi o con un alto tasso di cambiamento.

Per risolvere il merge skew, si può abilitare l'opzione "Require branches to be up to date before merging" su GitHub, che forza gli autori a rebase e ritestare ogni PR prima del merge. Tuttavia, questa soluzione può diventare frustrante per i team di grandi dimensioni, dove gli ingegneri si trovano spesso a competere per rebase e merge, creando una situazione inefficiente e manuale.

Una soluzione migliore è una coda di merge automatizzata. Il primo tentativo open-source di risolvere questo problema è stato Bors, che permette agli utenti di aggiungere un commento a una PR per metterla in coda per il merge. Bors esegue i test su ogni PR nella coda prima di effettuare il merge, garantendo che ogni cambiamento venga integrato senza skew.

Tuttavia, Bors ha dei limiti in termini di velocità. In un repository con molti cambiamenti giornalieri e tempi di CI lunghi, una coda semplice può rallentare il processo di merge. Google ha risolto questo problema con un sistema di batch e parallelizzazione, che permette di mantenere un throughput elevato. Il loro sistema TAP esegue una serie di test preliminari, permette il merge diretto nel trunk e poi verifica la correttezza con test più lunghi e paralleli.

Al di fuori di Google, altre aziende come Shopify, Uber e Airbnb hanno sviluppato soluzioni interne simili. Anche GitLab e GitHub hanno implementato funzioni di merge queue per affrontare il problema del merge skew. GitHub ha recentemente lanciato una funzione di merge queue che sostituisce il pulsante di merge tradizionale con un pulsante "Merge when ready".